Chapter 4. Requirements and Constraints
Requirements for an information system give a specification or description of the functional capabilities a system should deliver, along with characteristics or qualities it should adopt. Mandatory external and internal demands placed on a system turn requirements into constraints.
People often use non-functional requirements, architectural characteristics, and qualities interchangeably. They all refer to the same sort of requirements that define the approach to system delivery. We will discuss this further later in this chapter.
Documentation of requirements happens in different forms, depending on the type of requirement and the types of development and delivery methods. In this chapter, we will discuss the different techniques and focus on those techniques that are most appropriate for the definition of security requirements.
Finally, we will look at how traceability of requirements through the documentation of the architecture, operational documentation, and testing is essential to providing confidence in the delivery and operation of the requirements.
Chapter Artifacts
This chapter’s main goal is to discuss the definition and documentation of security requirements for a system. Figure 4-1 highlights, with white text in a black shaded box, across the top of the artifact dependency diagram the requirements and constraints that come from the external and internal context of the organization. In the requirements domain, we highlight artifacts for the definition of functional and non-functional requirements, with the requirements traceability matrix highlighted at the bottom right.
Figure 4-1. Requirements and constraints chapter artifact dependency diagram
We’re going to start with a discussion on some concepts about requirements that will frame the discussion of the artifacts used to describe requirements.
Requirements Concepts
Requirements give a description of what an information system must deliver and offer guidance for the development of a solution architecture. They specify the functionality, architecture characteristics, and constraints of a system. Let’s discuss this in a bit more detail.
Functional Requirements
Functional requirements describe what an information system is to deliver. In other words, they define the functional aspects of the information system as delivered by software. Functional requirements describe the sequence of activities, when they start and end, the inputs and outputs, and the behavior and processing of the data.
The second characteristic of functional requirements is that they describe the primary functionality provided by the system, such as placing an order for a product online. For security, this could be describing the sequence of steps for a customer to log into an online store but not the login sequence for the system administrator, which is a non-functional requirement. However, the techniques and artifacts used in describing the requirements can be the same for both.
Security can bring additional perspectives to consider when describing functional requirements. What are the decisions that affect the security of the system? How do we record activities to provide an audit trail? How do we monitor for activities that may be a threat to the system?
As an architect, you may be thinking that gathering requirements is the job of a business analyst or a security consultant. Even if someone else gathers those requirements, you will be accountable for the security architecture, and therefore you need to ensure that you receive complete and high-quality requirements.
When you have the complete context, you need to be able to challenge and modify non-security requirements, as they may have a negative impact on other characteristics of the system. Examples of this might be whether the application uses multi-factor authentication for login and whether it’s mandatory for authenticating certain transactions.
Non-Functional Requirements
Non-functional requirements describe how the information system should deliver the required functionality. They’re often described as the architecture characteristics of the system and include security, privacy, scalability, availability, recoverability, usability, and many other characteristics.
You will find that many non-functional requirements apply to the overall system rather than specific parts of it. The non-functional requirement in Table 4-1 shows a requirement that applies to the whole system.
| ID | Requirement |
|---|---|
NFR_SEC_AU_001 |
A change of all authentication credentials used in system-to-system communication MUST take place every 30 days. |
Many non-functional requirements are included in control frameworks, security policies, and practices. You may end up with hundreds of these enterprise-wide, detailed requirements.
However, other non-functional requirements will be specific to the delivery of a capability in your solution architecture. The non-functional requirement in Table 4-2 shows a requirement that applies to a specific component of a system.
| ID | Requirement |
|---|---|
NFR_SEC_FW_001 |
The edge firewall MUST support a peak application transaction rate of 1,000 active connections and 10 MB/sec outbound. |
Let’s now discuss some categories of non-functional requirements (or architectural characteristics) that are important to architectural thinking for secure design:
- Security
-
Security is normally expressed as the requirement to protect data from loss of confidentiality, integrity, and availability. You could say security is more of a family of architectural characteristics. From them, you can derive other requirements. Protection from loss of confidentiality requires identification and authentication to support accountability.
Many of these requirements come from policies, standards, and guidelines for the organization, but external industry standards specific to the application may add additional requirements. For example, an organization may require the use of at least transport layer security (TLS) 1.2, but the external standard requires TLS 1.3, which may then constrain the technology components used in the solution.
Collect the applicable policies, standards, and guidelines together at the start of a project and identify the control requirements that may cause you problems in terms of compliance. Add those to your list of risks or issues for management in your project. We will further discuss managing project risks and issues later in Chapter 10.
- Privacy
-
With privacy enabled, an individual or group can protect themselves or information about themselves to control what information is publicly exposed. The domain of security, which encompasses concepts such as appropriate disclosure of information, somewhat interconnects with privacy.
As discussed in Chapter 3, privacy is important to consider for the protection of sensitive personal information. There may be laws or regulations, such as GDPR, that derived requirements will come from.
- Scalability
-
Scalability is the ability of an information system to increase its compute, storage, and networking capacity. If the system doesn’t scale, it can result in a loss of availability. It’s an important consideration for an architect developing a solution for a security service. If a security service can’t scale to meet the growth of customers, this could result in an outage of the overall system.
For example, the design of a privileged access management system may be for the infrequent retrieval of passwords when booting a server. The frequency greatly increases in a container environment and unless the service scales, it can cause a denial of service, impacting the availability of the service. You need to architect scalability from the start, together with ongoing planning from the security operations team. The inclusion of performance and capacity management becomes an important part of the solution for a privileged access management solution.
- Availability
-
Availability focuses on keeping an information system available. With the move to cloud native applications that require continuous availability of security services, this becomes more important to the design of security services.
In the past, we might have rebooted an encrypted server every few months. The loss of a key management server would not have had an immediate impact and a reschedule of a server reboot could take place. In a container environment rebooted every few minutes or seconds, a key required for container startup becomes critical. There would be an immediate impact from the loss of a key manager.
For this reason, security services often need to have availability characteristics exceeding those of the applications they’re supporting. You may need to consider keeping a security service available even after multiple failures of the infrastructure have occurred. The security operations team may need to move from on-call support with response times of hours to 24×7 support with response times of minutes.
- Recoverability
-
Recoverability is the ability to recover data, services, and operations rapidly after a disruption to a service. We’ve discussed how critical security services become in the discussion on scalability and availability. It follows that recovery of the service is critical, especially due to the change in compute architecture to cloud native container applications.
In the recovery of a data center, security services will often need to be priority for recovery to enable the subsequent recovery of applications. Ensure backups are complete, data is synchronized, and recovery is regularly tested to guarantee you meet the needs of the dependent applications.
There are two key measurements for recovery: recovery point objective (RPO) and recovery time objective (RTO). RPO is the extent of the data loss when a failure occurs with an information system. Ideally, this is none, but when copying the data to a remote site with significant latency, the use of synchronous data replication may not be possible and asynchronous replication will result in data loss. Consider how you handle the data loss.
The RTO represents the time taken to recover from a failure. If the application has to recover within 30 minutes, the dependent security services may only have 10 minutes to recover, leaving 20 minutes for the application to recover. This may require the improvement of the availability characteristics to handle multiple component failures and increase the resilience of the security services.
Locking Your Keys in the Car
In the recovery of security services, you need to consider the recovery sequence. The retrieval of keys may not be possible unless storage has already completed decryption. For example, it could be that the reboot of the firewall can’t take place as it enables communication with the HSM required to decrypt the boot disk of the firewall. If there isn’t a different method to retrieve the keys, we can’t resolve this circular dependency. This is the keys locked in the car scenario, where you can’t open the car because of the keys locked inside. The same consideration needs to take place with secrets management and certificate management.
- Usability
-
Usability is the ease with which a user or operator interacts with an information system. With security, it’s particularly important because if the barrier to usability is too great, users will try to work around the security control placed in their way.
For example, the rules for reuse of a password have increased in sophistication over the years as users find a way to make it easy to remember their passwords. Another example is cumbersome identity verification processes that result in users providing false information to bypass the controls.
When adding security, think about whether it will promote behaviors that add additional vulnerabilities or bypass of controls.
Software Architecture Characteristics
We haven’t tried to list all categories of non-functional requirements. Have a look in Chapter 4 of Fundamentals of Software Architecture for a more extensive discussion of architecture characteristics and the different categories of architecture characteristics (also known as non-functional requirements).
Security is often described as a non-functional requirement, but in reality, security is also specified through functional requirements. A login sequence for an application will require functionality to identify and authenticate the user before accessing the application. An example of a non-functional requirement associated with the functional requirement for the login of a user is in Table 4-3.
| ID | Requirement |
|---|---|
NFR_SEC_IA_001 |
The login sequence MUST take no more than 30 seconds to complete if 70% of the users start a login sequence between 8:30 a.m. and 9:30 a.m. on a business day. |
It can get even more confusing because a security requirement can be both functional and non-functional, depending on the context. The key difference is that a functional requirement is about the primary functionality of the application, whereas non-functional requirements are about how the delivery of the functionality takes place.
For example, the requirement for identification and authentication of a customer is a functional requirement for the user interface of an online store, whereas the requirement for identification and authentication of all internal system-to-system connections is a non-functional requirement. With the first requirement, the system can’t meet the primary system functionality without it, but with the second requirement, the system can meet all functional requirements with unauthenticated system-to-system connections.
Constraints
Many requirements become constraints on the solution architecture. Start with consideration of the external laws, regulations, and standards, as they become mandatory requirements for your solution. You will then consider these constraints through the normal requirements gathering process.
However, there are many other constraints created by the current IT environment and selected software components that may be less obvious and take work to discover. These include the following four important areas:
- Software versions
-
Software version dependencies come from the underlying operating systems and middleware. You may get into a “deadly embrace” where your application software only supports an old unsupported library and an upgrade is impossible because the company that supplied the software no longer exists. This has the impact that the upgrade of all other software that depends on the unsupported library isn’t possible. The security vulnerabilities will then increase over time and you may need to find additional security controls to mitigate the risk.
When you are architecting a system that has predefined software components, make sure the dependencies of all the software components line up in terms of their versions and dependent software components.
- Security protocols
-
Even if supported versions of software components exist, the protocols may not align. For example, the TLS protocol, used for session-level encryption, has received upgrades to address newly identified vulnerabilities. Although your security standards may require TLS 1.3, the software may only support TLS v1.2 and lower. It could become even more difficult if interfacing software depreciates older protocols or ciphers and doesn’t support TLS v1.2, so they can’t integrate.
You will need to perform a check of the integration points to ensure the software protocols align. You may need to record risks for older protocols with vulnerabilities and mitigation put in place to prevent the exploitation of potential vulnerabilities. In this case, you may wrap the TLS in an Internet Protocol Security (IPsec) virtual private network (VPN) or encrypt the payload inside the TLS session.
- API versions
-
With the use of REST APIs in many cloud services there is a need to version control for the development of new capabilities and vulnerability removal. The software integrating with the APIs needs updates to support new APIs as the depreciation of older APIs takes place. You have no choice but to make these changes as the change in versions isn’t under your control.
If your security services rely on cloud APIs to implement security controls, ensure you have thought about the ongoing support for upgrading to new APIs. This consideration for ongoing support exists across all security services and is a significant risk that will need additional work during the development of your solution architecture.
- Agent incompatibility
-
Security requires many different software agents for detecting threats, checking compliance, or performing configuration. Version incompatibilities may mean you can’t install the agents on an older version of the operating system. This is an important consideration during your product selection.
Another challenge is the use of security appliances that can’t support security agents, such as enterprise detection and response (EDR) agents. These security appliances then become a risk as monitoring for threats can’t take place. Often, these appliances are just a version of Linux that would support the agents but the suppliers don’t want to allow it for their support purposes. You may need to apply compensating controls.
As you can see from this discussion, there are many constraints that come out of the current IT environment and the software components selected as a part of the architectural thinking process. These investigations may result in new requirements or updates to the project risks, issues, assumptions, and dependencies that we will discuss managing in Chapter 9.
The next step is to consider how we might ensure the quality of the requirements we document.
Specifying Quality Requirements
We need to ensure that the definition of quality requirements is part of our architectural thinking process. One approach is to use the SMART framework. SMART refers to making requirements specific, measurable, attainable, relevant, and time-bound:1
- Specific
-
Requirements must clearly specify the needs of the business. They must be clear, consistent, simple, unambiguous, and at an appropriate level of detail. A good starting point is to use the Five Ws: ask who, what, when, where, and why. They can help you define the problem more clearly so you can be more specific in your requirement definition.
- Measurable
-
The construction of requirements must be such that it’s possible to verify their implementation. Non-functional requirements often should be quantifiable and enable measurement of progress toward achievement. Ask yourself: Can you create a test for the requirement? Part of verification is through traceability of requirements, including testing, which we will discuss later in this chapter.
- Attainable
-
The requirement should be technically feasible and be possible within the constraints of your solution architecture. Ask subject matter experts on the specific technology solution to review the requirements. Check whether there has been successful delivery of the requirement before. If not, how sure are you that it’s achievable? Perhaps record a risk or assumption in the project RAID log to track any concerns. We will discuss this artifact in Chapter 10.
- Relevant2
-
Requirements must align with the overall business objectives and result in a valuable outcome. These requirements may pertain to the primary functionality or the security and compliance needs essential for conducting business. Be careful not to add security requirements that are outside the needs of the business or don’t match the risk tolerance of the organization.
- Time-bound3
-
The requirement should clearly specify when the capability is to be in place to ensure the alignment of the project team. Should the threat detection system be in place even for the start of the proof of concept, or can it wait until six months after the system has gone into production? The timescales may need a documented rationale through an architectural decision record. We will talk about how to document an architectural decision record in Chapter 9.
We’ve specified specific, measurable, and relevant criteria as a must, as all requirements should meet these criteria. Whereas attainable and time-bound criteria use should, as they can depend on the later definition of the overall dependencies, priorities, and risks of the overall project. Considering the requirements as a whole can enable a better assessment of these criteria.
Let’s have a look at a couple of examples, starting with a poorly specified requirement in Table 4-4.
| ID | Requirement |
|---|---|
REQ_1 |
An alert should immediately be raised with the relevant team for ransomware. |
It’s not specific, as it doesn’t specify who should raise the alert. How quick is immediate? We don’t know who the “relevant team” is. What does “for ransomware” mean? It’s not measurable because it’s not specific enough. We have no idea whether it’s attainable or relevant, as it’s not well specified. Time isn’t included. It fails to meet any of the quality criteria.
We’ve also demonstrated how not to label a requirement. Using the label REQ_1 doesn’t give us an idea of what domain the requirement is from, and using 1 rather than 001 makes it difficult to sort.
Then we’ve created a well-specified requirement in Table 4-5.4
| ID | Requirement |
|---|---|
NFR_SEC_TD_001 |
The threat detection system MUST be in place before the system contains client data to issue an alert to the security operations center (SOC) within 15 minutes on the detection of event patterns that could indicate potential ransomware. |
The requirement tells us the component that raises the alert and who will receive it. It’s more specific in that it’s about the detection of event patterns that could indicate potential ransomware. The patterns will be part of the detailed specification. It’s time-bound by defining when threat detection needs to be in place. It’s measurable, as within 15 minutes of detection, the alert needs raising. The requirement is relevant given its threat, which is a real risk to the organization.
How long it takes to detect the threat is difficult to specify, and defining additional requirements specifying the types of attack detection is an improvement. We can’t tell whether it’s attainable as we don’t have the project context. It’s a vast improvement over the first requirement.
You will notice the requirement has a complex sentence construction. Not every requirement will meet all these criteria, but they provide a quality checklist to see if you have missed documenting different aspects of a solution. The application of criteria may vary across different requirements. For example, the expression of the time-bound criterion may be in a single requirement that then applies to multiple requirements specifying the functionality.
We’ve also labeled the requirement in a better format. NFR stands for Non-Functional Requirement, SEC is for the group of security requirements, TD is for Threat Detection, and 001 is a sortable number.
Now that we have clear requirements, how could we prioritize them?
Prioritizing Requirements
We often end up with a long list of requirements for the solution architecture. While the implementation of some requirements is immediate, for others, the implementation priority can be within a specific time period.
For a minimum viable project (MVP), we must provide a username and password for identification and authentication and could offer multi-factor authentication if there is sufficient time. Another example is, with a small number of consumers of the service, we could decide that we must offer an RTO of 48 hours to start and could offer an RTO of 4 hours if we’ve had sufficient time to implement it.
One commonly used technique for prioritizing requirements is the MoSCoW method, where the capital letters represent:
- Must have
-
The project will implement the requirement. The completion of the project can’t take place without the delivery of the requirements categorized as Must.
- Should have
-
The project will attempt to implement the requirement within the time given but may not have time to do so.
- Could have
-
The project could implement, but won’t necessarily implement, the requirement. More than likely, the implementation of the requirement won’t happen.
- Would or Won’t have5
-
This could mean the project would have the requirement included if there was time, but it’s not critical. An alternative is to sometimes specify a project won’t implement a requirement. Perhaps because the requirement would introduce additional cost or complexity and needs to be explicitly excluded from a solution to ensure it doesn’t get implemented.
Let’s give some examples of prioritized requirements based on two sprints of a project, as shown in Table 4-6.
| Reference | Sprint 1 | Sprint 2 | Requirement |
|---|---|---|---|
REQ_SEC_1 |
MUST |
MUST |
All users MUST be identified and authenticated before given access to the system. |
REQ_SEC_2 |
SHOULD |
MUST |
All users MUST be authenticated using multi-factor authentication. |
REQ_SEC_3 |
COULD |
SHOULD |
All users MUST be presented with a legal warning about unauthorized use of the system. |
The table shows three requirements related to the identification and authentication of a user by a system with phased implementation. There must always be identification and authentication, with multi-factor authentication next and a legal notice coming later.
Now that we have a way of assessing the quality of requirements and a way of prioritizing them, let’s move on to the specification of requirements, starting with functional requirements.
Specifying Functional Requirements
There are many different ways of specifying functional requirements. Writing functional requirements can be as simple as something the system will provide, such as in Table 4-7.
| ID | Requirement |
|---|---|
FR_SEC_IA_001 |
The system will identify and authenticate a user using a username and password. |
However, this doesn’t describe the sequence of activities or the actors engaged in the activities. In this section, we’re going to introduce a selection of different techniques, show the artifact, and discuss their use in the context of specifying functional requirements.
We will discuss the following techniques:
-
Use cases
-
Journey maps
-
User stories
-
Swimlane diagrams
-
Separation of duties matrices
Use cases, a technique developed in the 1980s by Ivar Jacobson, who later codeveloped the Unified Modeling Language (UML), will be our starting point.
Use Cases
A use case is a description of system interactions by human and system actors. We will identify use cases as part of defining the system context diagram in Chapter 5. They need further description through the use of a UML use case diagram and use case descriptions.
We can use a UML use case diagram to visualize the behavior of a system with a box representing the system or subsystem boundary, people representing the human and system actors, and the use cases inside the box. We’ve taken a subset of the actors and use cases from the case study to show a use case diagram in Figure 4-2.
Figure 4-2. Case study UML use case diagram
The diagram shows the involvement of actors in each use case, but we need some more detail about the use case. We can document them either as an informal description or in a prescribed template, such as shown in Table 4-8.
Name of use case: |
Driver registration |
Description: |
Register the driver details and the vehicles they own |
Actors: |
Driver |
Preconditions: |
|
Flow: |
|
Postconditions: |
None |
Exceptions |
In step 1, if the driver has already registered the user interface will say “unable to register” and send an email to the owner telling them of the duplicate registration and guiding them to a reset of the password. |
Requirements: |
|
Each use case describes a set of activities with pre- and post-conditions. For non-technical use cases, business analysts or consultants may define them for architects and developers to implement.
A Use Case Description for System Interaction
We’ve used a textual use case description, but we may also use sequence or collaboration diagrams to better describe the interaction between system actors and the system (or subsystem). We include a discussion of these artifacts in Chapter 6.
There are many security use cases for definition in every system, from the end-user application login to the reporting of a security incident. You must ensure the identification of the security-relevant actors and document their use cases.
Further UML Detail
For a more detailed description of use case diagrams, read Chapter 18 in the Unified Modeling Language User Guide (Addison-Wesley Professional) by Grady Booch, James Rumbaugh, and Ivar Jacobson.
As we discussed, use cases are interactions with a system. It becomes difficult to avoid considering a solution as part of the requirement definition. In Table 4-7, the requirement has already defined the need for a username and password. What about a passwordless system of identification and authentication? It would have been better to require multi-factor authentication as a quality and leave the solution to the architect.
As a result, in the past 20 years, there has been the development of techniques that focus on the end user. We’re going to continue with a technique focused on the needs of a user, the definition of a journey map.
Journey Maps
We discussed design thinking in Chapter 2. The focus is on a human-centered approach to understanding personas (another term for actors) through their needs, pain points, and goals. One technique to better understand personas is to draw up a journey map to define their actions, thoughts, and feelings when engaging with a service or product. It’s a more personal tool to place yourself in the position of a user or customer to understand their thoughts and emotions.
The journey map is normally created in a workshop using stickies on a wall to describe the phases, steps, feelings, and pain points. We’ve shown an example of a journey map in Figure 4-3 for the case study.
Figure 4-3. Case study journey map
A journey map is also called a user journey or scenario map with slight differences between different formats. We used the to-be scenario map format from the IBM Enterprise Design Thinking method.
This technique is good for showing the end-to-end journey and getting into the head of the driver to understand their thoughts and feelings. However, a journey map doesn’t offer enough detail to move into solution development and there is a need for an additional technique to decompose the problem. We’ll now discuss using user stories for the next stage of development.
User Stories
In Agile development, functional requirements are often specified as a user story. It’s a concept that comes from the eXtreme Programming methodology as a way to improve software quality and be more responsive to changing customer requirements. Users express their requirements and values through user stories. The users are those specified as human actors as a part of the system context diagram in Chapter 5 and as personas in design thinking. It provides a mechanism to communicate between the development team and the customer about the specification of the solution.
We develop user stories and put them into a catalog of stories called a product backlog. Based on priority, for each sprint or iteration, we move the user stories into the sprint backlog. The MoSCoW approach to prioritization, discussed earlier, is one way to decide which stories join the sprint backlog.
A user story is normally written in a three-part form:
As a
<role>I want<a feature/function>so that I<business reason/benefit>.
This covers three elements of the five Ws for making a requirement specific: who, what, and why. Typically, you will add background information that provides context to the requirement and tests that determine its completion.
Let’s give an example of a user story for a compliance report, as shown in Table 4-9.
User story |
As a compliance specialist, I want to be able to obtain a compliance report containing trend graphs for different perspectives so that I can identify the stakeholders I need to work with to close compliance gaps. |
Context |
This comes from the compliance team who have been doing this manually with spreadsheets and need it automated. |
Acceptance tests |
|
Not all users want to enter a username and password, and sometimes with security requirements, it’s more appropriate to change the I want to I’m required, and then remove the so that clause. The core principle to remember is that the user story must be for a specific user role. Don’t start a user story with “As a user”; a specific user needs identification.
We refer to larger user stories that may take more than one sprint as an epic. They often need further refinement into many user stories and are a sign that there is a need for further work to decompose the problem. As a result, some tooling defines an epic as a group of user stories rather than a large user story. It’s worth agreeing on what an epic means within the team you are working with.
A theme is a collection of related user stories and epics organized into a group. For instance, a theme named “compliance reporting” could include stories and epics for each individual report.
Developers can easily forget about the users responsible for security and compliance when developing an application. This is why defining these actors (or users) is important in the system context diagram we will discuss in Chapter 5, as it’s a good reminder that the users aren’t just those for the primary business application. The overall information system also has to meet the needs of many other users, such as the “Compliance Team.” In this case, we should consider that one of the primary functions of the application is to meet external regulatory requirements.
Further User Stories Detail
Further detail on applying user stories is in User Stories Applied: For Agile Software Development (Addison-Wesley Professional) by Mike Cohn.
At this point, we have a way of specifying the end-to-end user journey and functional requirements through user stories. We’re missing a way of specifying the different users, how they interact, and describing the separation of duties. We therefore come back to a technique that has existed for much longer: a swimlane diagram.
Swimlane Diagrams
There are many different diagrams that describe a process flow or sequence of activities performed by an actor or user. There are flowcharts and UML activity diagrams that describe the steps in a process, but neither clearly shows roles without adding a table describing the sequence of activities.
Therefore, we use swimlane diagrams to describe the steps in a process, with each “swimlane” being a row or column representing the activities of an actor. The diagram enables you to show who performs what steps, the handover between actors, and decision points. The diagram can also show how to maintain separation of duties. Figure 4-4 shows an example of a swimlane diagram.
Figure 4-4. Swimlane diagram
We’ve used a simple set of diagram parts; you will find more complex diagrams, but you are likely to use these parts most of the time. Let’s discuss the parts:
- Actor
-
These are the actors, personas, or users involved in the execution of the process. There can be both human and system actors as part of a system.
- Swimlane
-
A swimlane is a row or column holding the activities performed by an actor. They look like swimlanes in a swimming pool where swimmers stay within their own lane, which is where the name of the diagram comes from.
- Terminator
- Process step
- Decision
-
A decision occurs when someone makes a choice in the process. It’s normally a two-way decision, like a yes/no or OK/not OK decision, but you could draw the diagram with more than two options. Where there is a policy decision, the writing of an event record to a log will need to take place.
- Subprocess
-
An individual process step may become too complex for a single diagram and a separate subprocess (or swimlane diagram) will describe the step in more detail.
- Step numbers
-
This numbers the steps and is a useful way of referencing the steps in the process. It’s a convention that swimlane diagrams should always go left-to-right or top-to-bottom, as they represent the execution of a process over time.
The swimlane diagram alone often doesn’t provide sufficient description, so we require a text description in a table. Table 4-10 provides a short example with the first two steps from Figure 4-4 filled out.
| Activity | Actor | Title | Description |
|---|---|---|---|
1. |
Request privileged access |
Employee |
The employee starts by opening the web page for the IAM request tool and completes a request for privileged access. The request includes the ID required and a business justification for obtaining that level of access. This must be linked back to an incident, problem, or change ticket. |
2. |
Decision |
Manager |
The manager reviews the request from the employee and checks that there is sufficient justification for the access and that the requested permissions are appropriate to the activities. |
n. |
etc. |
etc. |
etc. |
Note that the table includes the number of the activity, the actor, and the title, with the addition of a description. If you want to use a flowchart or UML activity diagram, this table can record the actors rather than using swimlanes.
For the next stage, we must ensure that an actor doesn’t receive inappropriate rights to perform a process step. We do this with a separation of duties matrix.
Separation of Duties Matrices
In Chapter 3, we discussed separation of duties as an important guiding principle. There are many security-relevant processes where a user must not perform a combination of activities and they need to follow the separation of duties principle.
For example, a user requesting privileged user access shouldn’t be able to approve their access or have the ability to issue their own privileged access. We use a separation of duties matrix to represent what they can and can’t do. Figure 4-5 is an example for the swimlane diagram in Figure 4-4.
Figure 4-5. Separation of duties matrix
The parts of the diagram are:
- Process step
-
These are all the process steps in the swimlane diagram.
- Role
-
This is the number of the role, as shown by the key, that performs a process step.
- ID
-
The ID is the number of the process step used in the swimlane diagram. The ID is both vertical and horizontal on the matrix.
- Risk matrix
-
In the center of the table is a 7 × 7 matrix showing what process steps a role can/cannot perform together. Where a combination of process steps is an elevated risk, an “X” marks a combination of activities that a role must not perform together. Where a “*” shows the combination is low risk, the role should avoid the combination. It’s not a showstopper and the role could perform the combination if there was no other choice. A tick marks a combination of activities that can be performed by the same person.
So how do the functional requirements artifacts work with the case study we’re using?
Case Study: Process Definition
We created a journey map for a driver in Figure 4-3, but this is too high-level and has no detail to provide functional requirements for the system. The first security-relevant activity on the journey map is driver account registration.
We’ve used a swimlane diagram to describe the driver account registration process as shown in Figure 4-6. We’re using a vertical form of the diagram so we can display all the process steps on a portrait page without decomposing into additional swimlane diagrams.
In this example, there is a single human actor and two system actors. We’ve identified two technical components among the two system actors and started the architectural thinking process. We don’t have multiple human actors, so we don’t need a detailed separation of duties analysis.
The identity provider and email provider could be two different cloud services. We may have a requirement that the identity provider make all identity-related decisions and not the email provider. It could be that we’ve gained greater trust in the identity provider and don’t want to spread the business logic for identity-related decisions across multiple services. An architectural decision record should document that only the identity provider will make these decisions. In this case, we can see in the swimlane diagram that the email provider only sends emails andcperforms business-logic decisions.
This is an example of a business process making security-impacting decisions. We don’t have to create a swimlane diagram for every process. We suggest you document any process involved in making a security decision using a swimlane diagram to be clear about the sequence of activities and security decisions. We will show in Chapter 11 further details on process decomposition and how to document the writing of security events into an audit log.
Figure 4-6. Driver account registration swimlane diagram
Now let’s move on to the specification of non-functional requirements.
Specifying Non-Functional Requirements
We talked earlier about how non-functional requirements describe how the information system should deliver functionality. We then talked about some categories of non-functional requirements, how to measure their quality, and how to prioritize them. So where do these requirements come from, and what’s the best way to record them?
Sources of Non-Functional Requirements
In Chapter 3, we talked about the external and internal sources for requirements. External laws, regulations, and industry or expert organization best practices enable an organization to develop its internal policies, standards, and guidelines. From these documents, an architect needs to extract the relevant non-functional requirements. These non-functional requirements are often constraints on your project, as they can reduce the choice of security solution. Figure 4-7 shows how the external, internal, and project contexts inform the solution architecture containing the security controls.
We discussed the external and internal context in Chapter 3. Once there is a project, we now have a project context that gives us additional requirements to work with, including the project objectives and scope. Resources, skills, tools, standards, budget, and timescale all have an influence on the solution we’re considering.
Figure 4-7. External, internal, and project context
The project context brings into consideration the project management triangle with the balancing of cost and time with scope, quality, and risk, as shown in Figure 4-8. However, the diagram shouldn’t only focus on scope and quality but also consider balancing cost and time with qualities such as security, resilience, and availability.
Figure 4-8. Project management triangle
This balance is something you need to consider when specifying requirements, as meeting all requirements may not be viable in terms of cost or time. You may need to look for alternative security controls that are lower-cost and have faster implementation.
Not all requirements are explicit, and so we derive implicit non-functional requirements from other sources, such as the applications or workloads the security services are securing. If an application has an RTO of eight hours, the security services may need to be available in a much shorter time in the event of a widely impacting outage. Or if an application needs to have 80% of the users log in within a short time, the security service supporting the application will need to scale to meet the needs of the application. This will result in a set of non-functional requirements for security related to availability and resilience.
Depending on the delivery of the security capabilities, you may not be in control of the security service functionality and architecture characteristics. They also become a constraint you need to work with.
Non-Functional Requirement Dependencies
You may be in control of the implementation of the security requirements through the project you control or you may have dependencies on security services delivered elsewhere. For security services delivered outside your project, you will need to assess whether those workloads can use the security services to meet the non-functional requirements of the project.
For example, if the application uses a specific technology, does the security service also support it? If not, will the workload need to change, or will you need to fill the gap? A good starting point is to obtain a list of key software components, their software versions, and the platforms they run on. The shared responsibility stack diagram we discuss in Chapter 7 helps with the analysis, as you can use it to think about the different layers of the solution for each platform.
Identifying Software Versions
In on-premises architectural thinking, the checking of software versions may have been later in the process. We’ve found this happens earlier in the process for hybrid cloud, with software versions requiring major changes to the architecture and operations.
For instance, the solution might require a software version or feature that the CSP doesn’t support, resulting in the need to replace a cloud service with software on a virtual server. The cost is then likely to increase and the viability of the project may be in doubt. As a result, the project may decide to use an alternative service.
Even if the solution is already software rather than a service, it could be that you need to change the security software from one vendor to another. The earlier you perform a software version check, the less likely there will be the surprise of a major change in software components at a later stage.
You should work through each of the key software components, examining what security services need integration and assessing their compatibility. Some questions you might ask are:
-
What are the operating systems, and are security tools like antivirus and end-point detection and response (EDR) supported?
-
Does the messaging tool require payload encryption inside the encrypted network session, and is there a security service to support it?
-
Does the database need activity monitoring to detect misuse of the data by an employee or an external threat actor? Is there a supported solution?
There might be even more restrictions for cloud services regarding the services used in workloads, such as databases, and the security services, such as access control, that the cloud service provider is delivering.
Documenting Non-Functional Requirements
We’ve talked about where the non-functional requirements come from and the derivation of requirements from dependent technology. Earlier in this chapter, we also talked about deriving and creating quality requirements using SMART. We now need a list of requirements that we can use to demonstrate compliance with the policies and any other requirements that come from different sources. It would be simple if we could just have a single document with all the requirements listed, but that’s not how it normally works.
We find the best way to approach this is to create a spreadsheet or table of all requirements and initially ignore the quality of the source requirements. Then categorize using the non-functional categories, and for security requirements, use the security domains as discussed in “Technique: Enterprise Security Architecture”. Then insert the original requirement with a reference to the source document, followed by the proposed solution and service owner of the requirement, as shown in Table 4-11.
| NFR | Domain | Category | Prio | Requirement | Ext. Ref. | Solution | Service owner |
|---|---|---|---|---|---|---|---|
SEC |
IAM |
PAM_003 |
MUST |
Rapid retrieval of privileged passwords is needed. |
EXT_REF_nn |
The hosting of the privileged access management (PAM) service will be on infrastructure components that are independent of the core infrastructure and will be available during a DDoS attack via a break glass remote VPN service. |
Security operations manager |
This gives you a format that’s good if you have a single project, but if you are running a program with many projects or an organization with many projects, creating a list of requirements from all the different sources will add up to lots of duplicated effort. In this case, it’s worth improving the quality of the requirements catalog. Let’s review some techniques for improving the requirements.
Improving Requirement Specification
You may end up pulling requirements from different sources, resulting in a variety of different formats and qualities. If you review the control requirements from NIST SP 800-53r5 Security and Privacy Controls for Information Systems and Organizations, the requirements are policy, technology, and sector neutral, which many people would not understand, and there are parameters that need completing.
The requirements pulled together will often benefit from rewriting into a consistent set that people can understand without resulting in inconsistent interpretation. You are then able to use the high-quality requirements many times across projects or contexts.
We’ve developed a useful set of approaches for the derivation of a consistent and high-quality security requirements catalog for repeated use. Iteratively use each technique to derive the necessary requirements and use them in the order that best works for you.
While you are doing this, ensure you maintain a mapping between the new requirement and the original requirement. As you make changes, recheck the mapping back to the original requirement to ensure it still holds. If you reword, split, or merge requirements, they could come out of sync with the original requirements.
Let’s start by sorting the requirements based on domain and then category to group related requirements. Then process the requirements in the following ways:
- Reorder
-
Although you have sorted the requirements into groups of common types of requirements, often they only make sense in a certain sequence. For example, you may have two requirements: the first requiring authentication using multi-factor authentication, and the second requiring identification and authentication before a user accesses a system. These two requirements need swapping so that one can build on the next.
- Split
-
You may find that you can split a requirement into multiple requirements. A requirement with “and” in the sentence is an indication of a requirement that you may need to split. For example, take the following requirement AC-2 a. from NIST SP 800-53r5. The first part is a documentation requirement, and the second part could be a requirement for a technical control enforced by tooling. Splitting the requirement into two requirements enables allocation to different teams for clear accountability, if needed:
AC-2 a. Define and document the types of accounts allowed and specifically prohibited for use within the system.
- Merge
-
Once you have reordered and decomposed, you may find two requirements that are effectively the same requirement. At this point, you may be able to merge them into a common requirement. Look for any subtle phrasing between the two requirements before you merge them and check back against any source requirements.
- Recategorize
-
Sometimes a requirement may be mapped against the wrong category and need remapping. For example, NIST SP 800-53r5 states that many control families require the development of a policy, which is typically written independently of the team responsible for implementing the requirement.6 You are likely to have a team that’s accountable for all policy development. These requirements will need recategorization to a different domain and category for improved alignment with the accountable owner.
- Subcategorize
-
You can end up with a long list of requirements that you have reordered, split, and merged. You may notice requirements come together into common themes. Grouping the requirements into further subcategories can make them easier to manage.
- Dimensions
-
Requirements should be as neutral as possible so that, as the context and technology change, you can apply them to the appropriate scope without changing the requirements. However, there is a need for some context. For example, take the requirement SI-3 a. from NIST SP 800-53r5. It says to implement the code protection mechanism at system entry and exit. You could take this to mean only implementing a control on a server, but the implementation of this control is at many control boundaries:
SI-3 a. Implement [Selection (one or more): signature based; non-signature based] malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code;
In the discussion for the control, it says, “System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices.” This requirement needs these multiple dimensions to be explicitly documented with the requirement. Otherwise, people may misunderstand the expected scope.
As it applies to all requirements related to malicious code, we suggest you keep the dimensions of the requirement in a list independent of the requirement for referencing multiple requirements. As the dimensions change, you only need to update them once.
- Parameterize
-
Requirement SI-3 a. that we used in the previous example has parameters that require filling out for the type of malicious code detection capability. As with the dimensions, we suggest you keep this list external to the requirement so you can apply the same parameters to more than one requirement if needed.
- Non-align
-
The security industry creates lots of new terms for new capabilities and unfortunately, those terms can end up in requirements. For example, the term smart protection7 used by multiple ISVs doesn’t tell us what the requirement is. Is it AI-based brand protection or malware protection technology?
A requirement shouldn’t lock any organization into a single product. You will need to spot these and replace them with a requirement that’s not aligned with branded offerings. You may need to define your own terms and create a glossary to provide a description of the terms in the context of your organization.
Let’s talk through an example to give you an idea of the improvements gained from improving the specification of a requirements catalog for use across projects.
Case Study: Specifying a Requirements Catalog
We discussed the specification of the functional requirements using a process flow and improving the quality of the requirements. In a project where the requirements aren’t reused, justifying a significant effort to improve them is unlikely.
When there is a need to reuse the same set of requirements across multiple projects, improving their quality reduces the time spent discussing the meaning of poor-quality requirements. Furthermore, with requirements scattered across different security documents, it’s difficult, without a single list to work through, to demonstrate compliance. In these cases, a single requirements catalog is valuable.
Identifying Security Requirements
The case study asks us to document the top 10 to 20 requirements for implementation as a part of the MVP. It’s suggested we use the NIST Cybersecurity Framework (CSF) as a starting point for the requirements. As an example, let’s start to build the requirements for vulnerability management from the framework, as shown in Table 4-12.
| Function | Category | Subcategory | Information references |
|---|---|---|---|
PROTECT (PR) |
Information Protection Processes and Procedures (PR.IP): Security policies (that address purpose, scope, roles, responsibilities, management commitment, and coordination among organizational entities), processes, and procedures are maintained and used to manage protection of information systems and assets. |
PR.IP-12: A vulnerability management plan is developed and implemented |
CIS CSC 4, 18, 20 |
DETECT (DE) |
Security Continuous Monitoring (DE.CM): The information system and assets are monitored to identify cybersecurity events and verify the effectiveness of protective measures. |
DE.CM-8: Vulnerability scans are performed |
CIS CSC 4, 20 |
Two subcategories within the NIST CSF, each serving different “functions,” lead to the requirements. Organizations often integrate these requirements into a vulnerability management service. Note there isn’t a one-to-one match between the security services and the NIST CSF functions, demonstrating you can’t use the CSF functions to describe security services.
The subcategories define the “building blocks” of security in the NIST CSF but are insufficient as requirements, leaving many questions unanswered and open to interpretation. They’re good for a high-level checklist but not for the specification of security requirements needed for a demonstration of compliance. For example, they say nothing about the dimensions we discussed previously. They have no parameters specifying the frequency of vulnerability scanning or the time required to remove a vulnerability.
Elaborating Security Requirements
Each of the subcategories has references to NIST SP 800-53r5, Security and Privacy Controls for Information Systems and Organizations. It’s a control catalog that provides a more comprehensive set of control requirements to work with.
In NIST SP 800-53r5, the first requirement for vulnerability monitoring and scanning is RA-5 (a), as shown in Table 4-13.
| ID | Requirement |
|---|---|
RA-5 (a) |
Monitor and scan for vulnerabilities in the system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system are identified and reported; |
While it’s more comprehensive, RA-5 (a) has many control requirements, dimensions, and parameters in the same sentence. Here is the list of what we found:
-
A vulnerability scanning tool to identify vulnerabilities—DE.CM-8 in NIST CSF
-
A vulnerability management process—PR.IP-12 in NIST CSF
-
A parameter for the frequency of scanning according to policy
-
A dimension for scanning “system and hosted applications”
-
A new requirement for notifying the vulnerability management service when new intelligence has identified vulnerabilities or threats to vulnerabilities in the system.8
We can’t leave RA-5 (a) as an integrated, multidimensional requirement to effectively demonstrate compliance and need to rewrite it into separate components.
Rewriting Security Requirements
Integrating multiple requirements, parameters, and dimensions into one control requirement makes it difficult to assign accountability and measure compliance. Decomposing the RA-5 (a) control requirement into discrete requirements, dimensions, and parameters, as shown in Table 4-14, is the best way to rewrite it.
| Topic | ID | Description | Control mapping |
|---|---|---|---|
Control |
VM-01 |
Define and implement threat and vulnerability management processes and procedures. |
NIST SP 800-53 RA-5 (a) |
VM-02 |
Vulnerability scanning MUST be performed at a frequency {VM-P-01,02,03,04} for the system component types {VM-D-01}. |
NIST SP 800-53 RA-5 (a) |
|
TIM-01 |
Notify the Vulnerability Management service of a potential system component vulnerability MUST be performed within {TIM-P-01}. |
NIST SP 800-53 RA-5 (a) |
|
Control |
VM-D-01 |
Networking components, servers (physical and virtual), containers, cloud platform, container platform, application |
NIST SP 800-53 RA-5 (a) |
Control |
VM-P-01 |
no less than weekly |
NIST SP 800-53 RA-5 (a) |
VM-P-02 |
after a significant system component change |
NIST SP800-53 RA-5 (a) |
|
VM-P-03 |
within 24 hours after notification of potential system component vulnerability |
NIST SP 800-53 RA-5 (a) |
|
VM-P-04 |
during penetration testing |
NIST SP800-53 CA-8 |
|
TIM-P-01 |
within 24 hours |
NIST SP 800-53 RA-5 (a) |
|
Key |
VM = Vulnerability Management |
||
We began by creating requirement VM-01 for processes and procedures, which is a fundamental requirement necessary for all services and requested in the RA-5 (a) assignment. Then RA-5 (a) requires a control requirement, VM-02, for vulnerability scanning and then a derived requirement, TIM-01, for the threat intelligence monitoring service to notify them of potential vulnerabilities. The TIM-01 control requirement, which isn’t explicitly mentioned in any vulnerability management or threat intelligence requirements, critically determines the successful delivery of the VM-01 control requirement.
The dimensions or scope of the service are missing. RA-5 (a) talks about a “system and hosted applications,” but that’s incomplete and depends on the technology components used in the environment. When we read RA-5 (a), we might think we just need to perform a vulnerability scan of servers and applications, but this doesn’t include the network, cloud platform, containers, and container platform vulnerabilities. Adding the dimension VM-D-01 improved the scope of vulnerability scanning.
Control Family/Domain Misalignment
You may have noticed the control families and domains in NIST CSF and SP 800-53 don’t fully align with the resulting security requirements, dimensions, and parameters. We derived a new requirement for Threat Intelligence Monitoring and discovered a new requirement for Vulnerability Management related to penetration testing. The result is that you can’t assign accountability for security processes and service delivery by simply allocating ownership of control families or domains to these frameworks.
The parameters for the service are missing. It doesn’t define how often the scans need to run or how quickly the owners of the vulnerabilities need notification. What’s the length of time for storing the vulnerability records? Many of these parameters could come from a policy, but if they aren’t specified there, it’s not clear when we’ve met the requirements. Adding the parameters VM-P-01, VM-P-02, VM-P-03, and TIM-P-01 has improved the understanding of the requirements.
We added a parameter VM-P-04 because we found the requirement CA-8 requires the ability to perform vulnerability scanning for penetration testing. This requirement needs documenting because it may change the number of supported human actors and require an increase in the capacity of the security service.
Up until now, we’ve discussed establishing a requirements catalog for a workload or application. But how can we use this catalog to make sure the implementation and operation of the security are in accordance with the requirements? We’ll talk about that in the following section.
Requirements Traceability
Once we’ve documented the requirements and identified the solution, we need to ensure the documentation of the solution at both a logical and prescribed level, the completion of testing, and the availability of operational documentation. We do this by creating a mapping from the requirements to the specific documentation, as shown in Table 4-15.
ID |
Requirement |
HLDa |
LLDb |
Test plan |
Documentation |
SEC_IAM_PAM_003 |
The system response time at all stages of retrieval for a privileged credential MUST take less than 5 seconds to load a page even if the core systems infrastructure is under extreme load. |
4.2 Privileged Access Management (PAM) |
11.3 Privileged Access Management (PAM) |
6.5 Unit Test |
Ops Manual—5.6 Emergency Break Glass VPN Process |
a High-level design b Low-level design | |||||
The table has a column for each stage of the documentation for the solution architecture, including testing and operations. Your table may contain further columns for your project but these are the minimum we would expect.
We can then be more confident about the documented solution architecture and the implementation and operation of the capabilities to maintain security. We will talk more about the development of the design and operational artifacts in the design documentation within Chapters 6 and 8, the required testing in Chapter 10, and the operations documentation in Chapter 11.
Indexing Requirement References
We’ve given each requirement a unique identity code to use as a reference. A useful approach to validating the inclusion of all requirements in a design document is to include the ID within a sentence, such as [SEC_IAM_PAM_003], and then mark it as an entry for an index. You can then find where the design specification documented a requirement and ensure coverage of all requirements by reviewing the index for completeness.
Summary
Some authors have expressed the view that documenting requirements are no longer needed in an Agile working environment. I hope we’ve demonstrated the value of spending effort documenting both functional and non-functional processes. You can scale the level of documentation to meet the size of the organization and project. We’ve indicated how to do it for the largest of organizations and highlighted some ways to scale down the work for smaller projects.
Security requirements aren’t just non-functional requirements but where they form the primary function of the system, they become functional requirements.
Functional requirements often follow an iterative process that can start with a journey map to identify user stories that may contain control decisions. User stories provide the next level of decomposition in an Agile environment, but for some processes, they’re insufficient, and that’s where the swimlane diagrams and separation of duties matrix help.
Non-functional requirements need a clear definition, and we talked about the various approaches to improving quality and prioritizing. We demonstrated the challenges when integrating control frameworks and project requirements through a set of improvements to the definition of requirements for the case study.
We’ve come to the end of discussing the documentation of requirements and constraints but not the end of using the requirements to define the security for a solution architecture. This should set you up for the following chapters, where we start with defining the boundaries of the system, the actors that interact with the system, and the data that requires protection.
Exercises
-
A functional requirement ______. Select all that apply.
-
Describes the primary functionality of the solution
-
Defines how the system should be delivered
-
Defines what the system should deliver
-
Doesn’t define any security requirements
-
-
What terms are used for requirements that describe how the information system should deliver the required functionality? Select all that apply.
-
Non-functional requirements
-
Architectural characteristics
-
Non-functional characteristics
-
Product quality properties
-
-
Which of the following is true about requirements for security services?
-
Applications should be recovered before security services during disaster recovery.
-
Moving from client-server to container workloads doesn’t require a change in security services.
-
In moving to the cloud, there is no need to adjust the way security operations are delivered.
-
The loss of availability of security services can have an almost immediate impact on workload availability.
-
-
What does “locking your keys in the car” refer to? Select all that apply.
-
Your keys can get locked in your car accidentally if they are not detected by key proximity inside the car.
-
The retrieval of keys may not be possible unless storage has already completed decryption.
-
Encryption keys accidentally get locked inside a physical safe.
-
The reboot of the firewall can’t take place, as it enables communication with the hardware security module (HSM) required to decrypt the boot disk of the firewall.
-
-
What are the suggested qualities to look for in security requirements?
-
Who, What, When, Where, and Why
-
Must Have, Should Have, Could Have, and Won’t Have
-
Specific, Measurable, Attainable, Relevant, and Time-bound
-
Traceable, Testable, and Timely
-
-
What is the best functional requirements definition technique for identifying end-user functional requirements? Select all that apply.
-
Use cases
-
A journey map
-
Swimlane diagrams
-
User stories
-
-
What is the best functional requirements definition technique for the formal definition of the sequence of security-enforcing activities taking place between different end users?
-
Use cases
-
Journey map
-
Swimlane diagrams
-
User stories
-
-
What factors does the project management triangle need to take into consideration when balancing scope, cost, and time? Select all that apply.
-
Skills
-
Quality
-
Viability
-
Risk
-
-
What are the primary reasons you perform a software version check early in the requirements process for hybrid cloud? Select all that apply.
-
Version incompatibility may require a major architectural change.
-
A cloud service may not support the prerequisite software version.
-
The security information and event management (SIEM) solution may not have been tested to process that specific software version.
-
The security product doesn’t support any version of the operating system being used.
-
-
In the process of improving requirement specifications, what steps are used to consider the scope of requirements?
-
Split
-
Dimensions
-
Merge
-
Parameterize
-
1 There are many different definitions of what SMART stands for. We’ve chosen this definition because we believe it delivers the best quality security and compliance requirements.
2 Sometimes the R in SMART is defined as reasonable. The criterion is to validate that the requirement has the appropriate resources to deliver the solution. We don’t use that, as reasonable timescales are included in the time-bound criterion and then the overall requirement is tested for reasonableness as a part of prioritizing requirements.
3 Sometimes the T in SMART is traceable. Traceability of requirements through requirements specification, solution architecture, implementation, and testing is more related to ensuring the quality of requirements implementation than the quality of the written requirement itself. We will talk about the traceability of requirements later in this chapter.
4 We’re sure you could improve the requirement, given more context and time.
5 The authors prefer the use of won’t, as any requirements that are not implemented based on lower priority are likely to be categorized as Could have. Sometimes you may need to specify that a requirement won’t be implemented because you know someone who wants the requirement outside of the immediate project and you want to make it clear that the requirement must not be implemented.
6 This is one example of why using accountability based on a control family within a control framework isn’t effective. There are many other examples, but this is the most obvious example to use.
7 This has nothing to do with using the SMART approach to improving the quality of requirements.
8 This could be a new software vulnerability reported in the CVE database or a threat intelligence about the exploit of a vulnerability. Ideally, you should add a requirement for the automatic patching of a software product.
Get Security Architecture for Hybrid Cloud now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
