Chapter 7 - Secure Software Systems

System Requirements

• Functional Requirements
• Nonfunctional Requirements
• Security Requirements

Secure functional requirements

A functional requirement must be thought of in terms of security. The secure functional requirements are added to a functional requirement to ensure it is implemented securely. It does not fundamentally change the requirements are designed, only how they are implemented.

Functional security requirements

Functional security requirements require a new feature to be added in order to increase the overall security of a system or a subset of its features. This may include account security, encryption suites, or creating security groups and access policies. They key identifier being that users will interact with these features directly as part of the program.

Nonfunctional requirements

May be related to how a functional requirement is implemented, developed, or deployed. May also include other security requirements like logging or audit trails.

Sources of Requirements

Direct

• System definition
• Scope
• Intent

Mission statement

We can reference the organization's mission statement when developing requirements. For example, if they have a strong hybrid/remote work style, they may favor cloud features or VPN compatible security.

Compliance/regulation based

• Laws
• Policies
• Standards

Industry Standards

It may be beneficial to look at other organizations in the same industry for ideas on requirements. However, most requirements fit globally and the industry specifics usually only account for around 10% of requirements.

Interaction

We also need to look toward integrations with other systems. Many requirements will come from the systems which our system interacts with. You must consider security, protocols, and format requirements needed to interact with those systems.

Stakeholders

Stakeholders are people concerned with ensuring the system is completed correctly. Primary stakeholders will be users and administrators. Secondary stakeholders are people who may not interact with it directly but may utilize external systems that integrate with the system or be recipients of its functionality.

Interest

Interest of stakeholders may vary greatly and be influenced by different factors. Some primary stakeholders will be directly affected by the project and will have high interest that may vary greatly. Secondary stakeholders may be motivated purely by intrigue and have less interest but may require very little to hold their interest.

Influence

Influence defines the ability a stakeholder has to affect the project. Some key factors are control over resources or control over management decisions. Others may have the ability to swing opinions which can result in high influence. One outlier is help desk technicians who have very little direct interest or influence. However, their attitude towards supporting the product can change the overall view of the system within an organization.

Summary

This figure from the book, along with its description shows a great summary of how interest and influence relate. The book describes the upper left as being a bad resource for requirements. Since their influence is high, it is important to focus on getting their support from methods that are a low barrier and keeps their influence positively directed. We can accomplish this through frequent updates and key feature reviews. The lower right are invaluable for ideas. The high interest will provide many insightful ideas that can develop requirements for the project. Since their influence is low, they will be more willing to adapt and change their ideas. The bottom left are the least useful but can still benefit from being informed.

Requirements Solicitation

We can either solicit requirement ideas from stakeholder using individual or group methods. Individual methods can go more in depth but take more time. Another downside is the lack of collaboration and ability to compound one idea with multiple stakeholders. Surveys are a good way to solicit responses from members in the upper-left quadrant since it doesn't take up too much of their time.

Observation

It can also be a good idea to take time to understand the current processes. By sitting and observing the daily use of current solutions, developers can gather requirements that will improve speed and efficiency of daily use. It also give users the opportunity to show the pain points and inefficiencies of the current product.

Groups

Focus Groups

By splitting people into focus groups, you can have them discuss specific portions of a product. It can help to bring similar stakeholders into the same groups to provide the most feedback and ensure features are fully though about before being written as requirements.

Brainstorming

Brainstorming is another group strategy that involves putting ideas on the table and waiting until all ideas have been presented before ranking them as possible requirements.

Joint Application Design (JAD)

A JAD session is one way to solicit and refine requirements. A JAD session takes a broad range of stakeholders and walks them through a highly structured process to refine requirements. The end goal is to come to a consensus on the requirements for the project. They are often late in the requirements gathering stage so that the groundwork of requirements already exists to be discussed.

Working with Stakeholders

Ambiguity

A common issue when working with stakeholders is inconsistent terminologies. It is important to discuss deeply and determine exactly what a stakeholder means when they bring up a requirement. If they mention an overarching idea, you should narrow down exactly how it is applicable. If they mention something like "cloud" you must determine if they mean a true cloud provider like AWS or just something they don't have to run directly on their machine.

Limitations by the known

Shareholders who have experience to a single older system may have no idea what is possible. This may lead to narrow minded requirements limited by their ideas of what is possible. Ideally, you would expand the requirements to get the general idea of what is needed then narrow it down to what is achievable when refining the requirement.

Requirements vs Design

It is also important to determine the requirements of what needs to be done instead of focusing on how it will be done. It is important to separate the design as one possible way to implement the requirement while acknowledging what the requirement entails. You should evaluate multiple designs before picking one. While stakeholders may have preferences on designs, these should be discussed after the requirements have been visited. There should be no expectations that design aspects will be implemented. However, it may be more acceptable if a systems architect requests design style or corporate rules mandate a certain design.

Security Requirements

A good first step for finding security requirements is analyzing intended security practices. Current security practices that are proven to be effective will be maintained or slated for improvement/discussion.

Privilege planning

The next step in security planning is determining the complexity of Separation of duties and privilege levels required in the system. Most organizations already have policies in place for authentication and authorization. Most systems should be able to reuse these policies and integrate with existing systems.

Logging

Logs are an important security requirement. They also provide useful information for debugging and development. Most systems will require logs to track privilege changes, significant transactions, financial transactions, and key communications. Logs should be stored securely and with controlled access. Logs can also be logged remotely.

Outsourcing requirements

Development outsourcing or cloud hosting provides new requirements. This will require security requirements regarding the responsibility boundaries. Security responsibility boundaries are where responsibility for providing, monitoring, and managing security transitions from one organization or organizational component to another (p 126). Security and service-level agreements (SLA) must be analyzed to identify new security requirements that may be need to be considered with the arrangement. Independent auditing may need to be considered in order to verify security with outsourcing and cloud services.

Requirements Engineering

[Requirements Engineering] involves categorizing, clarifying, deconflicting, and analyzing each requirement (p 127).

Categorization

Requirements must be taken and sorted according to categories such as functional and nonfunctional. They can also be categorized by criteria like their area--user interface, security, data, etc.

Clarification

We must revisit each requirement and ensure they are precisely understood. Care must be taken to resolve any ambiguity or possibility of misinterpretation. The requirement source may also need to be consulted to provide clarifications. Subject-matter experts may also be consulted to ensure a full understanding of the requirement is achieved.

Deconflicting

Requirements come from multiple sources will inevitably conflict. If both requirements are mutually exclusive, it may be necessary to revisit the sources and explain the situation. At this point, conflicting requirements will inevitably result in compromises. If an agreement still cannot be made, it may be required to have a higher authority mediate the conflict. If a requirement cannot justify resources and expenditures to discuss, it should be moved to a "desired" state.

Security Assessments

Requirements must also be assessed for security. Often a person who specializes in security will be consulted. This person should also be knowledgeable in the development and deployment processes in place as well.

Risk assessment

The requirements should be analyzed from a risk management perspective. Analysis should determine how the requirement could fail and what happens if it does. It must also be analyzed for what damage may occur from misuses of the a feature from the requirement. If a requirement has a failure risk, impact must be assessed. Risk assessments should also pinpoint where sensitive info will lie in the program and ensure it is properly protected. After a risk assessment is completed, the requirement may be reconsidered and modifications may be requested to mitigate risks or failure points.

Requirements Documentation

Wherever requirements are tracked and documented, they should contain many variables and links. You should be able to track ideas like categories, tags, priorities, etc. Using a relational database (like Jira) would also allow you to link related or prerequisite requirements.

Traceability

Requirements should be traced from beginning to end to ensure they are verified, validated, and deployed. See the below figure for examples of the process stages of a requirement. The first step should determining the requirement's origin. Be it regulation or sponsor set. Tracing this also helps when returning back to sources during deconfliction. This helps us easily revisit the originator and ensure we met their requirement successfully.

Tracking

We should be tracking when things change during development or requirements engineering. We should be tracking what has been altered, merged, dropped, or moved. The requirements tracking will be essential for designers, developers, and other team members to understand what needs to be done for each component and step of development.

System Definition and Scope

Key functions

Define what is essential to the system functioning. May grow as more requirements are formed.

System boundaries

Determines what and where changes will be made. Focuses on the key functions and determines where extended functions of the system ends. Attempts to define changes like hardware vs software as being inside or outside of the scope of the system.

Scope

Determines where development effort will be focused and where changes can and cannot be made. Efforts that will be allowed in development are said to be in-scope and those functions which development will ignore are said to be out-of-scope