We sat down with security analyst Andrew Walls at Gartner ITExpo and asked him how Web 2.0 affects application security.
He talked to us about how traditional desktop security measures are falling short in a Web 2.0 world and how developers need to take more personal responsibility for the security of their code.
Whats the single biggest threat to applications on the internet?
People. I know that sounds a bit simplistic and facetious but what it really comes down to has always been the way people use applications, and the way people use data. If everyone was honest, trustworthy and truthful then we wouldn't have security problems. On a practical level we assume in the security business that everyone out there is deceitful, dishonest and is trying to rob us all blind -- so we try to secure applications as well as we can.
We assume in the security business that everyone out there is deceitful, dishonest and is trying to rob us all blind.
In the world of Web 2.0, mash ups and web deployed applications many of the issues we deal with are actually the classic issues around security and application development -- We need to make sure that the input data, ie. the information that were entering into form fields in a web page, is actually valid data -- information that we want to have put into our system. And of course, the information that leaves you system is what you want to have put out.
Any system that ignores those basic rules is a system at risk. If you remember a couple of months ago there was a big hullabaloo about the prime minister's web site being hacked. That was a classic Javascript attack that relies on people not validating input, when they take data from a standard form. Now this is one of the standard forms of attack, and they still exist -- that's the problem. The developer world has not done a good job at validating all their inputs and outputs, or putting clear bounds on all of the data moving through their systems.
Fundamentally those problems exist because of people -- systems do whatever we tell them to, but it's people that carry out the attack, that hack the controls we put in place. The biggest problem is always going to be ourselves.
How well are these problems understood by businesses?
Well it depends on what you mean by businesses. Sitting here at the ITExpo, any one of these businesses out here on the floor understand them very very well. But of course they're focussed on IT, about security and they deal with that all the time. If on the other hand you're working for a bank, or for a car manufacturer and you talk to the business leaders in those organisations they would have no understanding of the minutiae I was just talking about, validating an the like -- Nor should they. What they need to understand is the impact on their business if those security problems are left untreated and unmanaged. They'll hire security managers and professionals to look after it for them.
What security managers need to be able to do is translate these technological and security risks into business language, into business risks. So then the business leaders can make informed decisions about their business -- they don't need to know about the specific problems, that's the security manager's job. The business leader does need to be informed, and to have real data, so the executive can make the best decisions.
How well can the approach taken to desktop application security be taken to the Web?
They really don't map very well to each other. To start with desktop security is not done very well, theres a lot of changes going on there still, we're seeing a whole new class of products that we refer to as Data Leak Protections. This covers things like moving data on to a USB stick, or burning it onto a CD. That goes beyond identity management, or making sure people have tokens for strong authentication -- it's more looking at how data moves through your system and controlling that information correctly.
If I want to stop credit card information from leaving my system, either over the network or through somebody's laptop or USB stick then I have to have software that knows what a credit card number looks like and can do things when it sees data being moved to the wrong places. That goes way beyond what most popular desktop security environments do. So these are new products that are emerging now. The desktop is not as secure as we'd like it to be, and there's still tons of room for improvement on the desktop and laptop side of the equation.
Then theres new application environments, like Web 2.0 environments -- there was a great presentation by David Backley from Westpac about how they're using Facebook type social networking environments within Westpac to promote collaboration and teamwork, and they're looking at virtual worlds like Second Life as well. These sorts of new applications that rely on large distributed network deployment introduce all sorts of new aggregations of security risks.
I say aggregations to break down these application types -- virtual worlds, social networks, blogs, whatever it is -- if you look at the components that make these up they're no different from any other application -- they may use a language thats a bit newer, AJAX or new forms of HTML, but they're still languages and they still have the same issues: Validation and making sure the code has not been altered -- the same basic thing.
The issue is in the new Web 2.0 world we're all dealing with is that those components cannot exist by themselves. It's not that you can get a copy of a word processor in one nice tidy piece on its own, Web 2.0 applications are often made up of dozens of these individual components. Those components may come from different companies, or may be homegrown, developed internally. Ensuring the security of each one of those components is critical if you're going to ensure the security of the network.
With the increased complexity of these collections, or mash ups, the challenge to secure them goes up logarithmically. Every time we add more systems together, the potential interactions, and the potential corruptions among them, expands, and we have to secure each of them. The only way we can secure the whole mass is to secure each component by monitoring, managing data transfer, firewalling, and in the end, we just have to watch our applications like a hawk. Now these are all standard approaches, nothing about this is new, we're doing all of these already. The issue is that it's getting more and more complex - we have to do it more aggressively, we have to do it faster, we have to do it at a much more granular level within the application than we have in the past.
As a result we're seeing vendors with products and services coming out which focus on different levels within applications, to do code reviews, application vulnerability scanning, testing, continuous scanning and testing of application suites. This is all self defense, how can we automate these tasks to be as responsive as we can be to continue to secure our organisation, it's all about how can we manage burgeoning complexity in the application environment. The processes are the same as they've always been, but we need to do it faster, and we need to do a lot more of it.
Nobody is going to give you more budget to do it, of course, so you've got to do it with what you've got. You've got to develop your staff, and your tools and your relationships with vendors -- you've got to be a much more adept and sophisticated manager to manager security these days.
To what extent is security management going to be playing catch up with the malicious side of the security industry?
You can close the gap to a certain extent, but you're always going to be lagging slightly behind. This is the same situation that law enforcement faces: certain national governments notwithstanding you generally can't arrest someone before they've done something wrong.
It's very difficult to defend against a truly novel attack. We know how to defend against attacks that are in classes of attacks that we know -- A virus? well we know how to defend against viruses, we understand essentially how they work. We understand buffer overflows, so we can defend against those, how to shape our applications around that. When we're talking a totally new kind of attack it's difficult to anticipate how to defend against them, we can do what we can, but it's just going to close the gap a little bit -- but there will always be a gap.
This basic concept is what a lot of business people don't seem to understand, there is no such thing as a bug free system -- no system is ever devoid of flaws. Someone could write a perfect application with no perceptible flaws, but the minute they finish that application and it goes out into the world people will start coming up with new concepts and new uses of that application that the designers did not intend and did not anticipate. It will break, it will have flaws.
I remember a time long, long ago before sport utility vehicles dominated the roads, when that was the case, cars were cars -- when cars slam into each other you were worried about bumpers on the front, bumpers on the side, seatbelts and that was it. Now we're got nice small cars, and big SUV's -- If i'm driving a mini and I slam into a big truck like car, then their bumper's at the height of my windscreen. The Mini was safe when it was on the road with other Minis, but then the environment changed around it and now I have a security problem.
It's the same thing with application code, it can look great today, but as soon as you put it out in the real world, the real world will change. Theres another version of this that gets bandied about a bit which is "as soon as you build a foolproof system, the universe will build a bigger fool", this is why software vendors and product vendors are constantly upgrading and updating their systems.
What should developers do to make their software less susceptible to security flaws?
Fundamentally the development community needs to take personal responsibility for security. Security is not something that can be slapped onto a piece of code once it's all done. Every structure within that piece of code has got to be built with security as an objective. It used to be that security was not considered to be a business requirement, and so when you were developing an application or a driver even, you were driven by performance and functionality -- security requirements were not inserted into that environment. The result was that you get a lot of buggy code floating around systems, and theres always someone who's going to discover flaws in something that hasn't been updated in ten years.
The fix is not more firewalls, more IDS, or whatever -- those things buy us time, they slow the attack down, but they won't solve it. The problem is in the coding, now admittedly you can't cure every ill, a new problem will pop up as soon as you put it back in the wild, but the coding structures and the approach to coding must have security as a major ascpect of the process at all levels.
This goes back to how we teach programmers. Our universities are now taking security much more seriously, we don't see security as just a unit you have to take, now security is being involved in every single unit in programming classes at more and more universities. That's exactly the attitude we need in every business process, and every development system. Security has got to be a bedrock requirement of every piece of code generated. We're seeing this in universities and slowly but surely we'll see it in the business world as well.
Leave a comment