Nearly every security breach that leads to identity theft, network outages, data loss or Web site defacement has a root cause in a security flaw that was the result of poorly written software code.
Research firm Gartner estimates that approximately 70 percent of all attacks happen at the application layer and that it is vastly less expensive for all concerned to fix the vulnerabilities during development rather than after deployment.
So if there's broad agreement about the solution to the industry's long-term security woes, what's holding back progress? Simply put, a major language gap exists between security and application development.
For the most part, this is an under-the-radar problem. Most organizations don't see the language gap between developers and traditional security professionals. They don't realize that asking developers to add security to a product already in development is akin to asking an auto manufacturer to add seat belts, airbags and a steel-enforced, rollover-proof cabin into a car after it has hit the assembly line. It ignores the fact that software development is a process and that the only way to affect the quality of the end product is through changes in process.
Security professionals want to help developers write better code, but the only way they know how is by throwing more software at the problem. The SANS Institute published research demonstrating that hackers and virus writers are now aiming at the products corporations use in their defenses. In fact, now that operating system developers like Microsoft seem to have figured out how to better shield their products, hackers are increasingly targeting antivirus applications.
So, to be clear: The hackers are now attacking the software that protected our software.
Does that mean we are supposed to add yet another layer? Are we going to deploy new software to protect the software that was protecting our software?
Confused? You're not alone.
Development professionals live in a world vastly different than security professionals. Development is a process-driven discipline where steps and roles are extremely well-defined, and upsetting the process can result in product development and shipment delays--an outcome that can make management, sales and even shareholders very unhappy.
Development organizations are driven by the need for quick time-to-market and the pressure for new features, not by the need to write more secure code. Only in the most high-profile cases do security breaches result in some sort of action taken by the development organization to rectify the situation during development. Most developers don't understand the first step of secure coding and testing: that by putting two properly written lines of code together, you can actually introduce new vulnerabilities.
The software industry needs an agreed-upon lingua franca for collaboration between development and security. The industry needs to develop a standard for integrating security processes, roles and artifacts into the existing life cycle with minimal pain and impact on time to market. Even if the approach is modular and takes time to implement, a standard will still mark an all-important first step to improving software security.
Such a standard is a must, if we are going to truly change the way that software is developed and affect the security quality of the end product.
Biography
Kevin Kernan, a 17-year veteran of the application development market, is CEO of
See more CNET content tagged:
gap, hacker, development, professional, security
Developers can't write doc...developers can't understand buffer overflows...developers can't do this or that.
Good ones can.
If I as an app developer choose to use ActiveX with VBA, I have no choice but to trust the underlying security tools provided to me by those tools. (haha) However, if there are vulnerabilities in the libraries I'm using, it's still going to look like an App problem and I'll be the one looking like a dumb developer because my tools vendor has insecure code.
This highlights another problem -- security people really don't know much about security. They are reactionary. They only know of security problems AFTER they happen. Security-consience people are allowed to review and test new code, but they only use OLD methods and well-known security expoits. If some new method of exploitation is discovered, they have the easy job of pointing their finger at the developers. It's THEIR fault! It's THEIR fault! Not ME!!!
The real problem lies in the subtle vulnerabilities. Ones we don't know about yet, are difficult to recognize due to their complexity, or come about due to a combination of minor flaws that together add to trouble. These are hard to spot both by tools and human eyes.
SQL injection is a big problem. Even when educated to avoid it by validating input many programs still exhibit flaws due to weaknesses in their validating logic. Is this really an intractable problem? Are the developers just prone to never get it right?
Couldn't we solve the problem better by re-designing the data API's instead of putting the burden on the multitudes of developers with varying degrees of security smarts? The data API's are not flawed, they just don't protect you from this attack.
What if they did?
- I completely disagree with the premise
- by betelgeuse68 June 15, 2005 12:59 AM PDT
- The premise being:
- Like this Reply to this comment
-
(5 Comments)"Most people would agree that the best long-term answer to the security problem is to make software intrinsically more secure."
Here is the problem, security and convenience are inversely proportional to each other. If you left your house unlocked at all times, it sure would make life a bit easier... wouldn't it? I mean, not having to bother with keys as you arrive home with bags of groceries or fidgeting through your keys at some late hour and it so happens the light bulb in the general area burned out.
Let me give a concrete example. Many people complain about Windows being insecure but this is entirely untrue. The Windows NT kernel has had security from the get go, as in early 90?s as has its file system (NTFS) sporting robust Access Control Lists (ACLs) facilities. Yet, when was the last time you found a SINGLE home user using a "limited account"? Namely an account whereby the manner in which they login does NOT have full administrative privileges.
The notion of ?least privilege? has been around since the dawn of time shared computer systems in the 1960's. In other words, don't make everyone an administrator. Yet with a home computer since the user base is small (1,2 or whatever the family size is) the expectation is convenience.
It turns out that Microsoft also does *not* leverage what it has created (Windows NT) for a simple reason, there are MANY misbehaved legacy Windows applications that will simply not work with a Windows XP limited account because they assume "God Like" powers on the computer system they are running including but not limited to being able to modify files in the system directory.
Yes this can be trivially overcome. *Impersonation* is the other tenet of secure computing.
If such applications failed for the average Joe Schmoe who is thinking "Well this always worked on Windows 95!!!" then guess who starts potentially looking bad? You guessed it, Microsoft. At the time they were more concerned with convenience and simply put putting the onus on the end user by not doing what today would be the right thing, i.e. creating accounts with stunted credentials and to hell with all misbehaved Windows 9x applications. Easy to say until you run into an end user who has some software they really want to run. Which iterating, is trivial to do, yet the notion that they then have to type an administrative password to run a program is *inconvenient*.
Yes, yes, yes, "But it's gotta be simple, like a toaster, just make it work." Yes, but toaster isn't a gateway to your financial records and/or bank online accounts. A computer, unlike a toaster, can burn you a lot harder (metaphorically) than a toaster might while you make toast.
The issue here is largely a user education issue. We don?t come out of the womb knowing this stuff but some simple practices can go a very long way to mitigate all the virus/worm din that perpetuates security concerns these days.
In my experience laziness when it comes to secure computing extends itself well into corporate America. The recent incident such as the Bank of America and Wachovia incident two weeks ago where something like 600,000 accounts were breached cannot be fixed by writing "more secure software."
It was easily preventable with a proper system of checks and balances and finally, simply monitoring network activity on well known data points (machines with massive databases).
The solution is to *leverage* the technology that already exists and has existed at this point for *decades*.
No disrespect Mr. Kernan but as someone who is well versed in security I'm sensing a bit of self-serving rhetoric here, i.e. Secure Software's focus.
-M