Application Security

As part of the requirements to maintain my CISM designation, I regularly attend ISACA e-Symposium events. These web events are held once a month and, to be completely honest, while my primary purpose of attendance is the 3 cpe received, I do tend to learn a thing or two on the subject matter offered. Sometimes what I learn is just in what I spout out while yelling at the screen (I am known to do this quite often with scientific documentaries on TV), but it gets me thinking at the very least. Yesterday's e-Symposium entitled "Application Security The New Gateway" was no exception; I learned some and spouted off at the non-replying screen more.

The two things that will get me talking back to a screen, computer or television, are when an important subject matter is glossed over or when something simple is over complicated. Experts always seem to like to over complicate things. In an effort to be completely fair to the e-Symposium, each presenter only has a limited time span to cover a wealth of information, so a lot will be glossed over to provide time to focus on their primary topic (which sometimes is a sales pitch).

One of the items glossed over was a statistic from Gartner stating that 75% of attacks occur at the application level. The statistic itself was not glossed over, but rather the reason it is 75% rather than 25%, and I feel that reason is important: System Security. Hackers didn't just decide one day to change their attack methods from network/system infiltration to application hacks; they did it because of path of least resistance. Once upon a time networks and systems were not very secure and allowed an easy path into all sorts of information, but system security became a hot spot and made accessing data through the "old school" methods far too time consuming and difficult. The number of web-born applications has also increased, presenting a doorway to data. And so application level attacks became the way to go.

I actually find it insulting to the security industry that the statistic is not 90+% in favor of application layer attacks, given the amount of time and volume of information regarding the need for good system security practices. It is what it is though, and some people and companies will always prefer to pay tons of money and time in a year or two than to pay a relatively small amount now to protect their investments. They would be better off selling their companies and spending the money at the craps tables in Vegas, a roll of the dice is just that and will always be in favor of the house, but at least this way they would only be wasting their own time and money and not hurting other people.

The second bit of spouting at the screen for this e-Symposium had to do with the over complication of things. Again, to be fair, each of the presenters represents a company and that company would like to get something out of the three hours of otherwise billable time for their expert, so the presentation becomes a partial sales pitch and things get over complicated. And as I said, experts like over complicating things. In reality, application security is not an over complicated item.

There are two main culprits for flaws in any program, lack of security knowledge by the developers and lack of testing during the SDLC (software development life cycle). Both were covered in the e-Symposium, but the solutions really were not, and they are, in theory, the easy parts. First, companies need to require their developers to be trained in development security best practices. It is an investment on both the part of the developer and the company, but it is time and money well spent. Again, pay a little now or a lot later. The SANS Institute now offers training and testing in development security through their Software Security Institute programs. A little costly, but the benefits are huge long term and, as I previously stated, promotes employee retention, which saves more money.

The second part of the solution is something that has been yelled and screamed from the rooftops for as long as companies have been developing software. Give QA the time and resources to properly test software. Yes, deadlines loom and developers get behind schedule, but cutting QA time to meet a launch date is far more costly and time consuming than pushing back a release schedule in order to get the software right. There are a ton of stats available from all sorts of independent groups on that subject, or just look at Microsoft and their reputation as a result of forcing projects to market. Further, QA personnel need to be trained in application hacking and exploitation techniques and it needs to become part of the testing process. Once again, this is time and money well spent in the short and long term of a company.

If those two items are taken care of during application development we will see a vast shift in security incidents. The overall number of incidents might not drop, hackers will continue to do what they do, but the percentages of types of incidents will shift dramatically away from application level. My prediction would be that we will see a number around 60% of all hacks being related to social engineering instead. Some companies, after all, will always want to pay more later than a small amount now. For those who "get it", a little proactive effort will go a long way towards Application Security and keeping your company profits up in the coming years. Just don't forget to cover social engineering.