Security is a Lifecycle Responsibility
I'm currently at Java Pro Live! in Boston, where about three hundred attendees have been participating in sessions on designing, building, and managing Java applications. While I haven't been able to look in on every session, I've certainly learned a lot about current and future directions bringing together these three aspects of the application lifecycle.
In his keynote, Paul Patrick, chief security officer for BEA, talked about changing expectations around Java with regard to application security. For those of us who think that security is a matter of configuring firewalls and network authentication, this was a sobering reminder that despite billions of dollars spent on infrastructure protection, enterprises are still losing money and data on application intrusions.
Part of the problem is that most of us have an incomplete picture of who is trying to get into our applications. The image of the rogue hacker seeking to intrude primarily for the technical challenge might have been accurate during the early days of the Internet, but in recent years this type of person has been supplemented by two other groups. The first is the internal person, the disgruntled employee, who already has at least some level of access to the network and quite possibly the application. This person might be motivated by thoughts of either riches or revenge, but because most enterprises don't adequately protect from an intrusion from inside, this kind of attack can be relatively easy.
The second type of person is the professional intruder, the person who does it for a living. Patrick pointed out that organized crime has discovered the Internet, and uses highly skilled people to fake financial transactions or obtain information that can be sold. And he noted that both terrorists and spies have become adept at getting information for their own nefarious purposes.
What makes security such a problem is that we have much more to protect today. It is certainly true that the things we lose today—money, system stability, and data—are the same that we lost 10 years ago, but the consequences today are much more significant. Any downtime at all on an e-commerce Web application can cost an enterprise millions of dollars, and the loss of data might not only be expensive, but also cause legal or regulatory difficulties.
Mr. Patrick called attention to the fact that protecting only the infrastructure means that anyone who can get past those protections has relatively free reign to create havoc with any application running on that infrastructure. Applications have many known potential vulnerabilities, and intruders can easily exploit those vulnerabilities in the pursuit of money, information, or chaos (the pun with the 1960s era spy comedy, "Get Smart," is intentional).
This is bad news for application developers and testers, who already have enough technical demands on them even before they start thinking about security. Yet there is no getting around the fact that learning and applying secure coding practices, and testing known hacks against applications will become a necessary part of the application lifecycle in the very near future.
Posted by Peter Varhol on 10/18/2004