Patching Operating System Dependencies

Operating systems are extensible entities, allowing users to install utilities and binaries in a variety of ways. Examples vary greatly, from installing a Secure Shell (SSH) client via apt on an Ubuntu machine, through downloading a cURL binary manually to your Red Hat server, to installing a full database via a dedicated installer on a Windows machine. These components are in turn used by the applications or systems administrators and are referred to as operating system (OS) dependencies.

OS dependencies offer great functionality, but they need some tender love and care. Over time, maintainers, researchers, and attackers discover security flaws in these dependencies, which are also known as vulnerabilities. These security holes are then fixed (more often than not), and a new version of the component is published. The consumer of this component then needs to find out the vulnerability was disclosed and then download and install the updated versions to keep their machine secure.

Updating dependencies on a machine is a relatively easy, albeit annoying, task (how often have you deferred your automatic updates to “install later”?). It might break something but usually doesn’t, and it might require a restart but not much more. However, updating dependencies at scale—patching thousands of machines in a continuous manner—is extremely difficult.

Subsequently, most companies fail at patching their servers well, and exploiting unpatched servers has become the top reason for successful breaches. In its 2019 predictions, security firm TrendMicro remarks that 99.99% of exploit-based attacks will not be zero-day vulnerabilities, stating, “The most accessible opportunity for cybercriminals is the window of exposure that opens up between the release of a new patch and when it is implemented on enterprise systems. In 2019, successful exploit-based attacks will involve vulnerabilities for which patches have been available for weeks or even months but have not been applied yet.”

When using serverless, patching servers is no longer your responsibility (as application owner). The Function-as-a-Service (FaaS) platform is in charge of provisioning and launching a server for you on demand, and it’s responsible for keeping its OS dependencies patched. It is still your responsibility to use a platform that does this well, but most cloud platforms do.

We saw a good example of this when the Meltdown vulnerability was disclosed, describing how data can be stolen by exploiting a weakness in how the OS interacts with the underlying processor. Amazon Web Services (AWS) quickly put some mitigating controls in place and published a new patched OS. Customers were subsequently advised to patch their instance operating systems, causing lots of shuffling amidst users, whereas serverless AWS Lambda (and Fargate) users received a simple “no customer action is required” message.

Note that although FaaS patches vulnerable OS dependencies, it does not patch vulnerable application dependencies. We look at that in more detail in “Library Vulnerabilities”.

Surviving Denial of Service Attacks

Denial of Service (DoS) attacks attempt to use up an application’s resources, therefore keeping it from serving legitimate users. They come in many shapes and forms, ranging from overwhelming network bandwidth, through invoking many compute-heavy actions in parallel, to exploiting flaws in the app that cause infinite or nearly infinite loops.

Because DoS attacks target resources, their risk is mitigated by having an elastic compute service, which expands capacity as quickly as it’s taken up. In other words, the same controls that can automatically scale your system’s capacity for good traffic can help it cope with bad traffic, too. The faster your system autoscales, the smaller the impact a DoS attack will have on your users.

Because serverless/FaaS is extremely elastic, it naturally fends off most DoS attacks. Malicious traffic spins up ad hoc server capacity and renders those instances useless, but legitimate traffic gets its own instances, and so—in theory—continues to work without a hitch! This is an implicit benefit of using serverless: no further action is necessary.

With that being said, this serverless security advantage does come with a few catches of which you need to be mindful:

• Most FaaS systems do enforce some limit on the number of concurrent instances (typically in the hundreds by default). If a DoS attack cause your application to the limit, it can still render you unavailable for good users.

• Even though FaaS is elastic, it often uses backend services such as databases or legacy systems that don’t autoscale quite as quickly. If that’s the case, a DoS attack can still take up your overall systems by having your fast-scaling functions take down the systems they interact with behind the scenes; you need to be alert for such resource exhaustion attacks and place throttles where needed.

• Serverless will autoscale, but that scale comes with a cost. Left unchecked, a FaaS application will continue spawning instances as long as demand comes in, racking up a sizeable bill. This is sometimes referred to as a “Billing DoS”—denying access to your bank account! Most cloud platforms have default limits on the number of resources and concurrent executions allowed, be sure to review those and confirm that they match your ability to pay, and consider using dedicated DoS protection solutions.

No More Long-Lived Compromised Servers

Hollywood movies like showing hackers mad-typing into terminals and breaking into remote systems in one go, but in practice that isn’t how cybersecurity breaches happen. Far more often, breaches happen in steps: attackers find a security hole, exploit it, and attempt to capture a “beach-head” by installing a local (malicious) agent. After it is installed, this agent cautiously continues probing, taking extra care not to be detected, looking to go deeper into the network or to find and start leaking valuable data.

With many long-standing servers, compromised systems often remain undetected for very long periods—months or even years. Famous breaches such as the Panama Papers and the breaches of Target and Sony are high profile examples of such long-standing data exfiltration. Even if the vulnerable systems are patched and their security holes closed, the malicious agent is already behind your walls!

With serverless, long-standing servers simply don’t exist. Servers are launched, briefly used, and then discarded and cleared. Even when FaaS systems keep servers “warm” (meaning keeping machines running for a while to serve future function invocations), machines rarely go beyond a lifespan of hours or at most days.

Under this paradigm, attackers cannot simply compromise a machine and continue penetrating deeper. They must launch their attacks again and again, repeatedly risking detection and having the vulnerability fixed.

This subtle but important security advantage, unlike the previous two, is not the result of pushing responsibilities to the platform; rather, it’s the programming model that serverless drives. In fact, the same advantage exists in microservices environments that cycle through their servers frequently.

Up to this point, we’ve discussed how serverless works and how it benefits security. In Chapter 3, we get to what you’re probably most interested in: the aspects of security that serverless doesn’t fix for you, and what you can do about it.