Software Security: The Big Picture. Part 2
Table of Contents
Data Center Security – an Incoherent Mess
Security in the data center
When I started thinking about a data center I had to try and find some lines to slice it along to try and make sense to the world. Here’s how I did it. I started thinking about the data center in 3 tiers: the Network, where the security people are concerned about the network firewall, the penetration test, or a SIEM (security information and event management) system. Then there’s the Host, where you want to make sure that the right code is running; if you have to run anti-virus, do that; and you’re concerned about locking that operating system down. At the top of this stack, we’re worried about the software – that’s where the business process is implemented; maybe you do penetration testing or maybe you use an application firewall, perhaps you’re securing the database.
There are 3 major activities that we see here. First, assessement – is that system vulnerable? If so, how? Second, mitigation – where there are vulnerabilities, we want to provide some sort of reason to think things are going to be okay. And lastly, monitoring, where we want to know what is actually happening to that system in real time as it’s running.
The network layer is probably the most mature market, where assessment, mitigation and monitoring have their own vendors who offer solutions that make sense for the problem they’re trying to solve.
At the host layer, the situation is maybe not quite as stable as at the network layer, but similarly mature, where we have silos of assessment, mitigation and monitoring.
At the software layer, the story is a little different. Before I can show you the slide with the software layer described, I have to talk a little bit about what the software layer is composed of. At the bottom, we’ve got the data store – usually a relational database these days. In the middle, we’ve got the infrastructure software – the middleware, maybe an application server, maybe the SAP server. And at the top, we’ve got the applications – maybe they’re custom-written in ABAP, maybe you’ve outsourced them, maybe you’re bringing in some open source. But you’ve got to tie all of these layers together in order to get a working system.
Security at the software layer
So, how do we protect such a thing? Well, the way we protect it is with assessment, mitigation and monitoring, but stratified along protecting the data store, the infrastructure and the application. This slide (see image) maybe needs a little bit of backstory, too – you see a lot of black marks on here. I submitted my presentation to RSA, and they said: “You’re not showing that.” I said: “Huh?! What’s wrong? I’ve been presenting at RSA every year for, like, the last 5 years. And this year – I’ve gone way off the tracks?” They said: “Those vendor logos on there do not play.” And I said: “Hey! Yeah, I’m seeing there’s room for improvement, but I’m not calling out any particular anybody as the bad guy…” And they said: “Brian, this year you’re HP. And when you’re HP and you put somebody else’s logo on the slide, it doesn’t matter what you say – you’re the bully.”
So, you’re going to have to use your imagination to fill in who I’m talking about when I’m talking about assessment at the application layer or monitoring at the database layer. The one thing I can say for sure about the slide – you can tell even with the black marks on there – is that mitigating vulnerabilities in infrastructure software is kind of a green field, so if you’re looking to start a new company, maybe that’s the place to go.
Alright, what’s bad about this picture? Well, what does it look like when you deploy it? Here’s the security team, with a whole bunch of stuff going on. It all ought to look pretty familiar: there’s maybe somebody protecting the software from the network layer; there’s somebody else running a penetration test against that software; yet another person worried about what’s going on on the host, looking at application on it; and somebody else worried about protecting the data store. That’s a bad deal. Why is it such a bad deal?
First of all, it costs a lot of money. Maybe this is a good place to not talk about what those vendor names are exactly, but if you start adding up these parts, you’re maybe going to pay 100K ahead for those guys on the security team, they’re hard to come by these days. And then you’re going to have to buy all the tool and it’s going to go in; and then you have to listen to them argue about who’s most important, because every one of those vendors is telling them: “You’re the top dog here, your stuff is the most important.” So, when you add it up it’s going to be slow and it’s going to be expensive. Does it really cost more than half a million dollars to secure a basic web deployment? Gosh! It seems like a lot. But wait – there’s more…
… and It Doesn’t Work
Real-world scenario – social website
It doesn’t work so well. For this I’m going to tell two stories. Here’s the first one. Here’s a social website; it’s an online dating site (see diagram). Here’s what they did. They had some penetration testers come in; they tested the app, they said: “Yeah, you know, things look good.” They said: “Hmm, we’re still a little nervous, let’s encrypt the database.” And they encrypted the database, too. And then they got hacked. How did they get hacked? Well, it turns out that the user interface and the web services weren’t quite so monolithic. The penetration testers tested the user interface – the attackers went after the web services. What happened? Well, because the attackers came in through the web services, the database encryption didn’t matter at all; and they compromised the identity of every real individual in that online dating site.
Real-world scenario – payment processor
Next scenario: payment processor – this one was more public, you could probably guess the name if you put your mind to it (right-hand image). Again, the penetration testers come in, they test the critical app, they say: “Critical app – looking good!” The attackers come in through the low priority app into the same data store. They get into that data store, they still can’t get to the critical app, but guess what – the critical app trusts the database, so they go from the data store to the critical app, and then back into the data store in order to extract all the transactions from the system. And that’s the anatomy of a major payment processor breach from a couple of years back.
Also Read:
Posted in: News
Leave a Comment (0) ↓