The importance of security requirements elicitation and how to do it

The most of security flaws discovered in applications and system were caused by gaps in system development methodology. In order to cover this problem, it will be presented aspects of security development process improvement along product/project life cycle, in particular covering the best practices for Security Requirements Analysis.

Introduction

Nowadays, the information security is demanding a great attention due to a large number of discovered vulnerabilities in the applications/systems announced as secure. It is well known it is very hard to build an application with no bugs and/or security breaches, nevertheless, the companies cannot give up improving development processes and adapting them to the current scenarios.

Besides the several publications of academic researchers and industries about the importance of security practices in the System Development Life Cycle (SDLC), there is a paradox for implementation. Most of development centers fail to apply the recommendations due to resistance to new processes and mindset adaptation. It also common the engineers and developers are resistant to accept their applications are subject to security flaws.

Even the development teams understand the importance of new security paradigm for SDLC, although, they are concerned about it, unfortunately, this is not enough. In order to reach the security goals, it is necessary a detailed and deeply knowledge on security procedures and techniques. A comprehensive Security Policy (SP) is the most important reference to guide a security development and all hardware engineers, developers, application architects, software engineers, testers and project leaders must see it as a law. It establishes rules for all development phases: requirements, design/architecture, implementation, testing and maintenance, and shall define the responsibilities for all roles involved in development process. Also, establish rules for requirements phase must attend the security principles, such as information security, integrity, privacy, confidentiality, Information availability, continuity, based on environment and public threats to the system. Certainly, process and its implementation require preparation time and a detailed planning.

This presentation will cover the Security Aspects on Requirements Analysis, the first step of SDLC. This is the proper step to identify and define the security specification targets, the necessary methods for the system and how important these activities are. Next, a discussion about security principles that support Requirements Elicitation, analysis and specification disciplines is brought to the audience. Of course, a model must be flexible to fit all needs and it will be presented hints on how to adapt the Security Requirements Modeling and, finally, a practical case of study will be presented to demonstrate the concepts in practical way.

Security Principles

A considerable amount of applications and systems have been faced serious security threats due to the large number of new available technologies and the lack of knowledge and investigation about them. In the past, security concerns were basically around network infrastructure layers. Currently, due to the growing use of networks and the Internet concept dominance, such as cloud computing, Software as a Service (SaaS), serious vulnerabilities are being discovered by attackers in the application layer. Therefore, the concept of application security layer emerged as an essential task in the development process.

According to Federal Information Processing Standard (FIPS) (The National Institute of Standards and Technology (NIST), 2010) there are three security core principles that guide the information security area:

• Confidentiality: preserve the access control and disclosure restrictions on information. Guarantee that no one will be break the rules of personal privacy and proprietary information;
• Integrity: avoid the improper (unauthorized) information modification or destruction. Here is included ensure the non-repudiation and information authenticity;
• Availability: the information must be available to access and use all the time and with reliable access. Certainly, it just must be true for those who have right of access.

When these principles are broken, it is defined the level of impact that they can generate for the organizational information, organizational assets or individuals. Generally, the impact is qualified as:

• Low: generate a limited adverse effect;
• Moderate: generate a serious or critical adverse effect;
• High: generate a severe or catastrophic adverse effect.

Bringing to application SDLC, these principles can be sum up in four verbs with a simple explanation:

• Identify: allow users tell to application who they are;
• Authenticate: verify the credentials of users;
• Authorize: define the rights and permissions for users/third parts;
• Audit: do evaluation for users usability.

The core security principles are the pillar of security and must be whole understood until apply security for SDLC. It is recommended the book Information Security: Principles and Practice (Stamp, 2011) for readers who need additional security knowledge.

Security into Requirements Model

The analysis is the most essential activity to obtain the understanding between the development team and the business team. It maps the information to develop systems/applications in accordance to business and user needs, provided by stakeholders as high-level statements on features and functionalities.

In order to cover security aspects it is necessary to bring together business, development and security teams to understand the key sensitivities and business consequences caused by risk of security flaws. Since SDLC is a feed forward process and errors introduced in this phase will be spread in the next development phases, it is important to analyze security risks at very early stages.

Currently security requirements are categorized as nonfunctional requirements, which are usually defined as attributes of the software, skipping to be mapped to proper functional requirements and therefore, may not built into the software neither tested appropriately. However, what is the security impact if the security requirements are not captured or defined? Probably the result application may not be assessed for success or failure prior to implementation. Map the nonfunctional to functional requirements, the security requirements become a part of the overall requirements analysis process and, in this case, if conflicts are inevitable than they need to be identified and treated properly.

To show how this discussion has high security impact for application, the IATAC published the report Software Security Assurance (Goertzel, et al., 2007) where the authors met the main security-specific issues involved in requirements engineering, among them:

• The people involved are not likely to know or care about nonfunctional requirements. Stakeholders have a tendency to take for granted nonfunctional security needs;
• Traditional techniques and guidelines tend to be more focused on functional requirements;
• Security controls are perceived to limit functionality or interfere with usability;
• Stakeholders must understand the threats facing a system in order to build defenses against them;
• The users who help define the system are not typically the abusers from whom the system must be protected;
• It is more difficult to specify what a system should not do than what it should do.

Note that there is a high level of complexity to deal with this change, mainly for the stakeholders. In fact, they think about what their system need to do, instead of what it should not do.

After this brief discussion, all security requirements shall be captured by requirements analyst and analyzed by security team as part of functional requirements and added in the Security Requirements Specification (SecRS) document, which may be a section in the System Requirements or a Software Requirements Specification. Exhibit 1 show some expected information for the SecRS.

Exhibit 1 - Items waited on the SecRS document.

To reach good results during the security specification, the requirements analyst needs to spend special attention with the Stakeholders. He/she shall consider they have not enough security experience and so, there is a big chance to security be the last thinking. To avoid it, elaborating a questionnaire it is a good approach. The following example set of questions can help to establish the questionnaire roadmap:

• Secure against what?
• Secure against whom?
• What is to be secure?
• Who or what should provide the security?
• In which way will be the security provided?

Yet, knowing the security risks involved to the application and its impacts on the business can also facilitate the work. In this way, some examples of risks are listed in the Exhibit 2.

Exhibit 2 - Risk categories and the possible impact.

After the risk classification, the Analyst has two main activities:

• Define what need to be protected – Analyze assets and their value. A correct analysis of the asset values can facilitate the definition of the security goals and avoid unnecessary efforts;
• About what should be protected from – Analyst should have a good knowledge about the potential threats that can damage assets and the business. This activity helps to avoid mistakes when defining the controls to protect the assets and information.

With this information and going back to the security principles discussed in the previous section makes possible defining the actions to reach the security goals. Following, Exhibit 3 includes some examples based on OWASP Application Threat Modeling (OWASP Foundation, 2014).

Exhibit 3 - Actions to be performed to reach the security goals.

Summarizing, the security requirements must cover areas such as:

• Authentication and password management
• Authorization and role management
• Audit logging and analysis
• Network and data security
• Code integrity and validation testing
• Cryptography and key management
• Data validation and sanitization
• Third party component analysis

Tasks for Security Requirements Development

Certainly, some security models were proposed to treat the security concepts into the requirements phase. There are some well know security models, such as CLASP (Comprehensive, Lightweight Application Security Process) (OWASP Foundation, 2014), Secure Development Lifecycle (SDL) (Microsoft Corporation, n.d.), Security Quality Requirements Engineering (SQUARE) (Mead, Hough, & Stehney II, 2005), Secure Requirements Engineering Process (SREP) (Mellado, Fernandez-Medina, & Piattini, 2006), etc.

Looking at these models, CLASP model was chosen as base for the proposed set of tasks that can help the requirements analyst because it is a model developed “after years of extensive field work in which system resources of many development lifecycles were methodically decomposed in order to create a comprehensive set of security requirements”. Below, there are six basic tasks describing the proposed adapted model.

1. Specify Operational Environment

This task focuses on understanding the operational context and its relationship to the secure system building. In order to map the operation environment, the Analyst must perform the following activities:

• Identify requirements related to individual hosts – Identify anything that could be potentially security-relevant. For example, if the project is expected to interact with important system components or libraries bundled into the Operating System (OS).
• Identify requirements related to network architecture – The network environment brings concerns like topology, configuration details, available services, single-sign-on mechanisms and type of protection configured.

2. Identify Resources and Trust Boundaries

This activity gives an architectural vision on system security requirements. According to CLASP model, this task is composed by two activities:

• Identify network-level design – When it comes to identify network-level design, the most difficult work is to identify all product/software parts that depend on network environment. For example, client software middleware and any database should be identified. When identifying components, it is important denote trust boundaries, such as firewalls. A network-level design developed through diagram coding can facilitate communication.
• Identify data resources – For identifying data resources, the Analyst needs to identify data resources that might be used by the application as much granular as possible. Some example of resources include: databases and database tables, ACLs, cryptographic key stores, audit logs, configuration files, web pages, registry keys, etc.

3. Identifying User Roles and Resource Capabilities

Everything users may be able to do into systems needs a good understanding. It is common restricting sensitive operations applying the principle of the least privilege by binding capabilities to roles only when necessary. The Analyst must perform the following activities:

• Identify the Resources – Thinking in security vulnerabilities, threats could be originated in any place of system/product, therefore it is important to identify each resource and respective capabilities.
• Identify the User Roles – An important task for the Analyst is mapping the capabilities to the classes of users. In addition, it is necessary to define one role for every set of resource capabilities one might want to allow. It is recommended mapping roles to static sets of capabilities and specifying the default set of capabilities for the role as well as the maximum set of capabilities for the role.
• Establish the Access Control mechanisms – All the operations on resources shall be mediated via access control mechanisms such as reading, writing and executing privileges on a file system. Nevertheless, it is also necessary to control other operations that could be considered “meta-operations” are often overlooked as setting file ownership or reading and writing file attributes. Remembering the system, itself can have an implicit role (or set of roles) with all capabilities and mediates access to them (client-server application).

4. Document Security-Relevant Requirements

The Analyst must document the following requirements categories:

• Goals – This document must cover all information about security risks and additionally, determines risk mitigations for each resource – i.e., which risks on individual resources need to be addressed.
• Content – Risks on capabilities may differ depending on the lifetime of a system and, when specifying functional requirements for protecting data, it should be explicitly considered. If data-flow diagrams are available for the system, one should trace each core security service at each step, particularly assessing whether currently identified controls are valid at each trust level. Functional requirements should specify what mechanisms should be put in place to provide security services on resources. Such mechanisms address particular risks and if the chosen mechanisms may not address all risks, every time a new risk is identified, the security expert needs to insert it into requirements document and the mitigation plan must be updated. When a system has multiple levels of requirements, it is a good practice to divide in global, business and functional requirements.

5. Detail Misuse Cases

Sindre and Opdahl firstly proposed the misuse cases (Sindre & Opdahl, Eliciting security requirements by misuse cases, 2000), (Sindre & Opdahl, 2005), however, John McDermott and Chris Fox (McDermott & Fox, 1999) was the pioneers to show the concept of abuse cases. Although both means the same, the name misuse case seems to be more common and used. According to authors, “a misuse case is the inverse of a use case, i.e., a function that the system should not allow”. They also defined the misusers or mis-actors as the inverse of actor, i.e. “an actor that one does not want the system to support, an actor who initiates misuse cases”.

Based on those works and others from Ian Alexander, (Alexander, 2003), (Alexander, 2003), the requirement Analyst must identify the possible misuse cases using the following activities:

• Motivation – Sometimes potential risks may be lost during discussions with stakeholders or, they may not be comprehended. So, one interesting activity and recommended by several process, is the application of misuse cases.
• Goals – This is a specific technique to help the requirements Analyst to communicate potential risks to stakeholders. They are almost identical to use cases; notwithstanding, they are developed to detail common attempted abuses of the system.
• Content – Like use cases, abuse cases require understanding the system actors. Whenever possible, those actors should be mapped to capabilities. For each one should be designed misuse cases starting with high-level and refining them after a good understanding. It is possible to develop misuse cases recursively, going from system to subsystem levels or lower as necessary. Lower-level cases can highlight aspects not considered at higher levels, possibly forcing another analysis. It is recommended the important misuse cases should be represented visually through a shaded background. For when misuse cases were not depicted visually, and they are still important, they should be documented explicitly.

• Security threats are rarely neutralized completely by mitigation measures. Thieves pick locks and break into systems through unsuspected access paths. Partial mitigations are still useful as long as they afford a realistic increase in protection at reasonable cost. The goal of neutralizing all possible threats is of course wishful thinking and cannot be stated as a requirement.
• According to Lan Alexander (Alexander, 2003), “there is a clear relationship between the hostile actors who initiate misuse cases and exception classes (i.e. exception classes are simply named categories of exception, situations that cause system to fail)”. The author shows devising threats and malign agents with misuse cases sometimes are a more powerful technique than simply stepping through a template or thinking about exceptions. By inverting the problem from use to misuse, it opens a new avenue of exploration, helping to find requirements, which might have been missed.
• Defense mechanisms should map directly to a functional requirement, or, in case of defense mechanisms be user-dependent, it should be inserted in an operational security guide.
• Besides, they help to discover exceptions classes, misuse cases may be used to help in other phases as test and design. For example, for test phase, it can help tester engineer to define the test plan and for design phase, to design trade-offs. Nevertheless, the main and most important contribution of misuse cases is probably related to the risk analysis process.
• Some kind of diagram tools can help to create misuse cases. It is also possible to use simple text tools with graphic capability as, for example, UMLsec or SecureUML (Jürjens, 2002).

6. Review Security Requirements

Reviews are good activities for security analysis. Therefore, although the resistance from Analysts, the review can avoid flaws in the understanding of security requirements. It is recommended that both Analyst and the Security Team make the review. Many times, even after two or more review from Analyst it is common the security team find bad description about the security requirements. Furthermore, generally the security team has more security skills that requirements Analyst and acts as a third party review.

A good practice for review security requirements is the confrontation of analysis between Analyst and the Security Team analysis. This approach can be seen as a trust checking and can avoid misunderstanding.

A Study Case

This section summarize the proposed methodology in practical example to perform a Security Analysis. The Requirements Analyst can describe the application using different tools, such as informal drawings, pictures, sketches etc. The Requirements Analyst also can use high-level risk tables to help the security requirements definition. Exhibit 4 and Exhibit 5 give a macro vision about the security goals, presenting methods that can be used to achieve the protection or mitigation and some tools that may be used to help.

Exhibit 4 - Security Quality Sub factors and Associated Measures

The content should be reviewed during the initial analysis and/or always when some modification is necessary into application.

Exhibit 5 - Security Measures and Associated Mechanisms

The Exhibit 6 presents an example of security requirement table, suggesting the priority level.

Exhibit 6 - Example of a Security Requirements Table

Misuse cases can be presented by either describing extensively the fact or/and by diagrams/flows/figures as illustrated in the Exhibit 7, which presents the misuse case for a typical Address Book application, using the UML notation as seen in (Jürjens, 2002).

Exhibit 7 - An Example of Misuse Case (based on UMLsec)

Exhibit 8 shows one misuse case, Spread Malicious Code (presented in the Exhibit 7), using an extensive version. This approach allows the Test Analyst to create test cases for Security Requirements.

Exhibit 8 - Misuse Case Detailed Example

Conclusion

Capture and treat the security requirements may do a great difference in the final system implementation. Several researchers have been studying and proposed new models to simplify this complex task for the requirements Analysts. In this work, we presented a discussion about the security into requirements phase. In addition, we showed six tasks method that may facilitate the Analysts activities, illustrated by a practical study case that can be adapted and used by readers.

Looking at those activities, we call attention for misuse cases that present a visual form to see the security requirements. According our studies and experience, they are the best form to elucidate complex security requirements when the most of applications have presented a growing complexity to development.

Finally, we have been seen two serious flaws in the security for requirements analysis phase at companies: the lack of security skills for the Requirements Analyst and the negligence with security role into business applications. We are working to change it and we urge all project managers to think out of box and add the security as priority for their applications.

References

Alexander, I. (2003, Feb). Misuse cases help to elicit non-functional requirements. Computing & Control Engineering Journal, 14(1), 40-45.

Alexander, I. (2003, Feb). Misuse cases: use cases with hostile intent. Software, IEEE, 20(1), 58-66. doi:10.1109/MS.2003.1159030

Goertzel, K. M., Winograd, T., McKinley, H. L., Oh, L., Colon, M., McGibbon, T.,… Vienneau, R. (2007). Software Security Assurance State-of-art Report (SOAR). Information Assurance Technology Analysis Center (IATAC); Data and Analysis Center for Software (DACS). Herdon, VA: Information Assurance Technology Analysis Center (IATAC).

Jürjens, J. (2002, Sep). UMLsec: Extending UML for Secure Systems Development. Lecture Notes in Computer Science, 2460, 412-425. doi:10.1007/3-540-45800-X_32

McDermott, J., & Fox, C. (1999). Using Abuse Case Models for Security Requirements Analysis. Computer Security Applications Conference, 1999. (ACSAC '99) Proceedings. 15th Annual (pp. 55-64). Phoenix, AZ: IEEE. doi:10.1109/CSAC.1999.816013

Mead, N. R., Hough, E., & Stehney II, T. R. (2005). Security Requirements Engineering (SQUARE) Methodology. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Retrieved January 10, 2015, from http://resources.sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_14594.pdf

Mellado, D., Fernandez-Medina, E., & Piattini, M. (2006). Security Requirements Engineering Process. Lecture Notes in Computer Science, 4189, 192-206. doi:10.1007/11863908_13

Microsoft Corporation. (n.d.). Software Development Lifecycle. Retrieved January 10, 2015, from Software Development Lifecycle: http://www.microsoft.com/security/sdl/default.aspx

OWASP Foundation. (2014, July 25). The Open Web Application Security Project (OWASP). Retrieved January 10, 2015, from The Open Web Application Security Project: https://www.owasp.org/index.php/Main_Page

Sindre, G., & Opdahl, A. L. (2000). Eliciting security requirements by misuse cases. 37th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS-Pacific 2000) (pp. 120–131). Sidney, Australia: IEEE. doi:10.1109/TOOLS.2000.891352

Sindre, G., & Opdahl, A. L. (2005, Jan 01). Eliciting security requirements with misuse cases. Requirements engineering, 10(1), 34-44. doi:10.1007/s00766-004-0194-4

Stamp, M. (2011). Information Security: Principles and Practice (2nd ed.). Hoboken, NJ: John Wiley & Sons, Inc.

The National Institute of Standards and Technology (NIST). (2010, February 24). Federal Information Processing Standards Publications (FIPS PUBS). Retrieved January 10, 2015, from Information Technology Laboratory Homepage: http://www.nist.gov/itl/fips.cfm