A developer’s ally in the battle against security bugs

Cisco Cloud Application Security finds vulnerabilities and recommends ways to fix them.

Cloud application security provides a unified set of policies and practices to protect cloud-based software by monitoring, prioritizing, and supporting remediation of vulnerabilities across the whole development lifecycle. As hybrid and multi-cloud environments become the enterprise norm, Cloud Application Security delivers an adaptable solution for organizations’ evolving security needs and insight developers can use to target application risk - without stalling development itself.

That’s critical since cloud applications are the future of digital business. Indeed by 2025, organizations will be running more than 750 million cloud-native applications, nearly three times as many as they are running today. ^1 By then, according to Gartner, Inc., more than 85% of organizations will have adopted cloud-native development principles ^2, redefining application architecture standards and the security practices required to protect these new environments.

After all, cloud-native applications are built differently and require a new approach to security. They

• live on shifting serverless infrastructure, instead of sitting on fixed hardware in a local company-run data center.
• call APIs for functionality, instead of running sub-routines on a static binary file to access app features.
• are designed as small, interdependent services instead of as a big block of code.
• use open-source code, instead of entirely homegrown code.

Cloud-native vulnerabilities and the pitfalls of open-source code

While all this makes cloud-native apps more flexible, resilient, and scalable, the modularity creates an amorphous attack surface that exposes organizations to new vulnerabilities. Where legacy systems had predictable, static boundaries that organizations could surround with security, cloud-native environments generally don’t have any clear or fixed perimeters.

Cloud Application Security is a step-change in security ideology for handling the risks created by all the moving parts and technical seams of cloud-native development. Because there are now hundreds of potential entry points to protect from attackers, instead of a few, Cloud Application Security focuses oversight on code, containers, clusters, APIs and cloud infrastructure, instead of strictly on networks and hardware.

When putting up a firewall was the go-to solution for reinforcing perimeter-based security, businesses tended to underestimate system threats and, therefore, underspend on security. But given the number, scope, and complexity of cyberattacks targeting industry these days, continuing to short-change security comes at a steep price. McKinsey forecasts that by 2025 the cost of global cybercrime will reach $10.5 trillion.^3

Attack vectors and the nature of the risks to cloud applications reflect the services-based approach to building them. Among the risks are application layer attacks, containerized software image threats, cloud and Kubernetes misconfigurations and overly permissive access roles, to name a few. The many APIs of an application are natural targets for accessing valuable digital assets and therefore need their own particular monitoring and policy-safeguard components, which we’ll explore later in this article.

Another big change in cloud-native app development is the growing use of open-source code. While a great time-saver and development accelerator, such reuse can expose organizations to tainted code built into third-party artifacts. That’s tough to monitor, which means organizations without the right tools will, at some point, unwittingly import bad code into applications. In cloud-native development sometimes the danger, to paraphrase a line from a classic horror movie, is coming from inside the house!

Cisco Cloud Application Security coverage

Cisco Cloud Application Security is designed for spotting these dangers wherever they might exist in the application environment. It is an all-in-one security solution that simplifies the detection and remediation of potential cloud security threats from CI/CD to runtime. With it, enterprises can drive security automation throughout the application development process, enabling developers to assess and build security policies from its tooling and to remediate faulty code.

In this new security paradigm, scanning must happen across the entire application environment. This includes artifacts (code fragments); Infrastructure as Code; cloud security posture; infrastructure entitlements and privileges; network configuration, segmentation and policy; Kubernetes security posture; workloads; APIs; and runtime exposures.

Cisco Cloud Application Security brings together multiple utilities to provide this complete-cycle oversight. During the development phase, it scans open-source artifacts using Software Composition Analysis to understand and catalogue the third-party components in use in the application and identify any vulnerabilities. It checks the security of APIs. It also looks at potential exposures in the application using the Common Vulnerabilities and Exposures (CVE) repository, which shares public information on cybersecurity threats. Importantly, too, it enables you to scan Infrastructure as Code (IaC) artifacts for security issues, misconfigurations, and exposed credentials, before the code is deployed into an environment.

During deployment, Cloud Security Posture Management (CSPM) capabilities inventory all cloud assets and identify misconfigurations based on industry standards and cloud best practices. These are part of a cloud configuration hardening suite of features that includes Kubernetes monitoring as well as network configuration and segmentation tools.

At runtime, Cisco Cloud Application Security provides runtime protection through its Cloud Workload Protection Platform (CWPP) capabilities, API scanning and serverless function monitoring. It also constantly checks for new vulnerabilities by referencing CVE and uses other scanning tools.

To learn more about CCAS’s capabilities throughout the development lifecycle, view Five Reasons You Need a CNAPP ASAP

A focus on securing APIs: How Cloud Application Security helps developers

APIs are essential to modern software development. They are pipelines to functionality and application data and the linchpins connecting cloud-native applications. They are also potential entry points for attackers and need to be monitored and secured.

The API Security feature set of Cisco Cloud Application Security gives developers the ability to screen APIs for risk. This includes the option to run a spec analysis job, enter a URL for a third-party API, and provide an API endpoint reachable by the APISec controller to running a fuzzing job on the API. In every case, the tool returns its security findings to help developers make decisions about those APIs that are safe to use in their applications.

APISec also allows the user to set an acceptable security level above which the API would be considered too risky. This test can be run during Continuous Integration, failing those specs and blocking those APIs that aren’t compliant. Another typical use case would be integrating the checks into the Continuous Deployment staging environment, running a fuzz test on the APIs, and alerting against/blocking those that fail.

Here we see the help menu for the APISec tooling showing start commands for the various pieces of functionality (Figure #1).

Figure #1

In this example, a developer is using the APISec tooling to do a scoring job on an open third-party API - in this case the popular OWASP Juice Shop. In Figure #2, we see an excerpt of the spec file to analyze.

Figure #2

To run the scoring job, the developer submits a “start-oas-scoring” command, which runs as a batch process in the SaaS portal of Cloud Application Security. From this we get job information back in JSON and a “Completed” status once the job has finished. (Figure #3)

Figure #3

We can now retrieve the job using the “get” function (Figure #4), which returns in JSON information on the risks that exist in the spec file. This example shows one of many issues returned from the job, in this particular case a “Failure to provide all the status codes” with a description. The issue is labeled as Medium in severity.

With this information, a developer can decide whether to use the scanned API in the application and/or use severity rankings to fail jobs should they violate security rules.

Figure #4

The power of Cisco Cloud Application Security attack path analysis

The all-in-one security posture approach of Cloud Application Security makes it possible to oversee components strategically and model potential exploits and their impact. Cloud Application Security has added attack path analysis, which enables teams to see their systems from the viewpoint of an attacker.

Attack path analysis helps assess risk and identify security weak spots before attacks happen by showing vulnerable entry points and their connections to other system assets. Because security breaches often target multiple environments, it can help identify ways to cut off pathways from vulnerabilities and short-circuit chained attacks.

In this example, we see how an attack can quickly escalate from a single breach point to a series of disruptions across the tech stack.

For developers, attack path analysis supports them in a number of ways. First, it helps with prioritizing fixes to the most vulnerable system entry points and connections. It provides transparency into the channels attackers might follow so that when attacks do happen, it is easier to predict their movements and preempt them with a response. The Attack Path Analysis capability helps developers by suggesting code fixes for vulnerabilities, a time saver for app developers regularly fielding fix tickets from security teams.

Any enterprise-grade attack path analysis solution should meet some standard requirements. It should be comprehensive enough to meet all the organization’s current needs, to avoid tool sprawl. It should be scalable, since environments and architectures will no doubt change over time. It should include robust automation capabilities, because, well, that’s what these tools are for. And its visual representations and reports should be detailed, customizable, and easy to understand.

Attack path example: the case of Jenkins over-permissions

In this example of an attack path analysis, Jenkins, a widely used tool for automating CI/CD pipelines, has been given full administrator rights to the user’s environment. It is an easy and common permissioning decision DevOps teams make for Jenkins since the tool has a wide range of plug-ins and features and performs so many different tasks, like spinning up container environments and virtual machines.

But from a security standpoint, the “anyone-can-do-anything” configuration creates the risk of an attacker gaining control of critical assets and using admin privileges to ride roughshod over them and other parts of the environment. Misconfigurations are one of the major causes of system breaches today.

The best, most secure posture on Jenkins permissioning should be one of least-privilege, allowing permissions only to those resources with which Jenkins needs to interact.

In the attack path visualization shown here, Cloud Application Security identifies the attacker’s way in as public access to the user’s EC2 instance. Once they are inside the EC2 instance, the attacker can tap into the user profile associated with that instance. That profile contains a list of available resources, which is where they’ll find Jenkins and its permissions.

With administrator rights, the attacker could access, provision, or hijack cloud resources like virtual machines for, say, crypto currency mining. They could drop ransomware or plant backdoors onto critical resources and hold the system hostage. They could establish a persistent reverse shell that would remain even after the Jenkins permission is resolved. Or they could tear down applications and infrastructure.

Unsurprisingly, Cloud Application Security recommends that addressing this particular vulnerability is a high priority and, ultimately, shares recommendations on how to fix it. To learn more about the Jenkins vulnerability, see Weaponizing the Utility of Jenkins Script Consoles.

Finding vulnerabilities before they find you

New ways of building applications require new ways of securing them. As organizations lean into ways to prevent security vulnerabilities instead of just fixing them, having tools that can identify, prioritize and suggest remediation for security weaknesses is crucial. For developers, a cloud application security solution can provide tactical and wholistic approaches to plugging vulnerabilities that may threaten the enterprise and, importantly, the high-value business of developing an organization’s digital future.

References

• ^1 IDC IDC Updates Its Future of Digital Innovation Framework; Highlights Role of Technology Suppliers in Helping Businesses Build Value Engines for Sustainable Digital Innovation
• ^2 Gartner 2021 https://www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences
• ^3 McKinsey https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/cybersecurity/new-survey-reveals-2-trillion-dollar-market-opportunity-for-cybersecurity-technology-and-service-providers

Resources

Infographic: Prioritize and remediate cloud application risks with precision

Cisco Cloud Application Security At-A-Glance

Learning Labs

Blog: Thought your Node.js latest Docker image was safe?

Topic Hub: Topic Hub: Full Stack Observability