Dont 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 arent at least two-to-three times that of network security you have an imbalance in the number of vulnerabilities youre mitigating.
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 its 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 doesnt even factor in things like reputation loss, cost of patching and deploying, and other losses that usually come along with security defectsthings 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; shouldnt you also consider how to mitigate or transfer your risk when youre 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 dont 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 dont 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.