Once the main epics of a product release are known, the team can get into a more detailed “what needs to be built” analysis, and even get a first high-level understanding of the “how”.

The majority of the main functional and non-functional requirements can be derived from the product vision. During the requirements analysis, this initial set of requirements becomes more detailed and the architects start adding more comprehensive requirements that are, for instance, derived from best practices. In this step, the Security Architect will start a security requirements analysis to add to the requirements pool for the project. Eventually, this pool will translate into user stories and tasks and be assigned to PSIs (when following an agile development model like SAFe), but we are not quite there yet!

The security requirements analysis usually starts with an analysis of the product’s target market. As an example, if the product is meant to be sold to medical offices in the US or meant to process credit card payments, a lot of mandatory requirements derived from HIPAA and PCI respectively must be implemented by the product, or it cannot be shipped. On the other hand, if the product is mostly used by consumers, there are a lot of best practices that drive requirements for the product, but many of them are not mandatory for the product to be released.

Once the target market has been determined, the Security Architect should reach out once more to product management and marketing to understand if there are specific features that would allow the product to perform better in the market. Commonly, the Security Architect will help marketing and product management to analyze products of competitors, and suggest improvements that would distinguish the product from the competition. Trivial examples include offering encryption or privacy protection where competing products transfer or store data in plain text, implementing strong auditing and giving the customer easy access to such data, and offering secure and innovative authentication mechanisms where competitors only support username / password based authentication.

Security requirements are often derived from laws and regulations which are often far outside the comfort zone and experience of most developers and product architects. Security stakeholders on the customer side are business information security managers and chief information security officers (CIOs) who speak a language of their own, often leading to misinterpretation of the provided non-functional requirements by the product team. A Security Architect performing the security requirements analysis understands both the relevant legal regulations as well as the language used to correctly interpret them, and translates them into a language commonly understood by product development teams to ensure regulatory compliance.

After these preparatory steps have been completed, the Security Architect commonly works with the product architect(s) on a weighted and prioritized requirements list that ties back to the original target market analysis and also shows the inter-requirements dependencies. This requirements list is meant to help product management decide which security feature to implement for a specific release. It is a decision tool that allows product management to understand that if they want to sell the product to a specific market segment, or sell the product in a specific country, the product has to implement specific requirements. Also, the list might have some “non-negotiable” requirements, which must be implemented e.g. to satisfy corporate security policies.

Highlighting requirements inter-dependencies helps with coarse-grained effort estimations. As an example, if requirements X, Y, and Z depend on a complex set of requirements A, B, and C, and X, Y, and Z are required to sell in a specific market, then product management might decide to delay this feature set for a release or two to allow some extra implementation time to implement A, B, and C first, and rather focus e.g. on a different country in the first release.

At the end of the requirements analysis, the product team should have a clear understanding of what needs to be built to address both short-term and long-term security and privacy concerns for the specific target markets, as well as which requirements to implement first, and options of how to implement them so that they can start the product small and grow it long-term, without painting themselves into a corner.

For the majority of software products, security is primarily a cost factor. Regular readers of my blog keep asking me how they should afford all these expensive and time-intensive security counter measures like code reviews, code analysis, and pen testing.

It is interesting to see that the majority of security related costs in many products still accumulate at the end of the development lifecycle. The closer a product gets to its scheduled release date, the more investments in security are being made. I frequently still see a “test security in” approach in products that quickly evolve in the beginning without considering security, while there are few product teams that try to get the security related parts of the product right in the first place to avoid the high costs of extensive late-stage security counter measures and, in the worst case, major design changes in a late development stage.

Security vulnerability aggregators like the NVD and the underlying security vulnerability databases list around 60 thousand different publicly known vulnerabilities. There are indications from research performed by IBM that the number of actual security vulnerabilities that are not publicly known could higher by a factor of 20, which indicates well over a million open or latent security vulnerabilities in major products that are tracked in the NVD.

The cost of fixing a defect at various stages of the development lifecycle grows exponentially from the requirements stage over design, coding, testing, and maintenance. This observation lead to the undisputed statement that attempts to test quality into a product are generally futile, at least when cost is a factor to be considered. As security is one aspect of software quality, the statement also holds for the unfeasibility to test security into a product. Yet, the pen testing tool and consulting industry is booming, and while many software vendors use security testing tools and pen testing, few are using security requirements and design analysis early enough in the product lifecycle to prevent security issues in the first place and avoid the horrid costs of fixing security defects after the product has been released.

To change a product team’s Secure Software Development Lifecycle (SSDL) approach and ensure acceptance, it is important to meet a product team where they are, and not try to force new development models on them when they are not yet ready for a major change. When working with product teams, I generally try to establish a more proactive model than what the team is using, presenting various options and recommendations, and then work with the team leads to find out what works best for them.

Typically the best solution is to use all of these approaches as needed in a closed-loop SSDLC program, investing most of the available resources in the proactive counter measures, then in the automatable counter measures, and least in the manual and most reactive counter measures.