Cloud security threats require improved IT collaboration, governance, not necessarily new technology

August 15, 2019

Dyslexia mode

Summary:: Migrating your on premise security controls to a completely new cloud environment isn’t enough. Even cloud organisations with years of experience behind them are vulnerable.

As enterprises expand their use of cloud services to include critical business applications and data, the risk of security breaches, such as the one perpetrated on Capital One that I detailed last week, becomes a C-level concern. Heedlessly migrating internal systems designed for on-premises infrastructure and security controls to a radically different cloud architecture, often without fully understanding cloud security features, controls, network design and user responsibilities, is a recipe for disaster. When even organizations like Capital One, with years of AWS experience providing a deep appreciation of the cloud’s technical nuances, can be exploited by a hacker, it’s evident that every cloud user needs to redouble their security efforts. Thankfully, there is an organization like the Cloud Security Alliance (CSA) dedicated to improving the security of cloud environments by developing policies, recommendations and threat research.

As the corporatized version of the DEF CON hacker conference, the Black Hat event has become a required stop for most security vendors and researchers. Like most security conferences, it’s full of scary announcements of previously unknown software vulnerabilities, new attack methods and creative demonstrations of the hacking craft. Unfortunately, like most security events, the preponderance of Black Hat content describes threats and vulnerabilities, not countermeasures and software fixes. CSA follows the script in using the event to release a new report on cloud threats, but counters with another report detailing structural improvements that improve an organization’s security posture by integrating security into the software development and IT operations

First, the threats

Like the Capital One incident demonstrated, using cloud infrastructure and applications opens up new avenues of cyber attack while simultaneously complicating the responsibility for application and data security by splitting responsibility for security policies between the cloud provider and user. While last week’s column focused on the demarcation of responsibilities, a new CSA report highlights the new threat vectors the cloud introduces.

The CSA Top Threats Working Group regularly releases its assessment of the most significant security issues facing enterprise cloud users. Over time, it found that traditional threats to core infrastructure like denial of service attacks or exploits targeting hardware and OS vulnerabilities are so effectively defended by the cloud provider as to be outranked by problems higher in the software stack which, as last week’s column illustrated, are the cloud user’s responsibility. As the introduction to a new CSA report on the top threats to cloud computing notes (emphasis added),

New, highly rated items in the survey are more nuanced and suggest a maturation of the consumer’s understanding of the cloud. These issues are inherently specific to the cloud and thus indicate a technology landscape where consumers are actively considering cloud migration. Such topics refer to potential control plane weaknesses, metastructure and applistructure failures, and limited cloud visibility. This new emphasis is markedly different from more generic threats, risks and vulnerabilities (i.e. data loss, denial of service) that featured more strongly in previous Top Threats reports.”

The working group ranked what it brainstormed to be the 19 most prominent cloud security threats using the Microsoft STRIDE threat model to analyze each issue’s scope and significance across six threat categories. The result is what the group calls the Egregious Eleven, which are ranked as follows in order of significance.

1. Data Breaches such as the Capital One incident in which “sensitive, protected or confidential information is released, viewed, stolen or used by an unauthorized individual.”

2. Misconfiguration and inadequate change control resulting from set up errors that leave cloud resources ‘vulnerable to malicious activity.”

3. Lack of cloud security architecture and strategy that result in IT departments not understanding their role in cloud security (see last week’s column) or carelessly migrating existing on-premises applications to cloud infrastructure without adapting it to the new security environment.

4. Insufficient identity, credential, access and key management that occur from not fully understanding the cloud identity and access management (IAM) services and controls and inadequately protecting cloud credentials by, for example, frequently rotating cryptographic keys, passwords and certificates.

5. Account hijacking via phishing attacks or stolen credentials (see #4).

6. Insider threat in which someone abuses their authorized access to cloud resources to either maliciously or inadvertently damages systems or expose sensitive data to disrupt operations. Such threats can come from current or former employees, contractors, or trusted business partners.

7. Insecure interfaces and APIs in which poorly configured or designed APIs allow an attacker to misuse applications or access data. As the report details, the interfaces of public-facing cloud systems are under constant attack and, as Capital One found out, often the portal for an attacker to access other, internal vulnerabilities.

8. Weak control plane is an example of not having a well-considered cloud strategy that results in not fully understanding cloud administration, security controls and data flows and improperly adapting existing processes to a markedly different environment.

9. Metastructure and applistructure failures result from weak implementations of APIs and other management interfaces by the cloud provider. According to the CSA report,

The metastructure is considered the CSP/customer line of demarcation—also known as the waterline. … To increase cloud visibility to customers, CSPs have often revealed or allowed API interaction with security processes at the waterline. Immature CSPs are often unsure of how to make APIs available to their customers—and to what extent. For example, APIs that allow customers to retrieve logs or audit system access may include highly sensitive information.

While not at the waterline, the AWS Metadata service used to launch a Server Side Request Forgery (SSRF) is an example of a metstructure failure.

10. Limited cloud usage visibility occurs when IT isn’t fully aware of cloud usage within the organization and thus blind to security problems. The situation occurs when either: (a) employees use cloud applications and/or resources without IT authorization, aka shadow IT, or (b) authorized insiders abusing their access (#6).

11. Abuse and nefarious use of cloud services in which attackers use cloud services to host malware or launch attacks, hiding behind the perceived legitimacy of the cloud provider’s domain name. Threats emanating from cloud infrastructure often include malware storage and propagation, DDoS attack, email spam and phishing campaigns and automated click fraud.

As the CEO and founder of CSA, Jim Reavis points out in an interview, these security issues affect all types of cloud services, including SaaS, not just infrastructure like AWS,

The report is well worth reading in its entirety since it details the business impacts and real world examples of each threat along with the specific cloud controls (from the CSA’s CCM categorization) that address each threat. A companion document analyzes nine newsmaking incidents, showing the source of the threat, its classification, the technical and business ramifications and the CCM controls that could have prevented or mitigated the attack. For example, the following is the summary chart for a data breach at Zynga.

Source: Cloud Security Alliance Report; Top Threats to Cloud Computing: Deep Dive

Weaving security into the application-infrastructure lifecycle

The CSA also released a proactive, advisory report focused on preventing cloud breaches by integrating security into the application lifecycle. The Six Pillars of DevSecOpsbuilds upon the DevOps structure and practices many organizations use to accelerate software development and cloud deployment. The paper contends that (emphasis added),

Putting security directly into DevOps substantially improves outcomes by integrating existing security into development and operational processes through modern integrated security paradigms, such as DevSecOps. … The goal is to reduce the complexity in the development and publication of software, ensure that only known and trusted components and services are used, empower software development teams with security resources (both automated and human) integrated directly into their development methods, use development environments that are well secured and monitored, and ultimately deliver the end-product per design and with only the features it was designed to have.

The report comes from the CSA’s DevSecOps Working Group, which describes itself as dedicated to creating a “transparent and holistic management approach” that synergistically combines development, security and operational functions into a cohesive software lifecycle. The report defines the fundamental characteristics of DevSecOps that further the CSA’s strategy of Reflexive Security. The latter is a process framework that incorporates security across an organization in a way that doesn’t add process overhead and enables the agile response to new and changing threats. For more information on the topic, see another CSA paper, Information Security Management through Reflexive Security: Six Pillars in the Integration of Security, Development and Operations.

Source: RSA Conference Virtual Session: DevSecOps Is A Global Movement, APJ Included

According to the report, the six elements of DevSecOps are:

1. Collective responsibility that eliminates siloed security organizations and makes security integral to business objectives. While the CSO (Cloud Security Officer) leads the effort, everyone, whether business managers, software developers of IT operations people treat security as integral to their jobs.

2. Collaboration and integration which exploits the collective responsibility to encourage pan-organizational information sharing about potential threats, system anomalies, best practices and process or software improvements.

3. Pragmatic implementation also seeks to breakdown organizational silos which often create a hodgepodge of incompatible development tools and niche, point products that don’t work well together, if at all, and end up creating new security holes. Instead, organizations should choose development and management platforms that are broadly applicable and highly integrable.

4. Bridging compliance and development addresses the mismatch between internal security requirements and external compliance regulations that are often poorly aligned. Bridging this gap requires identifying appropriate security controls, translating them into code and processes that can be incorporated into software and operations and ultimately automating them into repeatable actions.

5. Automation increases the repeatability, speed efficiency of security operations by replacing manual, mistake-prone processes with programmatically-controlled recipes.

6. Measure, monitor, report and action seeks to eliminate gaps in security and improve overall coverage by quantitatively measuring application and infrastructure compliance with security policies and standards.

My take

The CSA has played a valuable role in promoting cloud security and establishing a set of guidelines and audit standards that enterprises can use when moving to cloud infrastructure. Its work in identifying cloud security threats, while useful, doesn’t provide clear-cut directions on how cloud users should address them. Mapping each threat to the relevant controls from its audi and controls matrix is a good start, as are the incident cases studies in the CSA’s deep-dive report, but still leaves enterprises to develop solutions on their own. Hopefully, follow up threat reports can provide prevention steps and examples that can be applied to popular cloud platforms.

The DevSecOps is similarly vague and abstract, but at least provides the principles enterprises can incorporate into their IT, software development and DevOps organizations to improve cloud security. While the amalgamated term adds unnecessary jargon to an already jargon-rich field, the notion that security must be immersed in all parts of the software and infrastructure deployment lifecycle is unimpeachable. Sadly, it’s also not new. More than a decade ago, I reviewed the book Geekonomics: The Real Cost of Insecure Software that made the same points.

When it comes to security, IT seems determined to prove the axiom, “Those who do not learn history are doomed to repeat it.” Hopefully, as enterprises migrate to cloud infrastructure and the stakes of insecure systems get astronomically high, organizations will finally absorb the lesson.