Lessons in Multi-Cloud Security
By Dave Row, VP of Security Engineering, BillGO
So, you think you’re a One-Cloud Organization?
Monitoring Cloud Security can be daunting. Each Cloud Service Provider (eg. AWS, Azure, and GCP) offers native tools for managing identity, securing services and data, monitoring security controls, and reporting on vulnerabilities. These tools are typically tightly integrated with the respective CSP’s platform. I’ll leave third-party SaaS and PaaS security to another day.
In a single-cloud environment, it is possible to develop a Security Program using native tooling. Basic capabilities are typically available at minor or no additional cost. Even SIEM functionality is typically offered. The downside is being locked into the Provider’s GUI, API, and specific approach to addressing security challenges.
However, many organizations quickly find themselves in a multi-cloud scenario, possibly through acquisition or from a senior leader that decided to run out to another Provider, to implement their favorite application from lives past. What happens to your Security Program then? How quickly will you be able to upskill your staff to get your arms around the new environment? Will this week’s compliance report still run and report across the entire space? What about updating all those documented processes? Conversely, it could be as easy as granting your Cloud Security platform access to the new environment and possibly deploying a new agent. For the Security folks, the latter scenario seamlessly extends familiar monitoring, reporting, investigation, and vulnerability management tooling and processes. This quickly instills confidence in coverage and security posture, even when you need to put out a few dumpster fires in the new environment.
One terrific benefit of a multi-cloud security platform is the ability to easily demonstrate compliance with various standards (eg. CIS, ISO 27001, NIST, PCI, and SOC 2), as well as vulnerability management.
Logging
Developing a logging architecture becomes increasingly important when you begin to accumulate multiple accounts/subscriptions for a single Cloud Provider. This becomes non-negotiable when multiple clouds are in play. This is vital for ensuring that all environments are covered, logging levels are sufficient and appropriate, and costs are controlled. A Logging Standard can be a great tool to document what types of resources are expected to log and what event types should be logged, at what level, to where, and retained for how long. If you think of this as an upside-down funnel, you have resources at the bottom that generate events.
Your Logging Standard should dictate what type of security, health, application, and other operational events should be generated. Those logs could then be viewed with cloud-native tools, collected for analysis elsewhere by scripts, made available to Cloud Security platforms (eg. Lacework or PrismaCloud) for analysis, and/or sent to a SIEM for correlation and/or alerting your SOC partner. The key is full situational awareness and the frugality to only send events and alerts to systems and people that can analyze and act upon them. Otherwise, you’re wasting money on log storage and likely over-provisioning the corresponding analysis platform.
SIEMs need to fill a different role
Speaking of SIEMs, their traditional role has been to sit on top of log data, to alert on specific events, or to produce new alerts based upon the correlation of multiple log events. Historically, this required lots of care and feeding by very technical Security experts, in a never-ending quest to devise the right trap for the yet-to-be-seen mouse. Also, it required the SIEM to have access to all log data, to avoid missing certain attacks. This can be incredibly expensive. Fast-forward to the present and we have lots of great analysis happening natively and great Cloud Security platforms that can run machine-learning algorithms to detect behavioral abnormalities that native tools, SIEMs, and your teams’ eyeballs would likely miss. On the balance, it’s OK to let your native tooling and/or Cloud Security platform do much of this correlation, only then forwarding alerts of interest to the SIEM. In short, the SIEM is no longer the source of all insight into your log data. This is also a more cost-effective option than logging the same data in multiple places.
Compliance
One terrific benefit of a multi-cloud security platform is the ability to easily demonstrate compliance with various standards (eg. CIS, ISO 27001, NIST, PCI, and SOC 2), as well as vulnerability management. Holistic Cloud Security platforms help to do this consistently across multiple environments.
One special note on traditional “vulnerability scanners:” There was a time when we needed to scan our resources across the network, in order to detect vulnerabilities. This had lots of limitations, costs, and overhead. For example, network segmentation often required multiple scanners to be purchased and deployed, external views of assets did not reveal all vulnerabilities, and some unlucky person got the privilege of ensuring that all assets were being scanned at the right interval with the right scanner and the right scanner profile. This intense fun leads to credentialled scans and then to agent-based scans (i.e. the best position to detect vulnerabilities is directly on the host). With hosts in the cloud, there’s the fantastic native capability to detect OS-level vulnerabilities, but you still want to manage those with a single pane of glass. For example, Security must uniformly drive these vulnerabilities – including recommended remediation steps – and security policy misconfigurations back to the resource owners for remediation.
Another note on “Endpoint Security:” The right Cloud Security platform can do a decent job here, typically for OS-level vulns, but there are Endpoint Security solutions that are poised to dominate this space in the cloud, offering deeper insights into vulnerabilities, including the potential to be exploited. Solutions in this space include Crowdstrike, Cybereason, SentinelOne, and Tanium. The best solutions combine real-world threat intel (eg. attacks observed in the wild and difficulty to exploit) to inform which patches or other remediation is needed first.
Real-world investigations
When you have an alert to investigate, you need it to be trustworthy. One particular area to watch is how solutions deal with hosts being re-deployed with the same IP address, but with an entirely different role. If you tend to recycle IP addresses, do yourself a favor and really test the ability of solutions to know which host was running which service at a given time vs. munging that all together. This is critical. In the container world, services move fluidly between clusters. IP addresses mean virtually nothing. Also, be sure to understand how a solution differentiates between when something was detected and whether it has been remediated. This requires understanding when reports are generated and how timely the threat or vulnerability info is; It’s no fun to encourage someone to patch when the vuln was remediated weeks ago.
Automation is Key
If you want to interrupt the attacker’s OODA Loop, you must have automated responses to a variety of alerts. This requires 1) high-confidence alerts and 2) runbooks to guide the response process. SOAR platforms have fantastic potential, but if you can’t manually respond, you’ll never be able to automatically respond. In the meantime, the time spent doing alert enrichment and analysis will only benefit the attacker.
In Closing We’ve touched upon a wide variety of considerations in this article. The most important thing to note is that you need to think through prevention, detection, and response so that it’s as all-encompassing, consistent across multiple Cloud Providers, and as efficient and automated as possible. Pulling together cloud-native, multi-cloud, and Incident Response capabilities as tightly as possible is key. Demonstrating compliance in one pane of glass is priceless. Now, get crackin’! ?