Cloud security and speed -- how fast do your processes need to be? [Q&A]
Moving to the cloud offers many benefits for businesses, but it doesn't remove the need to keep your systems secure. The tools that make the cloud fast and attractive for business can also be used by attackers.
We spoke to Anna Belak, director, Office of Cybersecurity at Sysdig to discuss the pain points that she sees security teams dealing with today, where those problems come from, and how to address them around process and skills rather than just looking at the tech side.
BN: How are teams dealing with cloud security issues today? Are processes working effectively, or do they have to change?
AB: Cloud security issues must be dealt with at the speed of cloud. Cloud environments were designed to be automated through the use of tools and applications to make development, security, and deployment processes faster and easier. However, attackers can also take advantage of these tools to move faster as they work to deploy their attack payloads before defenders know they're there. In our Global Cloud Threat Report, the Sysdig Threat Research Team found that it only takes ten minutes to stage and launch an attack after gaining initial access to a cloud environment, compared to days or weeks spent on traditional networks. Speed is one of the greatest challenges cloud security teams currently face.
Cloud security teams tend to be more mature in asset scanning and remediation than they are in threat detection and incident response. Given what we've seen in the threat landscape, speedy incident response processes are critically important to the security of a cloud environment.
To achieve this speed, teams must first collect data from multiple data sources, including cloud logs, Linux system calls, and software container telemetry. Then, the data needs to be correlated to provide a wholesome view of the attack and the information gathered can then be used to block or contain the live attack before it is completed. A ten-minute attack timeline provides a benchmark for how quickly security teams have to perform these threat detection, triage, and incident response steps.
BN: What issues exist around cloud security that a more 'traditional' mindset will miss or that will cause more problems for teams?
AB: The challenge here is that security teams must be willing to either adapt their traditional, on-premises approaches to the cloud, or be ready to reframe them entirely. Many teams may try to hold on to their traditional processes when they move to the cloud, but this is not effective.
For example, cloud applications are often designed using serverless functions and containers, 70 percent of which live less than five minutes. Traditional security tools are built to cover workloads that exist for days, months, or even years. Since these assets are long-lived, the traditional mindset is that they're readily available for forensic investigation. This isn't necessarily the case when you're dealing with a large number of ephemeral workloads. When you have systems that are as complex as many modern applications are, it's hard to quickly identify the full scope of affected systems and correlate data to determine appropriate response actions across cloud service providers, SaaS providers, and partners and suppliers.
There is also a case to be made for security moving further out into a business. We've seen more organizations adopt a DevOps approach, which encourages IT security teams to shift left and embed security processes earlier in areas like cloud and software development. But security leaders need to determine if the shift left is encouraging cross-team collaboration between developers and security teams or if only the responsibility has shifted. It's easy to think you’re improving security, but developers need the right background and support from security teams to properly support the shift-left concept.
Another challenge or differentiator is simply how these environments are built. When working in your own data center, there is a mix of different networks, servers, deployments, and assets. Therefore, every organization’s infrastructure is at least a little different. Traditional attackers had to spend more time figuring out the lay of the land for each victim. In the cloud, environments are more homogenous. There is the realization that with these homogeneous cloud networks, attackers, like security teams, can more easily understand each organization's cloud environment, reducing the time needed for reconnaissance. Attacks happen faster because cloud attackers know what to look for and where it exists. In cloud security, keep speed in mind. Every second counts.
BN: How can your team establish the right processes and timeframes to work in?
AB: First, any change in infrastructure requires a change in security mindset. Organizations want their developers to deliver software more rapidly because faster delivery means more features delivered and more opportunities to generate revenue. Security teams then have to keep pace and keep those applications secure, the infrastructure protected, and the data accessible for those who are authorized. Fortunately, cloud architecture allows not only developers, but also security teams to embrace automation. We’ve prioritized the speed differentiator and worked with analysts and customers to build a framework for cloud detection and response -- dubbed the 5/5/5 Benchmark.
The first '5' pushes organizations to detect any change in their cloud environment within five seconds. Any time a new service or container is started, you should have the ability to gather the data from that workload using cloud service provider tools or any other cloud security services that are in place within that time.
The second '5' is how quickly organizations should be able to follow a detection trail within their cloud environment. You have up to five minutes to understand the security implications of any given signal. Because your cloud control plane, orchestration systems, and deployed workloads are so tightly intertwined, it’s easy for attackers to pivot between them but more challenging for security teams to track the problem. To solve this, you must gather actionable insights and connect the dots quickly. The difference between 'alert on a signal' and 'detection of a real attack' lies in the ability to quickly connect those dots, requiring as little manual effort by security teams as possible.
The final '5' is how rapidly you should respond once those malicious signals are detected and confirmed, whether that means fixing misconfigurations or killing containers. We suggest using an infrastructure-as-code approach for defining and deploying assets so you can respond and remediate quickly. You can replace a compromised asset with a clean version, minimizing disruptions to the business while fixing the problem. This response process should be completed within five minutes for the entirety of your cloud estate. In traditional environments, this speed of remediation is far more difficult to achieve, but with the automation features of the cloud, security teams can carry out those actions promptly.
Using a framework like 5/5/5 can help as you evaluate your existing security processes to see where you can make improvements. While it may seem like a daunting bar to reach for, look at introducing changes gradually and establish that it is a team effort. Foster buy-in and ensure all teams are pushing and pulling in the same direction and with the same sense of responsibility and urgency.
BN: Will this involve collaboration with other departments as well?
AB: As I mentioned before, an organization's security is no longer just a security team problem. A security team might make some improvements on their own, but bigger changes will be seen when barriers are broken down and there are cross-team collaborative security efforts implemented.
BN: What does the future hold here? Are we set up to succeed around cloud security, or are there other issues that we should look at in future?
AB: Successful cloud security depends on accessibility to and comprehension of real-time security insights. For companies that are new or not yet not comfortable with how cloud native environments operate, the learning curve can be steep. The goal is to make security teams more efficient and effective through automation and teamwork.
Furthermore, I think future successes are also tied to security getting closer to the business. I know that most security teams don't want to be the last step in the path to production, but that is how many teams today still operate. Get out into the business, have conversations with other teams, and bring security to all aspects of the organization.
Image credit: NataliMis/depositphotos.com