Over the fence. That’s a phrase I use all the time when talking to my teams. They’re probably tired of hearing it by now. I use it to describe the phenomenon that commonly takes place within organizations for an individual issue, problem or even recommended solution that gets “completed” by one group and then gets “thrown over the fence” to a different group to continue.
Within a traditional software development lifecycle, this method actually can be codified with hand-offs and division of responsibilities. Within a waterfall approach to software development, this is not only common, but is encouraged and arguably necessary. Why necessary? Simply because individual teams are focused on individual deliverables and cannot possibly share responsibilities outside of their specifics subject matter expertise, and expect the work to get done on time.
Agile lifecycles, in effect, are intended to offer another alternative and possible solution to this silo. In the context of security, traditionally the security team is brought in at the beginning of a project to oversee the requirements and then become uninvolved in the actual development and implementation process. They are then re-engaged just before making the software generally available and the entire project is “thrown back over the fence” to the security team for a last-minute general assessment. Fundamentally, teams and subject matter experts, in this case, represent their particular functions well, but don’t work together on the solution. Fences are barriers.
Product Management, Meet Security
We’ve already talked in this blog about how security needs to be integrated into the software development lifecycle, and not simply as an advisor at the beginning and at the end. But where does product management fit in? Some organizations have security-minded analysts who are focused on writing specific security based requirements. Others assume that security is simply an IT oriented function, and expect the security team to employ their own methods in order to ensure that a product is secure and are thus uninvolved directly with the security team as product managers.
An integrated security model needs to integrate product managers throughout the entire life cycle. Product management needs to take into account security from not only an analyst perspective but from a strategic perspective as well. An example of this can be treating secure features and functions within an application as a specific area of innovation. Instead of focusing an analyst on a specific set of requirements that are more reactionary. Secure product management specifically looks into areas where a product can actually innovate and be altogether proactive in its approach to secure software development. Instead of simply reacting to guidance, security innovators can develop strategies that anticipate future concerns, while offering end users stronger security with the best customer experience possible.
Security is not a team. Security is not a function. Security is not someone else’s problem. Secure products are not built as a reaction to threats. Product-lead organizations that are security-focused innovate by integrating secure practices and new specific security oriented features into their cutting edge products.