Why Converged Security matters: how to squash the security bugs

In my previous blog I talked about why Converged Security matters and described four use cases we advise customers to focus on. I then followed up with a blog covering Augmented Security Operations. In this third instalment I would like to talk about the secure application lifecycle.

 

In 2008, at an internal event, I attended a presentation by the CTO of a company we had recently acquired. The topic was web application security and since I had, in the past, built and managed enterprise web applications, I was intrigued. He started by demonstrating how to attack an application with SQL injection, which was quickly becoming a significant attack vector at the time. Within 30 minutes he managed to hack into the hotel’s application (used by guests to check their account) and produce – live on stage – the full account, room service and all, of our regional VP.

It would seem things have gotten worse. While SQL injection is perhaps not as prominent anymore, research suggests that 84%, or 5 out of 6, attacks occur at the application layer. Yet we spend $5 out of every $6 on perimeter – not application – security. This is a rather dangerous imbalance, one that the Secure Application Lifecycle can help address.

As we move to the new style of IT, there are some shifts that need to occur, as illustrated below:

 

Picture2.png

 

Whether driven by the adoption of Agile development methods or by everyone jumping on the mobile bandwagon, the reality is that rapid application release is the name of the game nowadays. Developers of enterprise apps are finding it hard enough to deliver on time let alone worry about security. Sound familiar? A decade or two ago we were having the same debate about testing. However, we cannot put all the blame on developers. After all, “harden the edge, trust the core” is still how most IT organizations view security and in an application lifecycle context, security is still often considered as a non-functional area. But think of what happens as we move apps to the cloud. Not all apps will move and some will stay in the core. So there will be a need to integrate cloud apps with on-premise ones and it needs to be designed into the application architecture holistically. Approaching it in a bespoke manner is simply asking for trouble.

What we need is a change in mindset. We can begin by embedding security into our application lifecycle (or our “Requirements to Deploy” value chain as we call it in HP) starting with analyzing code for vulnerabilities all the way to protecting the app at runtime. It is important that this is done by weaving it into the value chain, not as an overlay function. Security is no longer a non-functional set of requirements and should be part and parcel of how we build and deploy applications because a security bug can – today – cause a lot more damage than a functional one. The same way we moved from “testing” to “design for testability” we need to think about “design to be secure” rather than “test for security.” As was the case with testing, it won’t happen overnight but it will happen if we start by considering security testing as important as functional or performance testing.

There are some differences between now and then, which can ease this transition

  1. We now have precedence. We know it is the right way and we know it can be done
  2. We now have a mature set of tools to support test automation, test management and continuous integration that provide us with a strong foundation
  3. We also, at HP, have an approach – the Secure Application Lifecycle – and the tooling that can help application teams make it happen

Picture1.png

 

For more information on how to implement converged security, visit http://www.hp.com/go/convergedsecurity, or come and see my colleague Gerben Verstraete present how together we stand, but divided we fall at HP Protect .

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation