Secure Development – How Protected Are You …

First up - after my last posting, someone that works in the security field contacted me to let me know that I should be referring to folks that try to exploit weakness within systems and to break in to systems are known as crackers.  I stand corrected.
 
Last time we chatted, I discussed the need for security.  Today, I’d like to expand on that topic and talk about the need for secure development.  The need for development teams, and the software development lifecycle, to account for security is more critical today than it has ever been.  In fact, as more and more of our devices live in an always on/always connected state – the risk to you and your data will only increase.   Many organizations spend time and dollars to buy physical hardware to sit on the edge of their networks to protect their data centers - but then forget to build security in to the software that they implement in to their production environments.

How many of you over the last several years have opened up your firewalls to allow staff members access to your systems from their laptops, their mobile phones and their tablet computers?  Using internally developed applications companies are exposing their systems and data to be used from anywhere, anytime.  While this increases the productivity of your teams, it dramatically alters your security stance and increases the likelihood that the bad guys will find a way in to your organization.

As stated in the last posting – Microsoft used to be the poster child for products riddled with security holes that crackers played with like Swiss cheese.  There didn’t seem to be a day that passed where I was not hearing of some new exploit against the MS-Office products, Microsoft’s server products or Internet Explorer.  It finally became embarrassing enough to the company that in early 2002, Bill Gates sent an email to every employee of the company to layout the strategy of developing applications that were hardened against the hackers.

This event was not only a pivot point for Microsoft, who now has a pretty good reputation in the industry for developing hardened applications, but for the industry as a whole.  It became common for companies to talk about the processes they were using to develop secure applications.  In fact, development lifecycles were modified to incorporate security concerns/risks in at the beginning of the process and to track them just like any other requirement for the software.

If you have development teams on staff or on contract, on-shore, off-shore or near-shore, you need to ensure that you are building security in up-front in the process.  That means training your development teams on the concepts of secure development processes, design reviews that review all of the business and security requirements, threat modeling, static and dynamic analysis of the generated code, penetration testing and ensuring that your test cycle takes in to account security.

Here, I will harp on the need for development teams to build unit and integration tests up-front in the cycle that will not only hammer the system from a functionality standpoint, but will also attempt to break the software and test the ability of the application to secure data and ensure that they are not opening back doors for intruders to use to gain access to the systems.  These tests need to be constructed in a manner that they can be added to the larger pool of regression tests and live with the code through its lifetime within production.

Can you look across your code base and answer the following questions:

1. Is my entire code base subjected to nightly or weekly builds with automated unit, integration and regression testing in place?
2. How often am I reviewing the test cases to ensure that they are up to date and address security risks?
3. What tools do I have in place that allows me to know that my entire code base is being tested – code coverage?
4. Do the tools that I use allow me to identify and report on the most common security risks?
5. Do the tools that I use provide real-time or near real-time feedback to the development team identifying where issues were found and what remediation steps are needed.
6. If I have the tools in place – are they actually being used and is someone held accountable to follow up on errors/issues that are found by the tools?
7. If I have the tools in place are metrics exposed to the management team?

No one solution works for every company and every development team.  I’m not going to sit here and point out specific products that you can or should use – that’s for you and your teams to work through.  What I am saying is that if you haven’t started this conversation, you are late to the game and you are potentially exposing your organization to huge risks.

While it is all good to discuss the tool sets, you also need to work on the mindset of the organization.  From the CEO on down, management needs to understand the risks that exist and the costs associated with the change in process that will secure your applications.  Additionally, they can’t be sold a bill of goods – do not make promises that you will magically eliminate all risks.  What you are doing is raising the bar and making it more difficult for the cracker to get in to your organization.  Again, going back to the last post – 79% of all attacks on an organization were targets of opportunity.  Meaning, the companies in play did not pay attention to industry best practices and literally left the doors open for the crackers to walk thru.

I’ve seen companies successfully deploy off the shelf solutions, open source solutions and a mix of the two to meet the security challenges of software development.  Your challenge is to find the mix of solutions that will allow you to meet the needs of your software development lifecycle and the threats and risks of the systems you develop.

What actions can you take to improve the security stance of your software development lifecycle?

If you'd like more information on my background: LinkedIn Profile