Category: Application Security

There are a ton of different ideas and theories out there concerning Application Security. 

Please remember that many of these directions and ideas are driving by business needs and dogma. I know this is going to anger a few people and for that I am sorry. But the realism is that sometimes the information you receive is based upon a companies need to control you the user. So their ideas may NOT be 100% correct. 

A straight-forward, simplistic approach to Application Security is a combination of all of the following: 

1) Take Security OUT of the initial Risk Management assessment for all projects. Security must be present throughout your SDLC. You don;t build a network and incorporate Security measures only to stop there do you? How can you write an application and not place it into a continuous testing loop as well ? New vulnerabilities and techniques to find them are being discovered every day. So keep on top of it. Continue to test the application through black box or Penetration testing even after the application is in production. In my opinion, Project Management Principles MUST be updated. They are out dated and need to be changed periodically to include new directions. 

2) Training. Get your developers the training they need to stop writing code that may contain insecure coding methods. Trust the developer to learn at their own speeds. CBT training is one of the best, but follow up with group discussions and periodic meetings. Sort of like your own internal Developer User Group. I've been deeply involved in my career with quite a few of these groups. There is power in sharing ideas and utilizing the knowledge of others to help a developer. 

3) Oversee. Trust your developers through code review by independent developers or developers in other areas. Do not trust that the person sitting next to a developer to review the work. Group reviews, group discussions and group assessments are the best way to go. 

4) Testing. All testing should be handled within your Security Department. This might mean external consultants, companies or individuals who are adept at Application Security testing. If you do have someone on site and in your Security Department that can handle the testing, keep them up to date. A person that only spends a few hours a month testing will inevitably miss more vulnerabilities. A dedicated person is great but a person that can be utilized 50% or greater is better than 5% or none at all. 

Testing should be done with various tools. No one tool is perfect and should be trusted. Automatic and manual testing techniques are probably the best way to go. 
Give the person the time to test an application. If you only schedule a day for Application Security Testing on an application that contains 10 or more data entry pages, don;t expect this to get done over night. Low hanging fruit (easily found vulnerabilities) may only indicate a larger problem. No Vulnerabilities found 

5) Maintenance. Maintain log reviews, periodic application testing should be a normal event added to your Network Intrusion, Network testing cylces. Hackers continue to find new ways into applications. They new ways are discovered and incorporated into automatic or manual testing procedures. Thus, this is a never ending cycle here until the application is retired. A legacy application may be forgotten and found to be vulnerable. If we forget about an application due to its long term usage or "its always been there" mentality, a hacker will find it and exploit it. 

I will try to break down each section more throughout this section, in time.