Advice to Developers: Double-check Configurations to Avoid Cybersecurity Pain

Last month in my API Academy blog I provided my observations and recommendations about the importance of logging and monitoring from a cybersecurity perspective. This month, I’ll focus on the importance of avoiding security misconfigurations when building and updating applications. As I noted last month, I’m a bit of an old salt in security, having started about 45 years ago with mainframes and punch cards.  I’ve had to run fast to keep up with so many tech changes leading to today’s mobile strategies, zero trust and wide use of the cloud. I can’t say I’ve seen it all, but I’ve seen some very bad decisions while investigating just about every type of cyber breach over the last four decades.

Misconfigurations have led to major breaches, particularly in cloud environments. Some notable breaches included the July 2019 theft of more than 100 million Capital One customer records and an April 2019 disclosure of more than 540 million records of Facebook users on publicly accessible cloud servers operated by Mexico based digital platform Cultura Collectiva.

The Open Web Application Security Project (OWASP) lists security misconfiguration as one of the top ten critical security risks. OWASP notes that “attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc. to gain unauthorized access or knowledge of the system.†Examples of security misconfiguration include leaving default or test accounts and credentials in place in production, overly informative error messages, and having unnecessary features installed or enabled. OWASP also notes that security misconfiguration includes “missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services.†It’s this last example that I’ll focus on in this post. In fact, Aite Group’s Top 10 Trends in Cybersecurity for 2020 predicted that cloud misconfigurations will continue to expose sensitive data in 2020 and beyond.

It’s been more than ten years since we first saw cloud computing come on the scene. Companies of all sizes have adopted cloud infrastructures and the cloud has become ubiquitous across all industries and geographies as a viable option to reduce IT overhead. Despite the growing maturity of cloud use, we continue to see significant cybersecurity issues related to misconfiguration of cloud resources. According to the Cloud Security Alliance “misconfiguration occurs when computing assets are set up incorrectly, often leaving them vulnerable to malicious activityâ€. 

One of cloud computing’s major benefits actually contributes to the possibility for misconfiguration and cyber breaches. It is incredibly easy to spin up servers and services in the cloud but locking down these assets can be quite daunting for developers and administrators who do not have intimate knowledge of security controls and attacker capabilities. An often-reported misconfiguration relates to Amazon’s Simple Storage Service (S3) “buckets†when someone inadvertently makes the resource publicly accessible. Attackers are known to scan the internet looking for these misconfigured instances.

Cloud misconfigurations can go well beyond simple access to publicly accessible sensitive data. In October 2019, cyber security company Imperva reported that an attacker was able to find an administrative API key on a misconfigured Amazon production instance. The attacker used this key to access a 2017 database instance containing information related to the company’s customers.

Cloud providers have stepped in to help with tools and automation. In November 2019 Amazon released “Amazon S3 Block Public Accessâ€, a tool that can be used to reveal and remedy bucket misconfigurations. This followed the release in 2018 of a bright orange dashboard indicator which highlighted publicly accessible buckets, but the indicators were apparently still not enough to avoid misconfigurations. Misconfigurations in Microsoft’s Azure cloud are mostly related to role-based access controls, use of two factor authentication and inadvertently overriding default encryption for data at rest. It is also possible to misconfigure Network Security Group (NSG) firewall functions to allow unwanted incoming and outgoing data. Google Cloud can also be misconfigured, and developers and administrators can check for most types of misconfigurations in Security Health Analytics within the Google Cloud Security Command Center.

Yes – avoiding security calamity is part of the developer’s job. It’s my assertion that finding and fixing security misconfigurations should not be expressly the responsibility of the cybersecurity team; this should be a joint effort between developers and security specialists.

Here are some of my recommendations to avoid security misconfigurations:

1. If you have not gotten around to it yet, take a few minutes to read the OWASP Top 10 at https://owasp.org/www-project-top-ten/
2. Take a few more to read the section on security misconfiguration – A6:2017. This section has example attack scenarios and methods to avoid mistakes that can lead to a breach.  
3. If you are developing a cloud-based application or one that’s using cloud storage, use the cloud provider’s recommendations and tools for identifying and fixing security misconfigurations.
4. Make sure that checking for security misconfigurations is included in all application upgrades and patches.
5. Ensure that your QA teams are aware of security misconfiguration risks.  Include checking for security misconfigurations as part of their processes.
6. Make misconfiguration checks a prominent part of your SDLC and define both primary and secondary responsibilities for stamping out these nasty issues.