Few things can boil the blood of a security professional quite like the unforced error. It is a common term used in tennis, referencing a mistake attributed to a player’s own failure versus the skill or effort of their opponent.
In cybersecurity, the unforced error is better known as the misconfiguration. This occurs when security settings, typically involving a server or web application, are set up improperly or left insecure.
This leaves the system vulnerable to attack and furthers the path of least resistance for the bad guys. Considering the increasing sophistication of cyber threats and the ever-expanding attack surface available to your foes, you need not be an infosec veteran to know that your adversaries require no additional help accomplishing their goals.
Security misconfigurations rank No. 6 on OWASP’s “Top 10 Web Application Security Risks” list and are “commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information.”
The misconfiguration risk is only rising, especially amid the rise in public cloud computing adoption, whose benefits have become especially stark during the COVID-19 crisis and the subsequent work-from-home binge. Cloud demand has risen across Amazon Web Services (AWS) – which controls roughly half the market share – as well as Microsoft Azure and Google Cloud Platform (GCP), through the rapid adoption of online collaboration tools and other cloud resources.
A recent survey by Check Point determined that misconfigurations are the top threat to cloud security, with three-quarters of respondents saying they are “very” or “extremely” concerned about cloud security and 68% naming misconfigurations as their biggest cloud worry. Their concerns are not unfounded.
Cloud misconfigurations were responsible for potentially exposing an estimated 33.4 billion records in 2018 and 2019, victimizing high-profile organizations and costing organizations some $5 trillion. Considering many misconfigurations go unreported, the figures are likely significantly larger. And not only are misconfigurations obvious harbingers of data exposure, they also can present the ideal foothold to launch a more complex (and potentially more devastating) attack on an organization.
Recommendations for addressing cloud security misconfigurations
This is by no means an exhaustive list, but can serve as a reliable encapsulation of agreed-upon advice among experts:
- Know your cloud environments and define a security foundation. AWS, for example, provides downloadable readiness assessment and security architecture frameworks.
- Review access controls to ensure only authorized users can take action on specified cloud resources. This includes ensuring IAM policies are properly implemented, for example bucket policies on storage accounts inside of Amazon S3.
- Enforce the principle of least privilege by only giving your users the permissions they need to do their jobs. Consider setting up multifactor authentication and single sign-on for extra layers of security.
- Implement logging, which can identify changes to your cloud environments and help determine the extent of an incident.
- Enable AWS blocking of public access for S3 buckets. Separate objects into different buckets based on access controls (e.g. public versus private).
- Take advantage of free tools to diagram and analyze your cloud environments and perform best practice assessments and audits. These include CloudMapper, Prowler and Scout Suite, and many more exist.
- Much of this work can be automated, and AWS offers a service known as Macie designed to discover misconfigurations on S3 accounts, as well as data that shouldn’t be in them.
Response is critical: A case study
At the end of the day, the stats do not lie. Misconfigurations are inevitably going to happen, so the key will be limiting their time of exposure and reducing mean time to detect and respond (MTTD/MTTR). This can be accomplished with the help of automated remediation in concert with security orchestration, automation and response (SOAR).
For example, Check Point CloudGuard Dome9 users gain visibility, control, and compliance across all cloud assets to manage cloud security posture and detect and remediate misconfigurations from a single source of network authority.
Meanwhile, the Siemplify SOAR platform integrates with CloudGuard Dome9 to enable enrichment of alerts by integrating data from other Check Point tools, such as ThreatCloud and data from third-party tools such as Azure Active Directory. This integration allows analysts to investigate alerts from CloudGuard Dome9 and implement playbooks that automate remediation from a single console, saving your team time and effort.
Learn more about remote security operations and how Siemplify can help with A Technical Guide to Remote Security Operations, or begin test driving the SOAR platform today through a free trial or by downloading the Siemplify Community Edition.
Dan Kaplan is director of content at Siemplify.