One of the most ignored parts of a security enhanced software development life cycle is the security requirements engineering process. One of the prime reasons for this oversight is that security is assumed to be a technical issue and therefore best handled during architecture and design or better still during implementation. Since software requirements are often written by business analysts who are non-technical, this is a common conclusion.
The problem with this approach, as any experienced software professional would tell you, is that software which does not have its requirements elicited, enumerated and well documented will most likely be lacking in quality. This is because developers do not have a specific target with regards to embodying security into the design and implementation. Further, quality assurance folks have no benchmark to validate the software against, and traceability - a key software engineering attribute - is unachievable. In fact it is hard to even build a good threat model without a clear idea of the security requirements.
This is a well understood concept in the general field of software engineering. A lot of research has been performed on how to effectively elicit, validate and document software requirements. Further, most modern SDLC support tools already provide some mechanism for documenting requirements . Hence, it should not be too difficult to extend these systems and the process itself to include security requirements. The challenge however as mentioned above is that most organizations we work with are used to thinking solely about functional requirements – requirements that the system and business analysts writing them can put their arms around. What different widgets should the application have? How should it respond to the click of a button in the top right corner and so on? The non-functional requirements on the other hand are often marked as “N/A”. Our findings have been that this is not necessarily because they are considered unimportant, but because they are assumed to be de facto requirements – “the developers should know better than to build a slow or insecure or unreliable system”. The assumption always seems to be that these requirements would be obvious and hence don’t need to be documented.
On examining this problem a little bit further, we discovered that the problem to a large extent was a lack of awareness and knowledge of the people writing the requirements. The non-functional requirements can be very technical –consider specification of the encryption algorithm, cipher mode, key lengths and rotation parameters. Defining requirements around all of those would typically require a detailed understanding of the mechanisms around cryptography - not something that is typically found in the job description of a business analyst.
As a solution to this issue we present a template driven approach which is designed specifically to help the non-technical stakeholder to define very technical security requirements. While this approach does involve some amount of prior effort to create the templates, we have seen it to be tremendously effective in both ensuring that security requirements are documented (and not just with “N/A”!) and then implemented and tested.
The first step in this approach is for an organization or team (depending on the size and variety of applications involved) to identify all the relevant drivers for security requirements that would, could and should influence development. In our experience, most often you will see a lot of commonality among the various applications developed within the organization or team and hence we attempt to leverage that commonality and thus gain efficiencies across multiple projects
In our experience it is best to think about these drivers along the following categories. As mentioned above, most of these drivers will influence many, if not all, of the applications churned out within an organization.
· Regulatory Compliance – This involves specific requirements that would be mandated by various governmental agencies. Depending on the legal environment within which the organization operates and the application’s scope, a number of regulations could be relevant.
· Industry Regulations and Standards: These include typically standards that are specific to an industry such as financial services. This category in our classification is also setup to include standards bodies such as ISO and the norms they define.
· Company Policies: Most organizations that we work with have a slew of internal policies that should and could affect the development of an application.
· Security Features: Finally, most applications will have some form of security feature. For instance, authentication and authorization models that replicate real world role based access control. Similarly, administrative interfaces that will be used for user management including provisioning and de-provisioning.
For some of the above axes it is best to work with the legal department and internal audit to arrive at the list of relevant regulations. Once that superset has been defined, the next step is to examine each of these regulations through the eyes of both someone who speaks legalese and a software development expert. The aim here is to convert the list of legal requirements which would guarantee compliance to a set of core technical requirements for software that is impacted by these regulations. The Foundstone Security Frame can come in extremely handy here. For each of the relevant drivers from above consider the various categories in the security frame and how they might be impacted. For instance, if your organization is regulated by Gramm-Leach-Bliley Act (GLBA), privacy of personally identifiable information (PII) is absolutely critical. This in turn can have implications across multiple Security Frame categories not the least of which being Data Protection in Storage & Transit. The outcome of this step should essentially be a set of specific requirements along the various security frame categories that would satisfy each of the applicable drivers defined above. It is vital at this stage to also rationalize the various requirements obtained above getting rid of overlapping or redundant requirements.
A parallel step in this requirements process is to classify the applications as being impacted by the drivers. In our experience this is best done by creating a large matrix with the various drivers above forming the columns and the application set forming the rows. Classification then is the task of checking the appropriate boxes depending on whether, based on legal and other opinions an application is impacted by a specific driver.
As a result of the two parallel steps mentioned above, the team should now have a specific set of technical requirements for each application based on its requirement driver environment. All of the above effort is intended to be performed once and then revisited periodically. In our experience, it is very rare that these change very often or with each application release. This is primarily because applications tend to evolve very slowly with regards to the drivers mentioned above. Further, as mentioned above there is much opportunity to leverage commonality across applications as well since it is not atypical for many of the applications to be operating within a similar driver environment.
Having now defined this universal set of requirements a priori, as each application release is defined; the specific set of requirements for that release can be drawn out of this set. As part of this process, the data classification and privacy policy can help to identify which data elements handled by the application are impacted by the drivers. Additionally, it is also important to consider which features being added in this release would be impacted as well. Based on these pieces of input and the universal set of requirements a subset of those requirements will be obtained that are relevant for this specific release of this specific application. The person formulating these requirements now need not be an expert in security or any of the security frame categories but can simply check the appropriate boxes to obtain a set of requirements. In fact this last per application step can be easily automated through a template or lightweight application which references all the relevant policies, the universal set of requirements, considers the data elements in use and provides a set of technical requirements that may leverage encryption, access control and other security mechanisms. These can then literally be copy-pasted into the master requirements list.
To wrap-up this section let us consider an illustrative example. Take for instance, an online loan processing application. Such an application will obviously make extensive use of personally identifiable information and is determined to be impacted by the Gramm-Leachy Bliley Act driver. This in turn defines specific requirements around the confidentiality, integrity, availability and access to data as well as audit trails that monitor and report on such access. Now consider that a new feature is being added that emails the result of the loan decision to the customer. When a business analyst is defining the requirements around this new feature, he / she would need to consider all of the different data elements that would be part of this email, the transport mechanism used by the email and authentication around it. Based on business need and security, it can then be decided to avoid certain data elements or perhaps use a secure email solution.