This is part two to my previous blog dated Sept. 11th, 2006. As I was coming into work this morning, I remembered that I had never finished my previous blog about why software development groups should ultimately be responsible for making their software secure and how we can help make that happen. That combined with a great viewpoint I read from Bill Joy titled “Software is not complete unless it’s Secure” inspired me to write this.
The most critical chasm to cross and have software developers be responsible for securing their applications is evangelizing exactly what Bill Joy titled his blog, i.e. Software truly isn’t complete until it’s secure. This day and age, it’s inconceivable to think that one can produce an industry quality piece of software without going through at least some “gates” and producing some necessary artifacts. Almost every Software Development Lifecycle would entail some level of Requirements gathering, Functional and Design specification, implementation, unit and system level testing, documentation, and finally deployment or shipment (depending on what type of software you are building). Notice, missing from this lifecycle was “Security”. Why? Well, you would have to refer to my earlier blog to understand the psychology of a developer. In a nut shell, developers like to ship software with the right set of features on schedule. To do this, you have to have an optimistic and “I can see the end” type of mentality. Security is all about a slew of “What if things go wrong” type of scenarios and the best security experts I have met during my career are very obsessive about the potential worst case scenario. These two mentalities are somewhat in conflict and alas the challenge of how do we infuse some negativity and worst case scenario analysis into software developers. BUT, let’s not dwell in doom and gloom and get down to the purpose of this blog. What is the solution?
The first thing I have learned through my experience dealing with Security concepts and working with a slew of our customers from various industry segments is that there is no “silver bullet” approach to Security. In fact my advice to you all is if any vendor walks in your office and says “Buy my set of tools and your security problems go away” is a vendor worth disposing of! Tools make *your* security *process* more efficient and streamlined. Notice the emphasis on *your* and *process*. Software Security is a process that is unique to each organization. The end is the same which is making your software asserts secure, however the means that each organization goes through to achieve that end depends on various elements such as, how well educated on security concepts the groups are, what type of a software development lifecycle is being deployed, how are the employees motivated, etc. Having said that, let me share some models that have proven to be effective in our customer base.
First model is what I call the “Gate” model. This is highly effective for Security groups in organizations that are trying to spread the need for adopting security processes across development groups and face resistance. The idea being that no software can pass through the “gate” before being deployed or shipped without going through a security process. Essentially, you are creating a point in the development lifecycle through which software can’t pass unless it adheres with your company’s software security policies. What I have found is that the annoyance of this obstacle will cause adoption upstream. It might take a while but you will get there. The incentive for developers becomes catching the vulnerabilities before hitting the gate to ensure their bits are not held up in the queue.
The second model which I also see with a number of our customers is what I call the “Champion” model. In this case, you still have a central security team but they would be acting in more of a program management capacity. Each development group identifies one or more Software Security “Champions”. The advantage with this is that the champions are essentially developers themselves, but they are developers that are more security savvy and knowledgeable. They would work with the Security Program Managers to ensure security processes are put in place and followed throughout the software development lifecycle. As such you would have special incentives for these individuals which would then motivate the other members of the team to become security savvy.
The Holy Grail and ultimately the third model would be the complete absorption of software security processes within development, QA, Build and operating groups. I think there will always be a need for a Chief Security Officer (CSO) and ultimately for a group of Security folks in an enterprise and that’s because the larger concept of security spans just software security, but it’s apparent that software security is where we need a huge push to happen soon. The good news is IMHO that the need is gaining tremendous momentum and we are definitely moving towards the right direction. In sales situations I find myself no longer talking about “Why Software Security is important” but more of “Which tools and processes you should be using”. Brighter days ahead!!!!
