When people talk about security today, they tend to focus on the edge of the network, where they deploy firewalls and VPN software to secure access to the network. The trouble is, this gives IT people the illusion that the entire enterprise is secure when they have really just set up a first line of defence. Once you secure the network, the second line of defence is the applications themselves.
Much greater attention should be paid to making the applications secure from intruders. Failing that, a third tier of defence should be set up around the data in the applications. After all, when you visit a bank they don’t have locks on just the front door. The vault itself has its own lock and inside it are safety deposit boxes with their own locks. The same kind of thinking should be applied to IT.
It is difficult to achieve this level of security because developers are always under the gun to deliver on time. To meet what are often unrealistic deadlines, they typically cut short two processes. The first, as every end-user who has ever read a manual knows, is documentation. The second is quality control, where developers typically start to think about any security issues associated with their application.
But this is putting the cart before the horse, because the time to consider security issues is when you are building the application, not after it’s built. It’s only a matter of time and a few costly lawsuits before a multitier approach to security becomes standard operating procedure. Let’s take a hypothetical case in which an auto-maker consistently delivers a car with doors that don’t lock and an ignition that can be started without a key. If that auto-maker recklessly ignored reports from customers about these flaws, and someone used one of the cars to inflict damage or even kill another person, the auto-maker could be held liable depending on how you interpret product liability laws. Similarly, it’s only a matter of time before someone decides to sue a company such as Microsoft over the lack of security inherent in most of the applications that people buy today.
If a hacker commandeers a system using known security flaws in the application to inflict damage on others, the company that built the application and the company that bought the application should probably carry some of the liability associated with the damage caused by the hacker.
Hopefully we won’t see a raft of legal cases emanating over security, but the reality is that unless companies are seen to be taking measures to secure their applications, they should be held accountable. And for many of them, that means either slowing down the application development process or completely rethinking how they approach security issues as they relate to applications.
In the meantime, IT organisations must be less complacent about security. Just because you locked the main access point to your network with a firewall, it does not mean you are secure — not when a hundred backdoors are open at the application level.
What’s really required is a full audit of your entire security apparatus, from which you can then build a blueprint for securing all aspects of your site.