The fundamental problem with security is that it's everyone's problem, which means that no one is actually responsible. 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 defense. Once you secure the network, the second line of defense is the applications themselves.

Much greater attention should be paid to making the applications secure from intruders. Failing that, a third tier of defense 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 automaker consistently delivers a car with doors that don't lock and an ignition that can be started without a key. If that automaker recklessly ignored reports from customers about these flaws, and someone used one of the cars to inflict damage or even kill another person, the automaker 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.

This won't be popular with software companies already hard-pressed to keep up with their production schedules. But one could argue that the current pace of development is pushing software vendors to adopt behavior they know is reckless. As companies that make cigarettes and firearms learned, you can be held accountable for how people use your product.

In the meantime, IT organizations 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. After all, if someone penetrates your network, it's not a given that they should be able to access your applications. And if they do gain access to your applications, it's not a given that they should be able to use data outside that specific application.

For most of us, increased security goes against the grain because it means work and inconvenience. But the reality is that locks and access levels are the hallmarks of any civilization, and that is the key element of our collective social contract.

» posted by ITworld staff

InfoWorld

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine