I posted earlier about how development organizations need to start rewarding and punishing developers based on how well they implement security. Very few organizations do this and I think this gets at the root of what makes so many CSOs we work with so nervous about application and software security.
CSOs understand the risks inherent in exposing sensitive assets via web applications and from most organizations standpoint they are held accountable for successfully addressing that risk. Unfortunately they don’t have the ability to directly impact the security posture of the applications. If they wanted to close down a port on their firewall either they or their reports could do it themselves. With applications, however the developers who are ultimately responsible for software security report up through one or more different chains of command. That means CSOs are held accountable for application security with little ability to directly influence the outcome. Unfunded mandates are bad enough for executives to deal with. Untenable mandates are even worse.
So what is the solution? It doesn’t make sense for development teams to report to the security office – that would be silly. Someone from higher up in the organization needs to understand the situation and help moderate between the different groups that report up to them. In organizations with a centralized IT organization this is probably the CIO. This person should be able to weigh the business concerns and arbitrate disputes between security and development.
But what happens if an organization has developers that don’t report to the CIO. Does the CEO need to be bothered? Perhaps but that is not going to happen – at least not on a day to day basis. During one of our recent CSO Roundtables there was one individual who was describing their organization’s practices for security and software development and they were very mature in this area. When asked how he had managed to make so much progress he mentioned some points about security being an organizational priority and whatnot. And then he said “Oh yeah. I also bike with the manager of the software development group.” These information channels allowed him to make exceptional progress in the area of application and software security without formal organizational support.
Besides taking up bicycling, what can CSOs do to build bridges between development and security?
- Take a developer to an ISSA meeting. Or tag along with folks headed to a Java or .NET User Group.
- Schedule internal brown bag lunch sessions to get developers familiar with information security basics (Confidentiality, Integrity, Availability…) Have developers present to the security group about how their software development lifecycle (SDLC) operates.
- Put security architects and applications architects in the same room for a session. Or better yet – have them office together and let the ideas flow.
Software security can only be supported by scanners, analyzers and other drop-in products. It cannot be accomplished using these tools. The only real solution is for the individuals responsible to have the knowledge they need to make the right decisions. The cross-disciplinary nature of the problem requires a cross-disciplinary solution so get the right folks talking to one another.
dan _at_ denimgroup.com