Software security still has an aura of secrecy and mystery, and some people still think that security experts are magicians that can secure a product with a tip of their wand. Some self-appointed “security gurus” actually play a big part in creating this mystery and keeping it alive, because they make it seem as if it there is no structured approach to software security and that a security guru is a crucial part in building secure software.

This is, however, not true. Building secure software can be a very well structured process, which makes it reliable and, as importantly, repeatable. Process repeatability and consistent metrics are as important for software security as for any other aspect of structured software development.

Software security is not security software. Software security is about building things properly. Applying magic fairy dust in the form of cryptography, security tools, or pen testing consultants does not automatically make software secure! An important person to have on your team however is a good Security Architect. Security Architects can cover a broad field, which includes supporting the team with application design, establishing and supervising execution of a secure development process, project and program management, engagements with key customers (pro-active and in case of a security breach), securing operations of cloud solutions, and fire-fighting in case something went wrong. Good Security Architects are hard to find, because they must not only be experts in security and master architects, but also have advanced people skills to master the daily tensions of conflicts arising from competing requirements and at the same time be presentable to key customers.

A product does often not primarily sell because it is secure, but it will often miserably fail if it has security issues. Consequently, the Security Architect needs to work closely with product management to balance new features that customers are pushing for against security requirements and defects that must be fixed, but for which customers are usually not paying for directly (and in the best case do not even know about). While Security Architects are often empowered to stop a product release if they have major security concerns, they should use this power very wisely and rather secure a product by creating superior designs that address both security concerns and provide new distinguishing features.

This kind of work often starts by gathering security requirements from customers, creating a design that covers both the functional and non-functional requirements (often in collaboration with other domain architects), and then coordinating the work of several R&D teams to implement the specs and turn them into a secure product.

I will create a series of posts to review one possible embodiment of a secure development process, covering everything from the early requirements analysis stage over the design analysis to implementation and secure operations.