The methods by which applications and supporting infrastructure are developed and deployed are undergoing fundamental change. Avoiding the predictable hyperbole, new methods including DevOps and Cloud Computing promise to disrupt most of IT over the next 5-10 years. But embedded infrastructure and legacy applications are not going away. IT professionals need to walk a fine line between delivering critical services at the lowest price for acceptable performance, and doing it quickly and reliably.

As usual, security is at the end of the tail being wagged. It’s hard enough to get developers to run a security scan on their code before it’s deployed into production. The idea of integrating security into these integrated development and operational processes (something Rich calls ‘SecOps’) seems like a pipe dream. It may be a dream today, but it needs to become reality sooner rather than later.

IT has little choice. Adversaries continue to innovate and improve their tactics at an unprecedented rate. They have clear missions, typically involving exfiltrating critical information or impacting the availability of your technology resources. They have the patience and resources to achieve their missions by any means necessary. And it’s your job to make sure deployment of new IT resources doesn’t introduce unnecessary risk.

With this need to move faster and to have more agile infrastructure, it is increasingly difficult to ensure proper testing for infrastructure and applications before they go live. You have all heard the excuses that emerge when something goes wrong with a deployment.

  • We didn’t hit it with that much traffic.
  • We didn’t get around to testing those edge cases.
  • The application wasn’t designed to do that.

Ho hum. Just another day in the office, and it’s security’s problem when the new application is compromised, data is lost, or the application falls over under the onslaught of a denial of service attack. It doesn’t need to be this way. Really – it doesn’t. Although in light of common experience, many security folks don’t believe this.

The root cause of these issues is surprise. That’s right – when an application goes live (or a major change goes into production), you don’t really know what is about to happen, do you? You haven’t been through a rigorous process to ensure the application (and its infrastructure) is ready for prime time.

And calling the application ‘Beta’ won’t save you. If the application has access to critical (regulated) information and is accessible – whether internally or externally – a security mindset is required, along with a way to put the application through its paces. As I wrote in the Pragmatic CSO,

Basically you are trying to eliminate surprises. So by doing a full battery of tests before the new system is deployed, you reduce the likelihood that you are missing something that you’ll learn about later – the hard way.

Technological disruption is not about to stop. If anything it will accelerate, so we need to get over our idea of a discrete security function maybe doing some testing and/or risk assessment at the tail end of a project. So what can and should security folks do? And how can they get both the development and operations teams on board with the necessary changes to ensure the protection and survivability of the application?

To prevent surprise we suggest a security assurance and testing process for ensuring the environment is ready to cope with real traffic and real attacks. This goes well beyond what development organizations typically do to ‘test’ their applications, or ops does to ‘test’ their stacks.

It also is different than a risk assessment or a manual pen test. Those “point in time” assessments look at what can happen but aren’t necessarily comprehensive. The testers may find a bunch of issues but not all the issues. So remediation decisions are made with incomplete information about the true attack surface of infrastructure and applications.

So that is the topic of our next blog series, titled Eliminating Surprises with Security Assurance and Testing. We will dig into this process, discussing which devices and infrastructure components to test and how to consistently and reliable ensure you are testing the key functions. We will also focus on assuring the readiness and resilience of applications because they are often the path of least resistance for attacks.

We would like to thank Ixia for agreeing to potentially license this content at the end of blog series. We will be developing it objectively, using our Totally Transparent Research methodology. We can provide this research to you at this most excellent price because our clients support our unconventional research model.

Remember – your adversaries don’t need to hit an arbitrary deadline. They will take the time needed to find the chinks in your armor. Maybe it’s within the application, maybe it’s within the computing stack, maybe it’s the underlying equipment that gets data from one place to another. You can’t eliminate all the defects and security holes in your environment. But you can find out what they are and put a plan together to protect your environment.

Deploying a security assurance and testing process to do just that is what this new series is all about.

Share: