Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

2/1/2018
02:00 PM
Guy Podjarny
Guy Podjarny
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Securing Cloud-Native Apps

A useful approach for securing cloud-native platforms can be adapted for securing apps running on top of the platform as well.

In 2016, Justin Smith wrote a great article about securing cloud-native platforms such as CloudFoundry and OpenShift. Smith describes what he calls the "Three R's" — rotate, repair, and repave — and how they can improve security. The model is powerful, but Smith focuses on the platform itself. Those same techniques, with minor modifications, can be extended to securing the apps running on top of the platform.

Let's dive into the three R's, and see how they apply to the platform.

Rotate
The first R stands for rotate. A cloud-native platform relies on automation, so different parts of the system need to access and modify others. To do this, they use a mix of different tokens, ranging from username and password to UUIDs (universally unique IDs, a 128-bit number) to private keys and certificates. Over time, many systems and individuals have access to these tokens, inevitably resulting in tokens being leaked, giving attackers control over our systems.

The rotate principle means you should rotate your keys as often as possible. This way, leaked credentials will quickly become irrelevant, often before the attacker even gets to use them. Rotating credentials requires rethinking how you manage them, switching from a reliance on manual tracking to use of a central key management system, and the automation of the creation and consumption of access keys. (CloudFoundry recently launched CredHub for this purpose.)

This security principle applies to cloud-native apps pretty much as is. Although platforms rely on credentials for steps like SSH (Secure Shell) access and system provisioning, apps need them for accessing databases, third-party services, and interacting with the platform itself. Cloud apps typically store credentials in the platform's configuration or environment variables, which makes the values available to the app. Such a centralized credential storage makes it fairly easy to rotate keys — simply generate a new token, update the app's configuration, and restart all running instances.

Rotating application credentials is a great way to improve app security in cloud-native apps. All it requires is a bit of automation. Note that this often requires having two valid credentials at any given time — one used by the current system and one being rolled out. Such pairs allow you to rotate credentials with no downtime, as old running instances will keep using the old keys until all are restarted.

Repair
The next R stands for repair, as in repairing known vulnerabilities in your systems. Known vulnerabilities account for the majority of successful exploits, and high-profile vulnerabilities such as Heartbleed and Shellshock demonstrate their severity well. Each of these are usually easy to fix, often by simply grabbing the fixed version, but doing so at scale is hard.

Using a cloud-native platform implies that you can automate the creation and deployment of your containers. This presents the opportunity to automate the tracking of known vulnerabilities in your operating system or its dependencies, trigger the creation of new containers and images, and streamline the rollout of those new systems to the cloud. Handling such automated repair well should be a key criterion when picking the platform to use. 

Repair applies to applications, as well. As demonstrated by the Equifax breach, a vulnerable application library (in that case, a remote command execution in the Java Struts2 library) can cause as much damage as an OS dependency, and it won't be fixed by patching the underlying server. The steps are similar as well — automate tracking of newly disclosed vulnerabilities, repackage (in this case, rebuild) and roll out the new version.

The key distinction between app and platform lies in where this process takes place. Most developers are uncomfortable rolling out a library update without going through their automated testing, implying that this tracking should occur earlier in the dev process, integrated into your source control (e.g., GitHub, BitBucket, or GitLab), or as part of your continuous integration and continuous delivery/deployment (CI/CD).

Repave
The last-but-not-least R is repave. The original repave concept involves recreating servers frequently in case they've been compromised, removing the risk of a compromised server causing damage. Smith suggests switching from boasting about how long our servers can run to how quickly we can shut them down.

This concept doesn't really apply to apps, as code always needs some server to run on (even if you're using "serverless" computing). Frequent repaving of the underlying server would also help deal with servers compromised via an app-layer vulnerability. However, I suggest replacing this R with a new one: readjust.

Readjust/Divide and Conquer
Cloud-native applications take great advantage of microservices. In addition to being easier to maintain, they make our systems more flexible, as we use the same services in different constellations and execution paths, creating new business value with far less effort. Cloud-native platforms typically support locking down the permissions of each microservice individually, granting it only the permissions it needs to get the job done.

Unfortunately, maintaining granular permissions across many applications is hard, so developers reuse the same policies and credentials in multiple applications to lessen the load. This means each policy and service account needs to have the total permissions each microservice needs to operate — far more than what an individual policy would have allowed. To make things worse, it's not clearly known which app needs each permission in the policy, so it's hard to make them stricter over time.

To successfully mitigate the damage a compromised microservice can cause, make sure you regularly readjust the permissions to the minimum necessary for each. Doing so with cross-service policies will be hard, so I recommend requiring that each microservice maintains its own policy and credentials, making such constant adjustments feasible.

Switching to a cloud-native platform may be scary, as it shuffles your priorities. However, if this is done well, you can use the increase in automation and greater speed to your advantage and make both the platform and the apps running on it more secure.

Related Content:

Guy Podjarny is CEO & Co-Founder at Snyk.io, focusing on securing the Node.js and npm world. Guy was previously CTO at Akamai, founded Blaze.io (acquired by Akamai), helped build the first Web app firewall and security code analyzer, and was in the Israeli army cyber units. ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
The Mainframe Is Seeing a Resurgence. Is Security Keeping Pace?
Ray Overby, Co-Founder & President at Key Resources, Inc.,  8/15/2019
The Flaw in Vulnerability Management: It's Time to Get Real
Jim Souders, Chief Executive Officer at Adaptiva,  8/15/2019
Tough Love: Debunking Myths about DevOps & Security
Jeff Williams, CTO, Contrast Security,  8/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5638
PUBLISHED: 2019-08-21
Rapid7 Nexpose versions 6.5.50 and prior suffer from insufficient session expiration when an administrator performs a security relevant edit on an existing, logged on user. For example, if a user's password is changed by an administrator due to an otherwise unrelated credential leak, that user accou...
CVE-2019-6177
PUBLISHED: 2019-08-21
A vulnerability reported in Lenovo Solution Center version 03.12.003, which is no longer supported, could allow log files to be written to non-standard locations, potentially leading to privilege escalation. Lenovo ended support for Lenovo Solution Center and recommended that customers migrate to Le...
CVE-2019-10687
PUBLISHED: 2019-08-21
KBPublisher 6.0.2.1 has SQL Injection via the admin/index.php?module=report entry_id[0] parameter, the admin/index.php?module=log id parameter, or an index.php?View=print&id[]= request.
CVE-2019-11601
PUBLISHED: 2019-08-21
A directory traversal vulnerability in remote access to backup & restore in earlier versions than ProSyst mBS SDK 8.2.6 and Bosch IoT Gateway Software 9.2.0 allows remote attackers to write or delete files at any location.
CVE-2019-11602
PUBLISHED: 2019-08-21
Leakage of stack traces in remote access to backup & restore in earlier versions than ProSyst mBS SDK 8.2.6 and Bosch IoT Gateway Software 9.2.0 allows remote attackers to gather information about the file system structure.