By Prakash Sethuraman, Chief Information Security Officer, CloudBees
Despite the best efforts of companies around the world, cyberattacks are not going away. In fact, they may be getting worse. In a recent survey by the Ponemon Institute, 74% of respondents said the amount of time it takes to respond to an attack has either increased, increased significantly, or remained unchanged. For financial services companies, for example, detecting a breach can take an average of 98 days. And for retail companies, it can take a whopping 197 days, according to an earlier study by Ponemon.
So why does it take so long? And how can we react to attacks faster and more effectively? One of the best ways to defuse these time bombs quickly and avert disaster is to adopt a strategy we call Secure in Production.
What Is Secure in Production?
Secure in Production is the last link in a secure software supply chain. Simply put, it’s the ability to keep track of an application—and the environment it’s running in—after it’s released. This way, you know how and when to respond quickly if something goes wrong.
You might think that once your code is deployed it’s “out of sight out of mind,” but too often that’s not the case. With so many releases happening so fast, you can’t just celebrate and walk away. Even after your application goes into production, it’s crucial to keep track of code and make sure you’re able to respond rapidly as soon as a software security issue arises.
There are two basic parts to the process—detecting security problems and then fixing them—and they are associated with the following well-known industry metrics:
Mean Time to Detect (MTTD): This is how long it takes to detect an issue after your software is released.
Mean Time to Repair (MTTR): This is how long it takes to fix the problem detected.
Or course, between detecting a security issue and repairing it, there is always a space of time. If you’re faced with a serious vulnerability, what you do during that time—that space between detection and repair—is incredibly important. This is where new techniques like feature flagging and automated rollbacks can help out. In fact, these quick-response strategies spawned a new metric in the industry called Mean Time to Mitigate or MTTM.
Mitigation isn’t about repairing a problem. It’s about closing a vulnerability as soon as you’ve discovered it. This could mean anything from shutting down a website to turning off an application or feature, and more. When you mitigate a security flaw or breach, you immediately stop malicious actors from doing any further damage. Now you can safely proceed with repairing the underlying flaw.
Ideally what you want is a holistic approach where application security is embedded throughout the software delivery supply chain. This approach would include a cloud security posture management (CSPM) tool and an application performance management (APM) tool, both of which help monitor your applications and issue alerts when something goes awry. But while these tools are good at detecting issues, they’re not typically designed to respond to problems and mitigate issues as quickly as possible and can lead to yet another silo of technology.
A complete security strategy should also include a continuous compliance system that is directly integrated with a good mitigation system. The best ones act like a feedback loop connecting your entire supply chain, including production systems, to your coding ecosystem. They go beyond simply detecting security and compliance rules violations by triggering immediate mitigation and then providing specific instructions on how to fix the issues.
Here are a few good ways for building an effective mitigation solution:
Connect your feature flag system to your continuous compliance system. To limit the scope of an attack, the feature flag system—which can be baked into your software delivery pipeline—will automatically turn off the feature after the security and compliance tools discover a problem. Feature flags stop the bleeding while your compliance solution tells you how to fix it.
Establish rapid roll-back and roll-forward processes—and rehearse them. Make sure your DevOps teams have these processes in place in the event of a serious security issue at deployment.
Implement mitigation planning from the start. Ask yourself, “what are you going to do when something goes wrong?” Then build that automation into your secure supply chain. The earlier you start the discussion, the sooner you’re equipped to deal with an issue—not if it happens—but when it happens.
Stay Connected
At its core, Secure in Production involves keeping track of code once you’ve deployed it—where the code went and what environments it’s running in. But the “connectedness” of the pipeline is what makes this part successful. Gone are the days of handing off code to other teams and thinking “it’s not my job.” No matter what, keeping track of code will always be your job because its connectedness is what makes a supply chain whole and secure. Rather than operating in fragmented groups on separate islands of information, connectivity (aka communication) among departments and processes is driving IT to be more internally integrated.
Remember, if you can't respond quickly and seamlessly to a security problem in production, you don't have a truly secure software supply chain. In other words, you’re not Secure in Production. Too often we focus on “what went wrong?” and forget to ask, “how can we create a system where this won’t happen?” It’s time to start asking the right questions and start investing in the tools and processes you need to avoid the next cyber disaster.
To learn more about CloudBees Compliance, a solution from CloudBees that ensures enterprises are continuously compliant from commit through production, sign up for updates here.