The 12 Most Critical Risks for Serverless Applications

By Sean Heide, CSA Research Analyst and Ory Segal, Israel Chapter Board Member

12 Most Critical Risks for Serverless Applications 2019 report cover

When building the idea and thought process around implementing a serverless structure for your company, there are a few key risks one must take into account to ensure the architecture is gathering proper controls when speaking to security measures and how to adopt a program that can assist in maintaining the longevity of applications. Though this is a list of 12 highlighted risks that are deemed the most occurring, there should always be the idea that other potential risks need to be treated just the same.

Serverless architectures (also referred to as “FaaS,” or Function as a Service) enable organizations to build and deploy software and services without maintaining or provisioning any physical or virtual servers. Applications made using serverless architectures are suitable for a wide range of services and can scale elastically as cloud workloads grow. As a result of this wide array of off-site application structures, it opens up a string of potential attack surfaces that take advantage of vulnerabilities spanning from the use of multiple APIs and HTTP.

From a software development perspective, organizations adopting serverless architectures can focus instead on core product functionality, rather than the underlying operating system, application server or software runtime environment. By developing applications using serverless architectures, users relieve themselves from the daunting task of continually applying security patches for the underlying operating system and application servers. Instead, these tasks are now the responsibility of the serverless architecture provider. In serverless architectures, the serverless provider is responsible for securing the data center, network, servers, operating systems, and their configurations. However, application logic, code, data, and application-layer configurations still need to be robust—and resilient to attacks. These are the responsibility of application owners.

While the comfort and elegance of serverless architectures is appealing, they are not without their drawbacks. In fact, serverless architectures introduce a new set of issues that must be considered when securing such applications, including increased attack surface, attack surface complexity, inadequate security testing, and traditional security protections such as firewalls.

Serverless application risks by the numbers

Today, many organizations are exploring serverless architectures, or just making their first steps in the serverless world. In order to help them become successful in building robust, secure and reliable applications, the Cloud Security Alliance’s Israel Chapter has drafted the “The 12 Most Critical Risks for Serverless Applications 2019.” This new paper enumerates what top industry practitioners and security researchers with vast experience in application security, cloud and serverless architectures believe to be the current top risks, specific to serverless architectures

Organized in order of risk factor, with SAS-1 being the most critical, the list breaks down as the following:

  • SAS-1: Function Event Data Injection
  • SAS-2: Broken Authentication
  • SAS-3: Insecure Serverless Deployment Configuration
  • SAS-4: Over-Privileged Function Permissions & Roles
  • SAS-5: Inadequate Function Monitoring and Logging
  • SAS-6: Insecure Third-Party Dependencies
  • SAS-7: Insecure Application Secrets Storage
  • SAS-8: Denial of Service & Financial Resource Exhaustion
  • SAS-9: Serverless Business Logic Manipulation
  • SAS-10: Improper Exception Handling and Verbose Error Messages
  • SAS-11: Obsolete Functions, Cloud Resources and Event Triggers
  • SAS-12: Cross-Execution Data Persistency

In developing this security awareness and education guide, researchers pulled information from such sources as freely available serverless projects on GitHub and other open source repositories; automated source code scanning of serverless projects using proprietary algorithms; and data provided by our partners, individual contributors and industry practitioners.

While the document provides information about what are believed to be the most prominent security risks for serverless architectures, it is by no means an exhaustive list. Interested parties should also check back often as this paper will be updated and enhanced based on community input along with research and analysis of the most common serverless architecture risks.

Thanks must also be given to the following contributors, who were involved in the development of this document: Ory Segal, Shaked Zin, Avi Shulman, Alex Casalboni, Andreas N, Ben Kehoe, Benny Bauer, Dan Cornell, David Melamed, Erik Erikson, Izak Mutlu, Jabez Abraham, Mike Davies, Nir Mashkowski, Ohad Bobrov, Orr Weinstein, Peter Sbarski, James Robinson, Marina Segal, Moshe Ferber, Mike McDonald, Jared Short, Jeremy Daly, and Yan Cui.

CVE and Cloud Services, Part 2: Impacts on Cloud Vulnerability and Risk Management

By Victor Chin, Research Analyst, Cloud Security Alliance, and Kurt Seifried, Director of IT, Cloud Security Alliance

Internet Cloud server cabinet

This is the second post in a series, where we’ll discuss cloud service vulnerability and risk management trends in relation to the Common Vulnerability and Exposures (CVE) system. In the first blog post, we wrote about the Inclusion Rule 3 (INC3) and how it affects the counting of cloud service vulnerabilities. Here, we will delve deeper into how the exclusion of cloud service vulnerabilities impacts enterprise vulnerability and risk management.

 

Traditional vulnerability and risk management

CVE identifiers are the linchpin of traditional vulnerability management processes. Besides being an identifier for vulnerabilities, the CVE system allows different services and business processes to interoperate, making enterprise IT environments more secure. For example, a network vulnerability scanner can identify whether a vulnerability (e.g. CVE-2018-1234) is present in a deployed system by querying said system.

The queries can be conducted in many ways, such as via a banner grab, querying the system for what software is installed, or even via proof of concept exploits that have been de-weaponized. Such queries confirm the existence of the vulnerability, after which risk management and vulnerability remediation can take place.

Once the existence of the vulnerability is confirmed, enterprises must conduct risk management activities. Enterprises might first prioritize vulnerability remediation according to the criticality of the vulnerabilities. The Common Vulnerability Scoring System (CVSS) is one way on which the triaging of vulnerabilities is based. The system gives each vulnerability a score according to how critical it is, and from there enterprises can prioritize and remediate the more critical ones. Like other vulnerability information, CVSS scores are normally associated to CVE IDs.

Next, mitigating actions can be taken to remediate the vulnerabilities. This could refer to implementing patches, workarounds, or applying security controls. How the organization chooses to address the vulnerability is an exercise of risk management. They have to carefully balance their resources in relation to their risk appetite. But generally, organizations choose risk avoidance/rejection, risk acceptance, or risk mitigation.

Risk avoidance and rejection is fairly straightforward. Here, the organization doesn’t want to mitigate the vulnerability. At the same time, based on information available, the organization determines that the risk the vulnerability poses is above their risk threshold, and they stop using the vulnerable software.

Risk acceptance refers to when the organization, based on information available, determines that the risk posed is below their risk threshold and decides to accept the risk.

Lastly, in risk mitigation, the organization chooses to take mitigating actions and implement security controls that will reduce the risk. In traditional environments, such mitigating actions are possible because the organization generally owns and controls the infrastructure that provisions the IT service. For example, to mitigate a vulnerability, organizations are able to implement firewalls, intrusion detection systems, conduct system hardening activities, deactivate a service, change the configuration of a service, and many other options.

Thus, in traditional IT environments, organizations are able to take many mitigating actions because they own and control the stack. Furthermore, organizations have access to vulnerability information with which to make informed risk management decisions.

Cloud service customer challenges

Compared to traditional IT environments, the situation is markedly different for external cloud environments. The differences all stem from organizations not owning and controlling the infrastructure that provisions the cloud service, as well as not having access to vulnerability data of cloud native services.

Enterprise users don’t have ready access to cloud native vulnerabilities because there is no way to officially associate the data to cloud native vulnerabilities as CVE IDs are not generally assigned to them. Consequently, it’s difficult for enterprises to make an informed, risk-based decision regarding a vulnerable cloud service. For example, when should an enterprise customer reject the risk and stop using the service or accept the risk and continue using the service.

Furthermore, even if CVE IDs are assigned to cloud native vulnerabilities, the differences between traditional and cloud environments are so vast that vulnerability data which is normally associated to a CVE in a traditional environment is inadequate when dealing with cloud service vulnerabilities. For example, in a traditional IT environment, CVEs are linked to the version of a software. An enterprise customer can verify that a vulnerable version of a software is running by checking the software version. In cloud services, the versioning of the software (if there is one!) is usually only known to the cloud service provider and is not made public. Additionally, the enterprise user is unable to apply security controls or other mitigations to address the risk of a vulnerability.

This is not saying that CVEs and the associated vulnerability data are useless for cloud services. Instead, we should consider including vulnerability data that is useful in the context of a cloud service. In particular, cloud service vulnerability data should help enterprise cloud customers make the important risk-based decision of when to continue or stop using the service.

Thus, just as enterprise customers must trust cloud service providers with their sensitive data, they must also trust, blindly, that the cloud service providers are properly remediating the vulnerabilities in their environment in a timely manner.

The CVE gap

With the increasing global adoption and proliferation of cloud services, the exclusion of service vulnerabilities from the CVE system and the impacts of said exclusion have left a growing gap that the cloud services industry should address. This gap not only impacts enterprise vulnerability and risk management but also other key stakeholders in the cloud services industry.

In the next post, we’ll explore how other key stakeholders are affected by the shortcomings of cloud service vulnerability management.

Please let us know what you think about the INC3’s impacts on cloud service vulnerability and risk management in the comment section below, or you can also email us.

CVE and Cloud Services, Part 1: The Exclusion of Cloud Service Vulnerabilities

By Kurt Seifried, Director of IT, Cloud Security Alliance and Victor Chin, Research Analyst, Cloud Security Alliance

The vulnerability management process has traditionally been supported by a finely balanced ecosystem, which includes such stakeholders as security researchers, enterprises, and vendors. At the crux of this ecosystem is the Common Vulnerabilities and Exposures (CVE) identification system. In order to be assigned an ID, vulnerabilities have to fulfill certain criteria. In recent times, these criteria have become problematic as they exclude vulnerabilities in certain categories of IT services that are becoming more and more common.

This is the first in a series of blogposts that will explore the challenges and opportunities in enterprise vulnerability management in relation to the increasing adoption of cloud services.

Common Vulnerabilities and Exposures

CVE® is a list of entries, each containing an identification number, a description, and at least one public reference for publicly known cybersecurity vulnerabilities[1].

CVEs are identifiers for security vulnerabilities that are—or are expected to become—public. Traditionally, they are assigned by one of two entities: The CNA (CVE Numbering Authority) that exists specifically for that piece of software (e.g. Microsoft, which covers Microsoft software) or a CNA that has been given coverage of said software (e.g. The Debian Project, Distributed Weakness Filing Project, and Red Hat all cover Open Source software to varying degrees). These CVEs are then published in the MITRE CVE database. Finally, they are consumed and republished by other organizations, often with additional information such as workarounds or fixes which makes tracking and remediating those vulnerabilities possible.

Customers of companies or organizations that are CNAs for their own products can be reasonably assured that CVE IDs are assigned to historical, current and future vulnerabilities found in those products.

CVE and Vulnerability Management

The CVE system is the linchpin of the vulnerability management process, as its widespread use and adoption allows different services and business processes to interoperate. The system provides a way for specific vulnerabilities to be tracked via the assignment of IDs. Enterprises, security researchers, penetration testers, software providers and even vulnerability scanning tools all use CVE IDs to track vulnerabilities in products. These IDs also allow important information regarding a vulnerability to be associated with it such as workarounds, vulnerable software versions, and Common Vulnerability Scoring System (CVSS) scores. Without the CVE system, it becomes difficult to track vulnerabilities in a way that allows the different stakeholders and their tools to interoperate.

Example of CVE and other associated information
Fig 1: Example of CVE and other associated information taken from CVEdetails.com (https://www.cvedetails.com/cve/CVE-2007-0994/)

CVE Inclusion Rules and Limitations

The decision to assign an ID to a vulnerability is governed by the Inclusion Rules. In order to assign a CVE ID to a vulnerability, the assigner has to take the vulnerability through the Inclusion Rules. Generally, only a vulnerability that fulfills all five criteria will be assigned an ID. For example, one of the Inclusion rules, INC3, states that a vulnerability should only be assigned a CVE ID if it is customer-controlled or customer-installable. A vulnerability in a Customer Relationship Management (CRM) software that is installed on a server owned and managed by an enterprise fulfills that requirement.

CVE Inclusion Rule INC3
Fig 2: Inclusion Rule INC3 taken from cve.mitre.org (https://cve.mitre.org/cve/editorial_policies/counting_rules.html)

INC3, as it is currently worded, is problematic for a world that is increasingly dominated by cloud services. In the past, this inclusion rule has worked well for the IT industry as most enterprise IT services have generally been provisioned with infrastructure owned by the enterprise. However, with the proliferation of cloud services, this particular rule has created a growing gap for enterprise vulnerability management. This is because cloud services, as we currently understand them, are not customer controlled. As a result, vulnerabilities in cloud services are generally not assigned CVE IDs. Information such as workarounds, affected software or hardware versions, proof of concepts, references and patches are not available as this information is normally associated to a CVE ID. Without the support of the CVE system, it becomes difficult, if not impossible, to track and manage vulnerabilities.

Conclusion

The Cloud Security Alliance and the CVE board are currently exploring solutions to this problem.

One of the first tasks is to obtain industry feedback regarding a possible modification of INC3 to take into account vulnerabilities that are not customer-controlled. Such a change would officially put cloud service vulnerabilities in the scope of the CVE system. This would not only allow vulnerabilities to be properly tracked, it would also enable important information to be associated with a service vulnerability.

Please let us know what you think about a change to INC3 and the resulting impact on the vulnerability management ecosystem in the comment section below or you can also email us.

Stay tuned for our next blog post where we will explore the impacts that the current Inclusion Rules have on enterprise vulnerability management.

[1] https://cve.mitre.org/

CSA Releases New Whitepaper on Virtualization Security Best Practices

At this year’s RSA Conference, the Cloud Security Alliance released a new whitepaper entitled: “Best Practices for Mitigating Risks in Virtualized Environments” which provides guidance on the identification and management of security risks specific to compute virtualization technologies that run on server hardware.

The whitepaper was developed by CSA’s Virtualization Working Group which is co-chaired by Kapil Raina, of Elastica, and
Kelvin Ng of Nanyang Polytechnic and sponsored by TrendMicro. The 35 page paper identifies 11 core risks related to virtualization, including:

  1. VM Sprawl
  2. Sensitive Data within a VM
  3. Security of Offline and Dormant VMs
  4. Security of Pre-Configured (Golden Image) VM / Active VMs
  5. Lack of Visibility Into and Controls Over Virtual Networks
  6. Resource Exhaustion
  7. Hypervisor Security
  8. Unauthorized Access to Hypervisor
  9. Account or Service Hijacking Through the Self-Service Portal
  10. Workload of Different Trust Levels Located on the Same Server
  11. Risk Due to Cloud Service Provider API

The report is free and can be downloaded in full here.

 

 

 

 

The Dark Side of Big Data: CSA Opens Peer Review Period for the “Top Ten Big Data and Privacy Challenges” Report

moonBig Data seems to be on the lips of every organization’s CXO these days. By exploiting Big Data, enterprises are able to gain valuable new insights into customer behavior via advanced analytics. However, what often gets lost amidst all the excitement are the very real and many security and privacy issues that go hand in hand with Big Data.  Traditional security schemes mechanisms were simply never designed to deal with the reality of Big Data, which often relies on distributed, large-scale cloud infrastructures, a diversity of data sources, and the high volume and frequency of data migration between different cloud environments.

To address these challenges, the CSA Big Data Working Group released an initial report, The Top 10 Big Data Security and Privacy Challenges at CSA Congress 2012, It was the first such industry report to take a holistic view at the wide variety of big data challenges facing enterprises. Since this time, the group has been working to further its research, assembling detailed information and use cases for each threat.  The result is the first Top 10 Big Data and Privacy Challenges report and, beginning today, the report is open for peer review during which CSA members are invited to review and comment on the report prior to its final release. The 35-page report outlines the unique challenges presented by Big Data through narrative use cases and identifies the dimension of difficulty for each challenge.

The Top 10 Big Data and Privacy Challenges have been enumerated as follows:

  1. Secure computations in distributed programming frameworks
  2. Security best practices for non-relational data stores
  3. Secure data storage and transactions logs
  4. End-point input validation/filtering
  5. Real-time security monitoring
  6. Scalable and composable privacy-preserving data mining and analytics
  7. Cryptographically enforced data centric security
  8. Granular access control
  9. Granular audits
  10. Data provenance

The goal of outlining these challenges is to raise awareness among security practitioners and researchers so that industry wide best practices might be adopted to addresses these issues as they continue to evolve. The open review period ends March 18, 2013.  To review the report and provide comments, please visit https://interact.cloudsecurityalliance.org/index.php/bigdata/top_ten_big_data_2013 .

Tweet this: The Dark Side of Big Data: CSA Releases Top 10 Big Data and Privacy Challenges Report. http://bit.ly/VHmk0d

CSA Releases CCM v 3.0

The Cloud Security Alliance (CSA) today has released a draft of the latest version of the Cloud Control Matrix, CCM v3.0. This latest revision to the industry standard for cloud computing security controls realigns the CCM control domains to achieve tighter integration with the CSA’s “Security Guidance for Critical Areas of Focus in Cloud Computing version 3” and introduces three new control domains. Beginning February 25, 2013 the draft version of CCM v3.0 will be made available for peer review through the CSA Interact website with the peer review period closing March 27, 2013, and final release of CCM v3.0 on April 1, 2013.

The three new control domains; “Mobile Security”, “Supply Change Management, Transparency and Accountability”, and “Interoperability & Portability” address rapidly expanding methods cloud data is accessed, the need for ensuring due care is taken in the cloud providers supply chain, and the minimization of service disruptions in the face of a change to cloud provider relationship.

The “Mobile Security” controls are built upon the CSA’s “Security Guidance for Critical Areas of Mobile Computing, v1.0” and are the first mobile device specific controls incorporated into the Cloud Control Matrix.

The “Supply Change Management, Transparency and Accountability” control domain seeks to address risks associated with governing data within the cloud while the “Interoperability & Portability” brings to the forefront considerations to minimize service disruptions in the face of a change in a cloud vendor relationship or expansion of services.

The realigned control domains have also benefited through changes in language to improve the clarity and intent of the control, and, in some cases, realigned within the expanded control domains to ensure the cohesiveness within each control domain and minimize overlap.

The draft of the Cloud Control Matrix can be downloaded from the Cloud Security Alliance website and the CSA welcomes peer review through the CSA Interact website.

The CSA invites all interested parties to participate in the peer review and the CSA Cloud Controls Matrix Working Group Meeting to be held during the week of the RSA Conference, at 4pm PT on February 28, 2013, at the Sir Francis Drake Hotel
Franciscan Room
450 Powell St in San Francisco, CA.

Your Chance to Influence Cloud Security Research!

By Zenobia Godschalk

The Cloud Security Alliance needs your help! We are conducting a survey to help us better understand users current cloud deployment plans and biggest areas of security and compliance concern. The feedback generated here will assist the CSA in shaping our educational curriculum and areas of guidance over the coming months. So, if you’re concerned about cloud security, let your voice be heard!

http://www.surveymonkey.com/s.aspx?sm=VqH8jHHwc9GhANj3EzDl1g_3d_3d

(Survey takes just a few minutes, and you will receive a complimentary copy of the results)

Cloud Security and Privacy book by CSA founding members

By Jim Reavis

I wanted to let everyone know about the new book release, Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance. This book was written by three experts, two of whom are CSA founding members. I had the opportunity to read the book prior to its publication and I can personally recommend it as a great resource for those seeking to learn about and securely adopt cloud computing. The book URL is below:

http://oreilly.com/catalog/9780596802769/