Also, consider that network security is much more mature than application security and the investments you have already made here are probably orders of magnitude higher than those you’ve made in application security.
Don’t ignore network security, but try this practical tip: Make a list of the investments and compensating controls you have in place on the network, e.g., anti-virus, IPS, firewalls, etc. and along with that list their costs (initial/purchase cost is fine). Now do the same for your information and application security investments and compare them.
If the application security investments aren’t at least two-to-three times that of network security you have an imbalance in the number of vulnerabilities you’re mitigating.
With that first filter applied, you can now consider where and when is it most costly to address application security. IDC and IBM conducted a study about two years ago that mapped the cost of fixing a problem through the software development lifecycle. The results were roughly exponential with respect to time and phase.
Said another way, if a defect found at the design phase costs 1X to repair, the same defect costs 6.5X to fix if found during the coding phase, 15X if it were found in the pre-deployment testing phase, and 100X if it’s found by your customers in the field after it is deployed.
Keep in mind that this only accounts for the time and effort it takes to fix the problem (internal costs). It doesn’t even factor in things like reputation loss, cost of patching and deploying, and other losses that usually come along with security defects—things like loss of market share and stock price.
3. Ask Tough Questions
Tough questions are great because they make you think. The challenge is usually determine what questions are the tough ones. I provide a short list here to get you started. You will see the pattern fairly quickly and can expand on them for your own environment.
These are questions that are useful to ask your vendors before making a software purchase. You should also ask the same questions of yourself as you build and maintain applications for your business to use.
Finally, use these questions to improve your service-level agreements with outsourced partners (especially software development partners). Since you are probably making a purchase or partner contract to automate or transfer some business function; shouldn’t you also consider how to mitigate or transfer your risk when you’re doing this?
4. Create an Internal “Red Team” of Ethical Hackers
This is a term borrowed from the military. The concept here is that you dedicate a small team (usually three people or less) to act as attackers. This can be a permanent role if you can afford the resources, or you can take some nasty-minded testers and make this part of their job at various phases in the development process.
Their job is to attack your application systems and your networks as if they were evil. I don’t recommend constraining them to act just as “outsiders”. The insider threat is often overlooked and you can learn a lot from creating attack scenarios from an inside user perspective.
If you don’t have the resources or skill set to create Red Teams, there are many third-party consulting shops that can do this for you. Start with your most critical applications and work your way down the risk rank stack.
By the way, you also need to be certain that any third-party assessments company you use is capable. So ask those same tough questions of them, focusing on things like: methodologies used, credentials, engineers they are going to use on your application, how/if they depend on the use of automated tools, etc.