Practical Application of System Security Engineering to SDLC Security, Part 1

Part 1

Past approaches to creating and managing secure systems are not working. Daily reports of breaches and daily reports describing critical system vulnerabilities are strong indicators of this. A different approach is needed.

System security engineering (SSE) applies engineering principles to building system security models. The models are used throughout the systems’ life cycles to ensure changes retain expected risk expectations for both waterfall and DevOps system management techniques.

In this three-part series, I provide an overview of SSE and its three contexts. I also explain how to use assurance cases to demonstrate system trustworthiness. Finally, I describe the technical, operational, and management processes needed to continue reaching security objectives over the lifetime of a system.

The content of these articles is primarily based on NIST Special Publication SP 800-160v1Opens a new window that is based on ISO/IEC/IEEE 15288:2015Opens a new window . I take these documents out of their academic approaches into the realm of a practical application using my experience managing development, infrastructure engineering, and IT security teams.

Traditional System Development Life Cycle (SDLC) Security

Integration of security into the system life cycle has been a simple insertion of security processes into existing life cycle phases (Radack, 2009).

1. Initiation Phase. Perform preliminary risk assessment and create system security requirements. Define security roles.
2. Development/Acquisition Phase. Perform risk assessment and use the results to update the security requirements defined in Phase 1. Define standards and guidelines that lead to the selection of reasonable and appropriate controls that achieve security requirements. Integrate testing of security objectives into all testing processes.
3. Implementation Phase. Implement and test security controls and procedures.
4. Operations/Maintenance Phase. Use configuration and change management to ensure changes to the system continue to achieve predefined security objectives.
5. Disposal Phase. Individuals in roles defined in Phase 1 plan for the safe discarding of information, hardware, and software.

This approach improved our ability to harden systems, but it was a simple insertion of basic security processes into existing patterns of life cycle management. What is needed is a set of processes that creates system security models, based on and managed by engineering principles, that encapsulate all system life cycle activities. Further, we need an approach that works equally well for both waterfall and DevOps models.

System Security Engineering

“The primary objective of System Security Engineering (SSE) is to minimize or contain… vulnerabilities to known or postulated security threats and to ensure that developed systems protect against these threats” (SEBoK, 2019, Overview).

In SSE, the system is the foundational entity. A system is the complete collection of people, technology, and procedures needed to achieve objectives associated with one or more business processes successfully. Included are servers, network devices, end-user devices, and manual procedures. These are known as system elements.

SSE uses engineering principles to create and manage a holistic system security model against which we measure all system changes and use cases. It focuses on what can happen instead of what is likely to happen, and it also involves implementing reasonable and appropriate controls based on both risk and uncertainty. This model is the basis for the execution of all SSE processes throughout a system’s life cycle. Associated processes provide a more focused and broader approach than merely inserting security into traditional models.

At a high level, SSE helps us understand what targetable assets exist in our organization and the risk and uncertainty associated with what is both known and unknown.

Vulnerability Uncertainty

We manage system security while facing various levels of uncertainty: uncertainty about whether or not we truly understand our attack surfaces. Two types of vulnerabilities contribute to uncertainty.

The first type includes unknown system element vulnerabilities. The complexity of today’s systems ensures vulnerabilities exist that no one has discovered yet or that are held in secret by one or more malicious entities. These vulnerabilities can exist in a single system or somewhere within a matrix of systems; very few systems exist in isolation.

The second type includes vulnerabilities created by malicious actors (MAs). A good example is the software supply chain attackOpens a new window . MAs insert backdoors and other malware into software updates or firmware distributed with hardware on its way to target businesses or industries.

Managing Uncertainty

Uncertainty in risk management exists mainly in the probability of occurrence: the likelihood that a threat will exploit one or more vulnerabilities to compromise a system. Uncertainty exists in all risk assessments. Complete uncertainty exists when we have no information regarding the means, opportunities, and motives of potential threats against unknown vulnerabilities. As we use SSE processes, we can reduce uncertainty.

Planning for worst-case scenarios is an excellent way to manage uncertainty. With proper planning, worst case scenario management enables an organization to prevent, detect, and respond to most or all related lesser incidents.

We can strengthen worst-case planning by tracing all possible attack paths and using what-if-this-happens brainstorming for each system element. As we explore these lesser scenarios, we look at how well the worst-case planning manages them. If gaps exist, we make necessary adjustments.

SSE Contexts

The basic framework of SSE consists of three contexts: Problem, Solution, and Trustworthiness. All processes we discuss in this series fall into or support each of these contexts.

Problem Context (Defining the Problem)

The outcome of the problem context is a complete business problem definition. When implementing and managing a trustworthy system, the definition must include

• The classification of the data involved
• The criticality of the system
• Management’s appetite for risk, including the required balance between operational efficiency and security
• Cost considerations
• Scheduling
• Other constraints…

These characteristics of the system and its function form the security design problem: how to ensure reasonable and appropriate trustworthiness of the system when used efficiently to enable business processes.

Define Security Objectives

The security objectives are derived from and enable business functional objectives. Security objectives are affected by business and environmental constraints (Biswas, n.d.). They are defined in policies and represent management’s expectations of information resource assurance. Policies and their objectives define what we want to achieve, not how.

Security objectives are what must always happen, usually across all systems handling data of specific classification levels or enabling certain critical business processes. Standards of security best practice (ISO 27002, NIST Cybersecurity Framework, COBIT 5) are valuable resources for identifying objectives we should consider.

We cannot manage and control what we cannot measure. When we define objectives, they must be measurable. Measurable objectives have five characteristics represented by the acronym SMART: Specific, Measurable, Attainable, Relevant, Time-framed.

• An objective is a clearly defined, SPECIFIC outcome
• An objective includes one or more indicators that we can MEASURE
• An objective must be something we can accomplish, must be ATTAINABLE
• An objective must be something that moves us toward an overall objective, like system security; it must be RELEVANT
• An objective must be something achievable within a specific TIMEFRAME

In this example, I defined objectives in terms of what we do not want to happen. Business and infrastructure constraints are built into the objectives. For example, it is not reasonable and appropriate to expect no authorization configuration mistakes. Consequently, our objective allows 2 mistakes per quarter, as measured by audits or data owner access reviews. The timeframes should also represent how often we measure objective outcomes.

Define Security Requirements

Security requirements take the objectives a step further by defining mandatory system design elements:

Objective: prevent unauthorized human and device access to system data resources

• Requirement: implement strong authentication
• Requirement: data owners must review user access based on business role at least semi-annually
• Requirement: encrypt data in transit
• Requirement: segment database servers into network segments accessible only by application servers

Objective: allow access to system resources and use based on business role, the device used, location of the user, time of day, and what is being accessed

• Requirement: define business roles associated with the system that do not allow one person to perform all tasks associated with a business process; configure authorization based on these roles and the data owner’s stipulated role requirements.
• Requirement: implement authentication and authorization processes that provide access based on specific session characteristics

Define Success Measures

Again, we measure success against our security objectives, as shown in Table 1. In a future article, I examine processes we use to measure success.

Define SDLC Security Concepts

Security concepts include protection needs, security relevance, security architecture, trustworthiness, and assurance applied to SDLC concepts (Ross, McEvilley, & Oren, 2016), such as

• Development
• Prototyping
• Analysis of alternatives
• Training
• Logistics
• Maintenance
• Continuity
• Disposal

Security concepts are broadly applied to SDLC concepts, including

• Logical attack surfaces
• Requests for proposal
• Statements of work
• Development and test environments
• Operating environments and supporting infrastructure
• Supply chain
• Logistics
• Maintenance
• Training
• Clearances and background checks

In other words, we must include every system element (people, process, or technology) when we apply security objectives and requirements.

Provide evidence for the security aspects of the problem In this final problem definition step, we validate that we have considered all system elements, potential attack paths, and management of the level of uncertainty. We also demonstrate that the security objectives enable the business reasonably and appropriately; our requirements do not provide unreasonable constraints on system function.

Finally, we must show our requirements sufficiently address all objectives. One way to do this is with a table similar to Table 2 as part of a document describing why the objectives are necessary, reasonable and appropriate, and how the requirements apply a layered approach to achieve them.

Also, we need ways to determine whether or not the security requirements are met in the Solution Context. Creating initial high-level system use casesOpens a new window showing security constraints helps with this effort. Together with documented business objectives and security requirements, it is one of the deliverables we pass on to Defining the Security Aspects of the Solution.

Solution Context (Defining and creating the solution)

In the solution context, the project team uses the Program Context deliverables to design a system that meets the security requirements: whether developed in house or purchased from a vendor. If from a vendor, the request for proposal contains relevant information from the Program Context deliverables sufficient to meet security expectations.

Define Security Aspects of the Solution

In this activity, the project team selects the specific layered controls needed to meet security requirements. Requirements do not always easily translate to controls. Consequently, we often need clarification or adjustments to requirements during design. This requires a process that allows returning to problem definition for clarification or adjustment.

Realize the Security Aspects of the Solution

Implementation of the system with proposed controls realizes the security aspects. The first place this is done is in the test environment. Use cases started in the Problem context and finalized in the Solution context provide testing to show that the system successfully meets security requirements. Use cases must include activities by both humans and technology. For example, controlling access to a resource requires attention to both human business roles and to applications that need access during day-to-day activities.

The realization activity verifies that the design meets security expectations via analysis, demonstration, inspection, and testing (Ross, McEvilley, & Oren, 2016). Verification activities often result in returning to controls design or problem definition because it is probable that security objectives might not be met.

Produce Evidence for Security Aspects of the Solution

The project team provides detailed results of verification activities for review by the change managementOpens a new window team. Sign off for the system depends on whether or not the team members believe assurance is strong enough to ensure reaching security objectives.

Another tool to verify a layered approach to meeting security objectives is the controls matrix. A controls matrix shows security objectives and the controls that achieve them. Figure 3 shows a sample controls matrix that can be modified to include security objectives associated with the security requirements. You can download this template from adventuresinsecurity.comOpens a new window . The article, Use a security controls matrix to justify controls and reduce costsOpens a new window , explains how to use it.

A single control can often perform multiple tasks that meet more than one security requirement. The controls matrix allows the SSE team to understand how they can configure current and new controls to meet requirements and achieve security objectives.

Conclusion

SSE uses an engineering approach to system security. The first context provides a business problem definition that provides reasonable and appropriate security objectives and requirements. Failure to correctly define the problem results in a system that is not secure or that is not an efficient solution for the business.

In the Solution Context, designers use the problem definition to design a secure system and test it. Deliverables include use case testing results for both humans and technology. Further, the project team creates deliverables, clearly showing how the security objectives and requirements are met using existing and new control configurations.

In the next article, I step through creating assurance cases for the Trustworthy Context.

Works Cited

Biswas, P. (n.d.). Establishing Information Security Objectives. Retrieved June 2019, from APB Consultant: http://isoconsultantpune.com/establishing-information-security-objectives/
Martin, L. (2008, March 11). Information security is not risk management. Retrieved June 2019, from The Chartered Institute for IT: https://www.bcs.org/content-hub/information-security-is-not-risk-management/
Ross, R., McEvilley, M., & Oren, J. C. (2016, November). Systems Security Engineering, SP 800-160v1. Retrieved June 2019, from National Institute of Standards and Technology: https://csrc.nist.gov/publications/detail/sp/800-160/vol-1/final
SEBoK. (2019, June 6). Security Engineering. Retrieved 2019, from SEBoK Guide to the Systems Engineering Body of Knowledge: https://www.sebokwiki.org/wiki/Security_Engineering