In many organizations, there is not, yes, a well-defined line of responsibility for software security. The security professionals are responsible for security but they don’t understand the code, development cycles and pressures. And they don’t maintain the software. They have some responsibility for something that they cannot control.
On the other side, we have development teams and QA professionals. They have responsibility for delivering projects on time and within budget, but they don’t have the tools and/or process in place to effectively manage security vulnerabilities. Development organizations have to been given the tools for “secure” development but cannot be burdened with security management.
As CISO, you need a way to get these teams working together and to pass along responsibility for software security to those that create the software — whether they are your internal or external development teams. We aren’t talking about any mal-intention here. For the most part, software developers/IT haven’t been trained and given the infrastructure that they need to write code securely.
Two Challenges Facing Insecure Software
Because no one owned software security, the problem is two-fold.
Legacy systems were built in a different era – For many legacy applications, security was sufficient for their time and place of creation. With the uptick in devices utilizing technologies like Service Oriented Architecture (SOA) to increase access and scope, these systems are being put into scenarios they were not designed for. These systems and millions of lines of code have be scanned and scrubbed.
The second part of our challenge is preventing more insecure coding from being developed and introduced. This is what we mean when we say “build security in”.
Although many developers are becoming aware of software vulnerabilities, many don’t think about the malicious ways that hackers could attack their code. It’s not their natural instinct. And because development groups are often under tremendous pressure to deliver on time, adding the concept of security testing and resources is a luxury and not a necessity.