Complications in the cloud can have a cascade effect across an organization, leaving cloud-based apps in development at high risk of an attack.
Security professionals have reported a range of concerns — low visibility of cloud assets, trouble with prioritizing risk, insecure APIs and misconfigurations, as well as gaps in expertise — that complicate ongoing efforts to secure cloud workloads. There’s a lot to take in, and some fundamentals that may need to change for cloud-native to work how it was intended.
Cutting through the cloud-native clutter
For organizations looking to embrace cloud-native potential, the path ahead isn’t always clear. To understand how to simplify this journey, it’s good to be aware of the common pitfalls and what to look out for.
#1: The web of acronyms. The cybersecurity community loves attaching acronyms to concepts and products, which hasn’t made for the most accessible marketplace. When it comes to cloud specifically, there’s CWPP [cloud workload protection platform], CNAPP [cloud native app protection platform], CSPM [cloud security posture management], CIEM [cloud infrastructure entitlement management], and CSNS [cloud service network security]. With so many options available, it’s not difficult to see why customers might get lost or overwhelmed in the scramble to secure cloud-native workloads.
#2: Too many cooks in the kitchen. Each of these acronyms denotes a type of solution designed to meet a specific need. But in many cases, these solutions function independently and may not be compatible with or communicate to other cloud products, especially when several vendors are involved. This has resulted in teams having to juggle and manually correlate the data outputs across multiple tools and systems, which can significantly impede business agility.
#3: Noise pollution. Cloud security tools generate massive amounts of data related to all sorts of variables — network logs, identity access and credentials, compliance alerts, vulnerability alerts, configuration data and more. Much of this data is noise in the form of false positives, discovered misconfigurations, or even vulnerabilities that are important but not as important as other more immediate concerns. Security teams have no trouble getting data; the difficulty is understanding how to respond to it and prioritize what really matters.
#4: Getting DevOps right. Cloud-native development isn’t achievable through cloud technology alone. People are integral to cloud-native success, particularly when it comes to putting developers and operations in the same room. However, many organizations continue to treat these teams as separate, resulting in vulnerabilities that are discovered after release and not before.
Improve AppSec with a focus on streamlining cloud-native functions: Setup, Scan, Assess, Remediate
Fortunately, there are ways that organizations can simplify and streamline their transition to cloud-native app development.
#1: Simplify setup and configuration
Deploying vulnerability management and detection across multiple cloud environments and cloud service providers doesn’t have to be arduous. As part of a CNAPP package, vendors like Qualys have begun offering automatic setup so that customers need only establish a single connector to each of their public cloud providers, thereby providing immediate, out-of-the-box support for all organization-wide accounts.
#2: Automate continuous assessment and scanning of cloud inventory
New vulnerabilities can emerge just as quickly as old ones get fixed. There’s no need to play manual ‘whack-a-mole’ when it comes to identifying and assessing health of cloud-native assets. Instead, organizations should consider automating scans and continuously assessing their cloud apps to ensure they are compliant and configured in line with CIS guidelines. A cloud agent can perform these scans routinely and automatically, and then funnel any notable findings back to a centralized dashboard where teams can easily determine the risk and how to respond.
#3: Insight into risk is the goal, not data
Security teams aren’t lacking in data, but time and the bandwidth to take action on this data. Instead of dividing attention and efforts spent addressing individual vulnerabilities, runtime errors, or misconfigurations, organizations should reorganize team operations to focus on aggregating risk intelligence across the multicloud. A CNAPP solution, such as Qualys TotalCloud for example, automatically generates a risk score based on data it collects across the entire cloud inventory. While the score may be tied to any number of telemetries, it means that teams aren’t having to manually sift through and prioritize vulnerabilities themselves. That’s already done on their behalf, so they can immediately direct efforts to items that are most critical.
#4: Empower DevOps to proactively address vulnerabilities using infrastructure-as-code
A primary benefit of going cloud-native is the ability to spin up new applications at much faster speed to meet business demand. But for this agility to work in organizations’ favor, DevOps teams should be given wider reign to proactively address vulnerabilities earlier in the pipeline before builds are released. To simplify remediation, organizations should consider using infrastructure-as-code (or IaC), which enables devs to provision cloud infrastructure automatically through coded templates as opposed to console or command line interfaces. While IaC is not inherently more secure than manual configuration, it gives developers consistency in deploying approved configurations as well as greater flexibility to version code and identify where changes (if any) have been made.
