ISO/IEC has defined a standardized risk management framework for infor- mation security in ISO/IEC Standard 27005:2018 (2018). The ISO standard differs somewhat from e.g. the Touchpoints risk model, or even the SSE- CMM model, in both terminology and the level of details. In an adaptation of the risk management process for government work by Patiño et al. (2018), the risk management process is performed in four distinct stages. After the risk management context has been established, the process progresses bottom-up: each component subject to the process is evaluated individually, and the combined risk is then evaluated.
Process stage 1, Context establishment, contains three activities:
• Scope establishment. Define the environment and critical services.
• Selection of critical processes. Includes involving the people and man- aging the required resources.
• Description of Evaluation Criteria. Qualitative risk estimation.
An example result of this phase could be a risk matrix, used as a template into which each critical process is placed. The matrix has two dimensions: Frequency and Impact. The total risk is the product of these two. The frequency varies from highly improbable (1) to highly probable (5), and the impact from very low (1) to very high (5).
Stage 2, Risk identification, contains five activities:
• Identification of assets – in software development, an architectural description or security-related use case list can be utilized.
• Appraisal of critical assets. Estimate the impact of each asset included in the process. Calculate the average to gain an overall asset impact value for the process.
• Identification of threats. This activity is based on security expertise and knowledge of the threats.
• Identification of controls. Create a checklist of controls to mitigate the threats, update the list as necessary.
• Identification of vulnerabilities. These may vary from natural to social and technical and must be monitored.
The work products of this stage are a list of critical assets, a list of threats, a list of controls and a list of vulnerabilities. When the impact of the risk to assets is appraised, Patiño et al. (2018) suggest that processes with an average above 3.00 are considered critical. In this stage, the significance of security awareness is heightened. Identification of threats, controls, and vulnerabilities are highly context-specific and require an adequate level of security expertise.
Stage 3, Risk Estimation, consists of two activities; these are performed for each item on the lists created at stage 2.
• Valuation of probability. A numeric value from 1 to 5.
• Valuation of impact. A numeric value from 1 to 5.
Assigning the numeric values requires expertise on both the business do- main, and the security vulnerabilities and their impact. The standard does not give any advice as to how to perform this critical phase: It is important to know that all the related risk components are correctly identified and that the appraisal of the risk and its impact is accurate. To make things worse, the environment and thus the probability and impact of the risk may be in a constant state of change. To manage the ongoing risk assessment process, an owner should be designated for each risk. The owner may not be responsible for the mitigation or even remediation of the risk but can be held explicitly accountable for the management of their particular risk items. Risk can be expressed the direct product of the probability and im- pact: (Risk = P robability × Impact), properly adjusted to the asset value. Security controls are implemented to reduce this value.
An example risk analyzing technique, called after its mnemonic DREAD, combines this stage with the next one, Risk Evaluation. The mnemonic comes from Damage potential, Reproducibility, E xploitability, Affected users, and the exploit’s Discoverability. This model adds further dimensions to the risk estimation process, and makes the impact assessment more thorough by taking e.g. the amount of affected users into consideration. DREAD has been integrated also to tools, as described e.g. by Ingalsbe et al. (2008); as Chapple et al. (2018) notes, these inspection points should be accompanied by risk estimation aspects customized to the current context.
Stage 4, Risk Evaluation, concludes the risk process and consists of three activities.
• Risk valuation. Calculate the product of each impact and frequency. To be repeated once in e.g. 6 months.
• Identification of critical risks. Focus on mitigation of risks that are ranked high or very high.
• Selection of control measures. Treatment options are: mitigate, ac- cept, avoid and transfer to a third party.
This stage sets the requirements for the practical security engineering work. In a software development company, the risks that are to be mitigated or avoided require policies and guidelines. These policies and guidelines form a major part of the organizational normative framework. Through applica- tion normative frameworks derived from them, they get incorporated into the software development processes, environments. They are also imple- mented into the software products. The risk management framework pays specific attention to an organization’s internal threats. Internal threats, also known as malicious insiders, were also a major concern of the early security standards: the military did not trust their civilian contractors.
To avoid excess security overhead the security risk process should be a part of organizations generic software risk process, such as one described by Boehm (1991). The process described by Boehm is not specific to soft- ware security, but security items can be easily added to the to it. This process consists of six steps: (1) Risk-identification checklists, with a top 10 risk sources (more, when security is included) and a quantification model for this; (2) Risk analysis and (3) risk prioritization are to be adjusted to the security items relevant to the current context; (4) Risk-management planning, involves mitigation for the risk items is integrated; (5) Risk reso- lution and, finally (6) risk monitoring, involve implementing the plan and by keeping the implementation on track by a closed-loop process and applying corrective action whenever necessary.
Risk management sets the foundation for all the security work in the organization, by practically defining the organizational security rationale. Combined with the security regulations and other external factors, it forms the complete Organizational Normative Framework, from which each Appli- cation Normative Framework is derived. An example of such external regula- tion is a governmental requirement for use of a risk management framework or a security maturity model, such as NIST RMF (NIST 800-37) in the United States, or the VAHTI framework in Finland. The caveats of quan- tification of risk probability are obvious: Such calculations should be used with caution, especially when used to manage security-related investments and security work.
An essential characteristic of the risk management process is that it cannot be done by the developers alone: input from the user domain is
essential for the completeness of the assessment. Perhaps due to this, and the amount of work involved in the risk process, the reported experience of risk management in software security research is scarce. This indicates a research gap and a clear demand for improved risk management processes. One such model could be a combination of iterative risk process keeping track of the top 10 (or any number found suitable) of the software security risks in the development project, and managing the security engineering and assurance work utilizing this list.
3.2.3 Security Assurance Engineering
Security assurance has many definitions, and its scope and composition has significantly grown since the introduction of the concept. The assurance el- ements described in the first DoD standards still form the basis of software assurance in software-intensive systems. In the early definitions, assurance consists of system design and security documentation, together with descrip- tions of security policies (cf. DoD (1985b)).
Assurance in the security context is commonly specified as grounds for
confidence that a deliverable meets its security objectives. In ISO/IEC Stan-
dard 15026-2:2011 (2011), a definition of assurance is given as a set of ev-
idence consisting of the sets of known facts, data, objects, claims and as- surance cases. Of these, a claim is further specified as a proposition to be
assured about the system of concern, chosen based on a set of justifications for the objectives. Software (security) assurance is defined as “level of confi- dence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at anytime during its lifecycle and that the software functions in the intended manner”.
Hamidovic (2012) combines security assurance engineering with require- ments engineering in his practical dissection of security assurance selection and implementation. This approach to security assurance reflects the three main areas of software security engineering:
1. Security of the deliverable software through verification and testing.
2. Security of the development processes.
3. Security of the operating environment.
Security assurance exists to create confidence in all three. In an anal- ysis of information assurance techniques by Such et al. (2016), four main components of assurance are identified: (1) Assurance scheme, consisting of standards (e.g., ISO 27001) and qualifications; (2) Assurance target, which are further classified as either security controls or security competence re- quired for assessment; (3) Assurance technique, the method of assessing the
Interview Observe
Observe Witnessed Test
Public Review Observe Review of Client- Completed Self- Assessment Form Review of Documented Policies, Procedures and Processes Threat Assessment Architectural Review Source Code Review Configuration Review Red Team Excercise Penetration Test Test Cryptographic Validation Formal Verification Emanation Security Analysis Social Engineering Fuzz Testing Dynamic Analysis Static Analysis Vulnerability Scanning
Optional Contributing Assurance Technique Optional Parallel Assurance Technique
Figure 3.3: Assurance techniques as given by Such et al. (2016)
target: either security control, such as penetration testing, or controls for the qualifications of the personnel; (4) auditing and assessment evidence of the three other components. All four of these are directly applicable to se- curity context as well. The assurance techniques identified in this study are presented in Figure 3.3.
Not all of the assurance techniques are directly used by the observed software security assurance frameworks, but they may be introduced to the assurance process by e.g. regulation. The level, scope and qualities of se- curity assurance are ultimately dependent on the applied security policies. Beznosov and Kruchten (2004) group security assurance into requirement
assurance, design assurance and implementation assurance.
Implementation assurance is gained by security reviews and various forms of security testing. In a cross-case analysis, Cruzes et al. (2017) identify the following risk-based security testing types in various software development life cycle phases:
• Implementation: Code-based Testing and Static Analysis
• Verification: Penetration Testing and Dynamic Analysis
• Maintenance: Security Regression Testing.
To set the target of the validation’s outcome, the assurance argument must be clarified. In defining the minimum viable security assurance, the NASA definition of minimum security assurance as listed by Davis (2005) could prove helpful:
1. Security risk evaluation process has been performed.
2. Security requirements have been established for the software and data.
3. All software reviews and audits include evaluation of security require- ments.
4. Configuration, change and incident management processes contain se- curity reviews to prevent security violations.
5. Physical security for the software and the data is adequate
In addition to the proof of secure system architecture and design, the security assurance requirement includes verification and validation of appro- priate security controls. This assurance is created to provide an acceptable amount of information about the security policies being enforced. In prac- tice is created by logging the system and application events. The core of security policies is to set the rules for how the access is granted to the data contained in the system. The access control in based on the authentication scheme: the security classification of information and its users.