DEVOPSdigest

In the previous blog of this WhiteHat Security series, the Twelve-Factor App looked at exporting services via port binding and included advice on what to apply from a security point of view.

We now move on to Step 8 of the Twelve-Factor App, which recommends scaling out via the process model discussed in Step 7.

Start with Security and the Twelve-Factor App - Step 1
Start with Security and the Twelve-Factor App - Step 2
Start with Security and the Twelve-Factor App - Step 3
Start with Security and the Twelve-Factor App - Step 4
Start with Security and the Twelve-Factor App - Step 5
Start with Security and the Twelve-Factor App - Step 6
Start with Security and the Twelve-Factor App - Step 7

Defining Concurrency in the Twelve-Factor App

A simple explanation for this factor is to picture a lot of little processes handling specific requirements, such as web requests, API calls, or sending tweets. Keeping all these working independently means that the application will scale better, and you’ll be able to manage more activities concurrently.

According to the Twelve-factor app, processes are a first class citizen, in which processes take strong cues from the unix process model for running service daemons(link is external). Twelve-Factor goes on to say that by using this model, the developer can architect the app to handle diverse workloads by assigning each type of work to a process type. For example, HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process.

Applying Security to Step 8

The security challenge to this step is that the ability to scale requires paying attention to APIs that are known to introduce Denial of Service issues. One such API is known as "readLine". Implementations of this method are available on almost every software development platform and yet is subject to Denial of Service. "readLine" will continuously read bytes from a given input stream until a newline character is found. Assume the attacker controls that stream… what if the attacker never provides a newline character? What will happen? More often than not, this will result in errors and stability issues stemming from memory exhaustion.

Two simple processes can be implemented to strengthen the security posture of this step:

1. Ban DoS-able API i.e. Document relevant DoS-able API for your platform (such as readLine) and ban them

2. Resource Closure i.e. Expose simplistic patterns to facilitate closing of I/O resources (e.g. scope)

In the next blog we will cover Step 9, Disposability, which is all about maximizing robustness with fast startup and a graceful shutdown, and what this means from a security point of view.

Read Security and the Twelve-Factor App - Step 9