Building Security in Requirements

Background:

Every software application or product is developed based on business expectations. If we want to build a secure product or application, it is inevitable that we ensure that THE security is built into the product and requirements is no exception. This article will focus on various aspects that a security analyst needs to focus on when building security into Requirements Phase.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

Aim:

The aim of this article is to focus on introducing security analysts to a methodical approach using which they can effectively build security into Requirements Phase of the SDLC by introducing Security Requirements.

Intended Audience:

This article is written predominantly for Security Leads or Analysts who technically drive security into the SDLC. It can also serve as an overview or ready reference for management officials who are accountable for ensuring successful procedural integration of Secure Development Programs for their respective organizations. This article will serve as a detailed guide for such management officials who love to get into the details instead of managing overall projects,be it for the improvement of their own knowledge base or for laying out an effective management strategy by knowing the detailed roadmap.

Structured Approach:

One of the major aims of this article as highlighted before is – to introduce users to structured approach to build security requirements. To arrive at a list of security requirements for a software application or product, we need to perform certain steps (need not necessarily be in a sequence, though).

1. Budgeting for Security
2. Understanding Project Stature
3. Analyzing Business Requirements
4. Mapping Compliance Requirements
5. Analyzing Vendor Contracts
6. Analysis of Open Source Library Security
7. Finalization of Security Requirements
8. Revisiting Security Requirements on a need to basis

During this article, we’ll expand on the above steps and understand what we need to do as a part of each step eventually work towards achieving our final goal – listing down security requirements. The following is a pictorial representation of the approach we are going to follow in this article.

Although all process steps need not be in sequence, some of these steps have to be executed first and rest of them later on. Budgeting for Security is one such example. If a project does not have budget allocated for security, performing the rest of the activities may not be very fruitful.

• 1. Budgeting for Security:

Every organization follows a lifecycle for developing software, however not every life cycle will be similar. Some life cycle’s explicitly have a phase known as ”Inception”, where they address all requirements which are pre-requisites before a software project is started. This includes getting high level approval from management, allocating appropriate funds or budget to the project, analyzing the cost benefit analysis and many can include more things. However, some organizations may not do it necessarily. Small & Medium Enterprises (SME) can be one such example. Many SME’s do not have a mature software development process in place.

In such scenarios, it is best to do a sanity check first before running into actual execution for building security requirements. If the budget allocation for security resources has not been performed, we should follow up with management for the same and ensure that it is done.

• 2. Understanding Project Stature:

It may surprise some readers as to why we need to worry about project stature when we are in requirements phase! We already know this – don’t we? Well, yes is a short and sweet answer. However, this is an important step in our approach, as not all software projects are first timers. If the software application we are currently evaluating is a version enhancement, what then? This is what this section tries to address. Some of them can be minor enhancements, while some can be version upgrades of existing products.

It is important to understand the background before pushing our agenda on the project. A half-baked security requirement can cause more problems than it would have otherwise addressed.

If the project is a version upgrade, we first need to have a list of existing security functions or modules which are supporting the product’s core security. Next, a set of security requirements may be merely ensuring that new business requirements are implemented securely. Alternately, if the product does not have much built in security, it is a security analysts job to ensure that appropriate security requirements are listed down and the same be incorporated into upcoming version of the product. Some of our security requirements can be extracted by understanding security requirements of prior version as well.

• 3. AnalyzingBusiness Requirements:

For a Security Analyst who is working towards listing down security requirements for a project, it is very important to understand business requirements clearly to understand if there are any imperative security requirements embedded within such business requirements. Insight is required to extract such security requirements and ensure that they are a part of security requirements list – which once drafted and conveyed will be embedded into the software when it is designed and developed.

Example:

Let’s assume that the business requirement is that an application should have 4 roles:

• Normal User
• Maker
• Checker
• Administrator

Any skilled security professional will be easily able to extract a security requirement from this business requirement. The security requirement here is – “Secure design & implementation of authorization matrix”.

This is what we as security analysts need to do – extract explicit and implicit security requirements from business requirements

We can extract some security requirements by analyzing business requirements, however this is not complete list. Additional security requirements can be identified, as we’ll cover in upcoming sections.

• 4. Mapping Compliance Requirements:

An application may be subject to both internal and external compliance requirements. Examples of external requirements can be PCI DSS, HIPAA, etc… while internal compliance requirements will vary from organization to organization.

Nonetheless, both these requirements are quite important. If the organization is developing a financial product dealing with credit or debit card data, then PCI DSS compliance is applicable. While these requirements may likely come via management itself, if there’s a reason as to why it is missed, it is a security analyst’s job to ensure that such requirements are addressed and are a part of final security requirements list.

Security Requirements identified from this phase should be appended to the previously listed security requirements and we should continue doing this until the list is finalized and we have addressed all the steps in this approach.

• 5. Analyzing Vendor Contracts:

If this application is going to be developed by a third-party vendor or if the vendor is partially involved in development process, then we need to ensure that our organization’s security model is being adhered to, by the vendor in question. He needs to perform all formalities like signing Non-Disclosure Agreements, formally understand and agree to risks in case of security breaches happening because of vendor’s oversight and similar other issues. We need to ensure that security requirements that are identified for the product in question are to be addressed by the vendor who is going to develop the product on behalf of our organization.

Security Analysts need to ensure that all these activities have been completed and verify that organization’s policy and procedures are being adhered to when software development is being performed.

• 6. Analysis of Open Source Library Security:

As discussed before, some projects may be version upgrades. In such cases, security analysts may have the luxury to know if the application is already using any kind of open source libraries. If such libraries are in use, security analysts need to ensure that any vulnerable version of such library is not in use.

If a final product containing vulnerable version of library is shipped to the client for deployment, the risk is huge. Not only is the client at risk, but also the organization which has developed the product is risking their reputation. If any external auditor, independent security researcher or even a client’s internal security team for that matter, is able to identify vulnerabilities in such libraries, it will have a direct impact on organization’s reputation.

Even worse, if the client’s application is compromised because of this, not only will it impact them, but will indirectly also impact the organization which developed such vulnerable product as prospective clients will be cautious and may opt for competitor’s product instead.

For projects which are developed from scratch, someone from the development team has to undertake the responsibility of fixing such issues, as timely support can’t always be expected from open source community. Delegating this liability to internal product team will ensure that someone owns the responsibility to release a patch in case if vulnerabilities are identified in these libraries.

Formal documentation should be maintained – where in who has undertaken such responsibilities are clearly documented. This should be a helpful as a future reference.

• 7. Finalization of Security Requirements:

In this stage we will consolidate all our security requirements which have been identified so far from various steps we have performed previously. Review these requirements to ensure that we have covered all security requirements before sharing the same with the product development team.

Although not explicitly mentioned anywhere in this article, we also need to take into account the risk profile of the application. If the application falls under a critical or high risk category, security analysts should pro-actively suggest some additional security requirements to ensure that the application is having good security features and is capable of facing tough security risks it might otherwise face because of the nature of the application and taking into consideration the business expectations from the same.

Once we have all the security requirements, security analyst should track them till closure. Closure happens when these requirements are implemented as per security team’s expectations.

• 8. Revisiting Security Requirements on a need to basis:

Software Products or Applications evolve over a period of time. There are new business requirements added and sometimes the products undergo a complete redesign based on business expectations.

When such situations arrive, security team should revisit the security requirements based on the changes which are planned to be implemented. Some existing security requirements can be dropped on one hand; while on the other hand, some more security requirements can be added.

The Security Team should have a provision for such scenarios in their policies and procedures and should adhere to them on a need to basis.

The following table lists down sample security requirements for reader’s reference:

Sr.#

Questions

1 Application should implement Authentication

2 Application should ensure that Organization Defined Password Policy is implemented

3 Application should implement secure Authentication and Authorization Matrix

4 Application should not store credit card numbers

5 Application should generate logs for important security events

6 Application should use secure development framework from the list of frameworks which have been approved by the security team

7 Application should Implement a secure Input Validation Framework

8 Application should implement a secure output validation framework

9 Application should secure sensitive data by encrypting them using approved encryption algorithms

10 Application should never hard code “encryption keys”

There can be many such security requirements that can be listed. The above listed requirements are only for reader’s ready reference and should not be confused with a final list. These requirements change from project to project.