Positioning of Penetration
Testing and IT Risk
Management Frameworks
investigated
September 2013 Scriptienummer 1090 Jip Hogenboom MSc
it doesn’t matter what business you’re in, it’s a risky business”
1
Preface
This document is the thesis of the postgraduate study programme on EDP auditing at the Vrije Universiteit Amsterdam. This thesis covers the positioning of penetration testing within IT risk management frameworks and the relationship between IT risk management and penetration testing.
We would like to express our thanks to Dr. René Matthijsse RE, our supervisor at the Vrije Universiteit, for his support and criticism.
Additionally, we would like to express our thanks to Mr. Michiel van Veen MSc RE and ir. Peter Kornelisse for their support during the course of the project. We would not have come this far without them.
Furthermore, we would like to thank the participants to our case study interviews for their time and availability to express their opinion and share their experience on this subject.
Last but not least we would like to thank our families for their support and their patience with us during our study. Without them we definitely would not have made it.
Jip Hogenboom Nick Peterman
2
Abstract
Risk management is an important step within each business process and project to minimise, monitor, and control the probability and/or impact of unfortunate events or to maximise the realisation of opportunities. The risk management process generally contains four steps: Determine Assets, Analyse risks, Select applicable controls and test the controls. By performing these four steps, organisations can attempt to minimise the amount of risk they face.
One method of identifying IT-related risks is by performing penetration testing. A penetration test should be performed by a qualified professional and is aimed to identify vulnerabilities and weaknesses on application layer, operating system layer, database layer and network layer. These vulnerabilities can be the result of e.g. inadequate patching, development or system management.
Penetration testing is described as a part of security testing. Security testing itself is covered in IT security frameworks which describe various steps and activities to obtain an appropriate overview of the current status of the security within an organisation.
In this thesis, the positioning of penetration testing within three IT risk frameworks is investigated. The use of penetration testing provides additional insight in the IT-related risks organisations face. However, we noted that penetration testing is inadequately covered in the researched IT risk frameworks. It is either not mentioned at all, or it is only mentioned as a possible action to aid in control testing. However it is never included as a mandatory activity or as a requirement for proper risk analysis.
The investigated IT risk frameworks occasionally refer to IT security frameworks for further reference to perform security testing. However, we believe that any user of the IT risk framework should be guided to initiate mandatory penetration testing activities. Therefore, we feel that the use of penetration testing should be directly incorporated in the generic IT risk frameworks.
Our intention is to improve the general IT risk management process and the overall security of computer systems, networks and organisations in general. We propose updates to the IT risk frameworks to improve upon the identified shortcomings using the advantages penetration testing provides. These additions can be incorporated to update the frameworks in order to put more emphasis on penetration testing within the risk management process.
We have interviewed experts in both the risk management and in the security testing field and we were informed that penetration testing is a valuable method to identify IT-related risks which may not have been identified using other methods. During these interviews it was also noted that the use of IT risk management frameworks alone is not sufficient to determine all possible vulnerabilities and risks organisations face.
Contents
1
Preface ii
2
Abstract iii
3
Introduction 1
3.1 Research question 4 3.2 Approach 4 3.3 Scoping 54
Penetration testing and security management
87
4.1 Introduction 87
4.2 Penetration testing 87
4.2.1 How is penetration testing performed? 98
4.2.2 What are the limitations? 109
4.3 Penetration testing methods 109
4.3.1 KPMG security testing method 1110
4.3.2 SERSC penetration testing method 1312
4.3.3 SANS penetration testing method 1615
4.3.4 NIST 800-115 penetration testing method 1716
4.4 Comparison 1918
5
IT Risk Management
2220
5.1 Introduction 2220
5.1.1 A framework for integrated risk management in IT 2220
5.1.2 Conclusion 2523
5.2 IT Risk Frameworks 2624
5.2.1 American standard: NIST 800-30 – Guide for conducting risk
assessments – Information security (2011): 2725
5.2.2 International organisation: ISACA – Risk IT 3028
5.2.3 International standard: ISO/IEC TR 15443:2012 – Framework for
IT security assurance 3230
5.3 Risk Categories in frameworks 3634
5.3.1 American standard: NIST 800-30 – Guide for conducting risk
assessments – Information security (2011) 3634
5.3.2 International standard: ISO/IEC TR 15443:2012 – Framework for
IT security assurance 3735
6.2.1 X1 - PCD (Process Control Domain) Security Auditor 4037
6.2.2 X2 – Incident analyst 4138
6.2.3 X3 - Manager IT Advisory – Security 4239
6.2.4 X4 - Director IT Advisory – Security 4441
6.3 Main conclusion 4542
7
Conclusions and recommendations
4743
7.1 Conclusion 5743
7.2 Positioning of penetration testing in IT Risk Frameworks 4744
7.2.1 NIST 800-30 – Guide for conducting risk assessments –
Information security (2011) 4845
7.2.2 ISO/IEC TR 15443:2012 – Framework for IT security assurance 4946
7.2.3 ISACA – Risk IT 4946
7.2.4 Summary of risk categories 5047
7.3 Recommendations 5248
7.3.1 Suggestions for updates to the IT Risk Frameworks 5248
7.3.2 Suggestions for improvement Error! Bookmark not defined.48
7.3.3 NIST 800-30 – Guide for conducting risk assessments –
Information security (2011) 5248
7.3.4 ISO/IEC TR 15443:2012 – Framework for IT security assurance 5349
7.3.5 ISACA – Risk IT 5450
8
Research questions revisited
5752
9
Bibliography
6357
3
Introduction
Risk management is an important step within each business process and project to minimise, monitor, and control the probability and/or impact of unfortunate events or to maximise the realisation of opportunities. The strategies to manage risks typically include risk avoidance, risk mitigation, risk acceptance or transferring the risk to other parties. In this thesis, we will consider IT security related risks and will not consider generic risk management, therefore we will cover risks on the network infrastructure, database, operating system and application level. One of the core activities for one of the authors of this thesis (N. Peterman) is IT risk management.
An effective method for identifying risks which are applicable to a specific environment/process is by performing a penetration test or other specific security related tests. The core activities of one of the authors of this thesis (J. Hogenboom) are penetration testing, technical security testing and security configuration reviews.
Penetration testing activities are considered to be a subset of security testing. Security testing is the process of exercising one or more assessment objects under specified conditions to compare actual and expected behaviour. [1]
Security testing activities and guidelines are generally covered in security frameworks such as NIST 800-115 [1] and ISO 27001.
The term security framework is used in a variety of ways, but it has become an aggregate term for the various documents and associated programs from various sources, that give advice on topics related to information security. In particular with regard to planning, managing or auditing of overall information security practices for a given organisation. [2]
IT Security frameworks cover a broad range of activities and are a part of overall risk management frameworks. These frameworks cover the whole spectrum of risk management activities.
The main purpose of this thesis is to provide the reader with an overview of three IT risk frameworks and the positioning of penetration testing in these risk frameworks. We will provide recommendations on how to improve the risk frameworks to include identified gaps.
We believe that penetration testing should be an essential part of each IT risk framework to ensure it is on the radar of the risk management departments. Performing penetration testing should not be dependent on the use of the underlying IT security frameworks, but should be directly incorporated into the risk frameworks.
Risk
A risk can be regarded as a potential situation that might or might not occur in the future. Risk is defined by two characteristics, the probability of occurrence (likelihood) and the consequences of the occurrence (impact). [3]
A substantial part of this research has involved researching IT risk frameworks. Therefore it is important to obtain a good overview of what an IT risk framework is and what its basic components are. Chapter 5 describes the main characteristics of IT risk management.
Risk Categories
We can identify a number of categories which can be used to categorise risks. For this thesis we have decided to use the categorisation specified by the ISACA – Risk IT Framework which describes the six categories as illustrated in Figure 2: IT risk categories.
Figure 2: IT risk categories
We have identified the following definitions for the various enterprise risk categories:
Strategic Risk; Strategic risk is the current and prospective impact on earnings or capital arising from adverse business decisions, improper implementation of decisions, or lack of responsiveness to industry changes. [4]
Environmental Risk; A specific area of risk that can be identified is that on the local and global environment. Accidents, natural events, and deliberate assaults are all possible ways for an enterprise to cause pollution or other risks. [5]
Market Risk; Market risk refers to the risk of losses in the companies trading book due to changes in equity prices, interest rates, credit spreads, foreign-exchange rates, commodity prices, and other indicators whose values are set in a public market. [6]
Credit Risk; Credit risk refers to the risk that a borrower will default on any type of debt by failing to make payments which it is obligated to do.The risk is primarily that of the lender and includes lost principal and interest, disruption to cash flows, and increased collection costs. The loss may be complete or partial and can arise in a number of circumstances. [7] Operational Risk; Operational risk is the risk of loss resulting from inadequate or failed
internal processes, people and systems, or from external events. [8]
Compliance Risk; Compliance risk is the current and prospective risk to earnings or capital arising from violations of, or non-conformance with, laws, rules, regulations, prescribed practices, internal policies, and procedures, or ethical standards. [9]
In our thesis we will determine how penetration testing and IT risk frameworks cover these categories and where they can complement each other.
During our investigation we have determined that risks on IT level can lead to Strategic, Environmental, Operational and Compliance risks. Operational risk can in turn lead to either Credit, Compliance or Market risk.
Compliance Risks can be derived from either IT systems directly (e.g. non-compliance of implementations to regulations) or through Operational Risks (e.g. usage of outdated software). In this thesis we will only focus on risks directly resulting from IT. Additionally, we will not consider Credit Risk and Market Risk due to the dependency on Operational Risk (which is covered).
A graphical overview of the risk categories and their dependencies is provided in Figure 3Figure
3.
3.1
Research question
Our main research question is defined as:
What is the positioning of penetration testing in current IT risk management frameworks, what are the gaps of these frameworks compared to penetration testing in practice and how can these frameworks be improved?
To further analyse this main research question, four sub questions were defined:
1. What is penetration testing, what various types of activities does it include and which IT risk categories can be identified?
2. Which IT risk management frameworks are commonly used in practice, which IT risk categories can be identified by using these frameworks and how do the frameworks cover penetration testing?
3. How do the risk categories identified by penetration testing differ from risks identified by using an IT risk management framework in practice?
4. How can the risks which are solely identified by performing a penetration test be covered and incorporated in order to improve the IT risk management frameworks?
3.2
Approach
We have performed our research in four phases: Phase 1. Analyse penetration testing methods
In phase 1, we have performed a literature study by investigating four penetration testing methods to determine the main differences and similarities between them. Our main aim was to obtain a baseline of activities which should be attended to when performing a penetration test. The description of each method and the results of the comparison are presented in Chapter 4. Phase 2. Evaluation of frameworks
In phase 2, we have performed a literature study and evaluated the three IT risk frameworks in scope (NIST 800-39, ISO/IEC TR 15443:2012 and ISACA Risk IT) to determine if, in which phase and to what extend penetration testing is covered. The results from this evaluation are presented in Chapter 5 and 7.
Phase 3. Case Study / Expert interviews
In phase 3, we have performed an in-depth analysis on the differences between the risks that can be identified by implementing the IT risk frameworks as compared to penetration testing. In addition, we performed four interviews with Subject Matter Experts (SMEs) in the penetration testing and IT risk management field to determine the need for inclusion of penetration testing to the IT risk frameworks. The results of our analysis and the interviews are provided in Chapter 6 and Error! Reference source not found.7.
In phase 4 we summarised our findings and formulated our overall conclusion. Additionally, we provided amendments for the frameworks in scope to cover the identified gaps. Furthermore, we formulated an overall conclusion as a result of our research. The amendments and overall conclusion are provided in Chapter 7.28.
3.3
Scoping
In this thesis, four penetration testing methods will be described: 1. KPMG penetration testing method [10]
2. SERSC (Science & Engineering Research Support Society) [11] 3. SANS Institute [12]
4. NIST 800-115 [1]
In the field numerous risk frameworks are used. In this thesis we will only investigate IT related risks. In practice, we see that three IT risk frameworks are commonly used:
American standard: NIST 800-30 – Guide for conducting risk assessments – Information security (2011) [1]
International standard: ISO/IEC TR 15443:2012 – Framework for IT security assurance (2012) [13]
ISACA – Risk IT (2009) [14]
In this thesis we will investigate these frameworks to determine the place penetration testing upholds and analyse if and which gaps exist in the identification of risks.
This thesis is organised as follows. Chapter 4 provides background information on penetration testing and describes four penetration testing methods. IT risk management is described in Chapter 5. An overview of the interviews performed and the main conclusions is provided in Chapter 6 . Chapter 7 contains an overview of how penetration testing is covered in the three IT risk frameworks in scope for our research. Our suggestions to improve the IT risk frameworks, the conclusion and discussion are provided in Chapter 7.28. The research questions are revisited in Chapter 89 and a bibliography and list of figures is included in Chapter 910. Appendix A
contains a summary of ISACA Risk IT and Appendix B contains an overview of the main writers for each chapter.
4
Penetration testing and security management
4.1
Introduction
Considering security testing is a very broad term, in this thesis we will focus on one of the activities included in ‘Security testing’: penetration testing. This activity was selected due to our extensive experience with penetration testing and the increased exposure in the media with regard to IT related risks and malicious attacks.
Security testing can be defined as the process to determine that an information system, the data and functionality is protected as intended. All three aspects of information classification (confidentiality, integrity and availability) are applicable to security testing.
Organisations can employ security testing to identify weaknesses and vulnerabilities which can contribute to a negative impact on the confidentiality, integrity and availability of information systems. Security testing can contain multiple activities such as:
A configuration review for insecure configuration settings (application, database, operating system or network devices);
A source code review of an application to identify insecure functionality; A review of firewall rule sets to assess the implemented network segregation Performing a malware analysis of identified malicious programs to understand the
motives and work methods of malicious persons;
Performing a security audit to identify insecure processes or e.g. management of privileged accounts;
Performing social engineering and phishing tests to determine and improve the security awareness of employees within an organisation;
Performing physical security testing to determine the effectiveness of implemented physical access controls;
Performing penetration testing to assess the security of an IT environment (application, database, operating system and network) from the perspective of a hacker.
4.2
Penetration testing
In this chapter a theoretical basis is provided on penetration testing including the definition and limitations. According to OWASP, a penetration test is defined as the following:
“A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. […]”
“The process involves an active analysis of the application [or infrastructure] for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution.” [15]
Note that in the definition above, the word ‘method’ indicates there are multiple ways to perform a penetration test. The main purpose of a penetration test is to identify and report on weaknesses and vulnerabilities in IT-systems.
A penetration tester (a person performing a penetration test) is required to describe the risk and impact of exploiting these vulnerabilities, to allow management to make an educated decision on how to deal with the identified risks (e.g. mitigate or accept the risk). It must be noted that a penetration test without any findings does not guarantee that the system is 100% secure. It is no more than a snapshot of a system’s security at a single moment in time. However, it serves as a method to perform risk analysis and control testing.
Penetration testing is considered as a subset of security testing. Figure 4Figure 4 shows the place penetration testing upholds in the full picture of security testing.
Figure 4: Place of penetration testing in the full picture
Other than for the purpose of risk management, penetration tests often are required from a ‘legal’ perspective. An example is the Data Security Standard drafted by the Payment Card Industry (PCI DSS) requiring vendors to perform a periodic penetration test of the environment dealing with credit card data.
We see that penetration tests are also performed to increase the awareness of upper management for security issues (to increase budget) or to test the intrusion detection and response capabilities of departments within the organisation.
4.2.1 How is penetration testing performed?
A penetration test can be performed in multiple ways (black box, white box and gray box). The main differentiating factor is the amount of information which is shared with the penetration tester prior to performing the penetration test.
Black box. A black box test is performed without prior knowledge of the infrastructure, defence mechanisms and communication channels of the target organisation. The penetration tester will
not be provided with any information concerning the target environment other than the IP addresses of the components in scope. This test is performed to simulate an external attacker. White box. A white box test is performed with full knowledge of the infrastructure design and components. When testing the security of an application, also the source code is distributed to the penetration tester and application accounts are provided. Performing a white box penetration test will allow one to identify the largest amount of vulnerabilities. A white box penetration test will allow one to identify more vulnerabilities than a black box penetration test at the expense of time.
Grey box. A grey box test is performed with minor knowledge of the infrastructure design. As an example, specific parts of the infrastructure design can be provided. Additionally, application accounts or OS accounts are provided to simulate a malicious user or attacker with access to the underlying system. These accounts are used to test for privilege escalation and segregation of access rights. Additionally all functionality within the application can be tested in this way.
4.2.2 What are the limitations?
Depending on the chosen method (e.g. black box vs. white box) and due to a time-boxed approach, vulnerabilities and weaknesses might be missed during the penetration testing which might be obvious to someone with knowledge of the internal workings of the application. A penetration test can only identify those problems that it is designed to look for. It should also be noted that new vulnerabilities can be identified in the used software at a later stage which were not known at the time of testing.
It should be noted that a malicious hacker will always have more time available than a penetration tester and as such may be able to identify additional weaknesses not identified during a penetration test. Penetration testing is a time-boxed effort and the outcome of a penetration test is largely dependent on the skill set of the assessor. More skilled penetration testers will be able to identify more vulnerabilities within a shorter period of time than people who are new to the field. Additionally, the risk exists that vulnerabilities and weaknesses are overlooked by the assessor or testing is performed in an inefficient manner.
This risk is also recognised by “De Nederlandse Bank (DNB)” who states that an investigation is being initiated by DNB to check the quality of penetration tests and the security of mobile apps. The DNB has leads that the quality and quantity of penetration tests are not always sufficient to obtain certainty concerning the security which is derived by the organisations themselves and third parties [16].
4.3
Penetration testing methods
To reduce the risks described in section 4.2.24.2.3, penetration testing methods have been developed. Each organisation providing penetration testing services uses their own method of testing. Additionally, public institutes have developed penetration testing methods which can be used to perform penetration testing.
Four penetration testing methods will be described within this section: 1. KPMG security testing method [10]
3. SANS Institute [12] 4. NIST 800-115 [1]
We have chosen to assess these specific approaches for the following reasons. The KPMG penetration testing method is used daily in our work. The SERSC is an autonomous research group, their approach was chosen due to the fact that research groups are considered to be unbiased. The SANS institute is a publicly known and respected institute which also provides expert training sessions and NIST is an internationally recognised organisation providing technical standards on various subjects.
4.3.1 KPMG security testing method
The KPMG security testing method [10] is used as guideline for penetration testing services performed by KPMG. In this chapter, we provide a summary of the steps taken within a penetration test performed by KPMG.
Before commencing the penetration test, a signed Letter of Authorisation (LOA) is required to be signed by the client. Within this letter, the client authorises the penetration testing vendor team to perform the penetration testing on specific IP addresses (the scope). Additionally, the client declares that it shall indemnify and hold harmless the penetration testing vendor against any damage, demands, liabilities and claims for personal injuries and/or property damage that may be caused by or ensue from the execution of the penetration test.
Additionally, the activities to be performed (and not to be performed) are agreed upon between the penetration testing vendor and the client to ensure the test will have the correct focus. The KPMG testing approach shows tests are performed in three phases: mapping, scanning and exploiting. Figure 5Figure 5 below demonstrates that these phases can be performed iteratively depending on the gathered findings during each phase.
Figure 5: Penetration Testing Phases
Mapping concerns the identification of systems and applications within the IT environment in scope of the penetration testing engagement. The identified services and applications are monitored, evaluated and discussed with the client to determine if the scope is correct and if additional scanning and testing should be performed.
Scanning concerns the identification of services and known weaknesses on systems and applications that are likely to be vulnerable for exploiting. Depending on the engagement, scanning is performed with automated tools and manually. In our experience, automated scanning tools are usable to identify initial vulnerabilities. However, manual penetration testing allows one to identify more vulnerabilities and determine the impact of successful exploitation much better. In parallel during the scanning phase, the report is drafted (reporting) to ensure a preliminary overview of findings can be supplied to the client whenever requested.
Exploiting is focused on exploiting the identified vulnerabilities, or determining how difficult it would be to do so given unlimited time, based on a certain level of skills and experience. Exploiting is a form of testing whereby the techniques of a hacker are used. They serve to test the level of effectiveness of the implemented security measures, and real attempts are made to break in to the environment. As part of testing, clean-up of changes (if any) is supported. It should be noted that the exploiting phase can result in the identification of additional services which should be included in the scope of the penetration test.
After performing the phases tests, the final report is drafted. To determine the severity of the findings, a categorisation in ‘high’, ‘medium’ and ‘low’ risk findings is provided. The severity is based on the impact on the confidentiality, integrity and availability of the servers, data residing on the servers and the business processes.
The report includes the following information: The scope of the penetration test;
Management summary containing an overall summary on the state of the security; Results;
The main/critical findings;
A heat map showing the findings within a matrix (likelihood vs. impact); The detailed findings and recommendations;
The evidence for the findings; A cleanup list.
Additionally, an activity checklist (AC) is completed including the testing activities performed and a logbook containing the invasive activities for filing and reference purposes. The activity checklist also includes a detailed list of actions which should at least be performed and acts as a validation to ensure no steps have been missed.
Analysis of the KPMG penetration testing method
The KPMG penetration testing method contains a concise overview of the various steps considered within a penetration test. It includes a clear distinction within the phases to be performed within a penetration test and provides a link-up with newly identified services/applications during the test. The methodology does not provide an overview of the specific tools to be used and instead relies on the professionalism and knowledge of the security tester.
Since a Security Testing Activity Checklist (STAC) is completed with the logbook of the penetration test, it is ensured that no steps within the penetration testing process have been missed.
4.3.2 SERSC penetration testing method
The Science & Engineering Research Support Society (SERSC) proposes a method to perform penetration testing [11]. This method can be described using the following figure:
Figure 6: SERSC Penetration Testing Method
This method describes three main categories: Information, Team and Tools. Information
The first phase is gathering information about the environment, the used systems and procedures. The approach starts with identifying public information using technical and non-technical methods.
SERSC considers two kinds of penetration tests: black box (information is closed) and white box (information is shared). SERSC considers the information gathering phase as a requirement for black box penetration testing since no information is known before commencing the test. SERSC considers four steps in information gathering.
1. The first step of information gathering is a network survey to obtain a network map to identify the number of reachable systems. Result of this phase will be domain names, server names, IP addresses, a network map, ISP/ASP information and system and service owners. 2. The second step consists of OS identification by actively probing the system for responses that can distinguish its operating system and version level. SERSC considers ‘nmap’ to be the best method for OS identification.
3. Step 3 within this penetration testing method is port scanning. SERSC considers it the responsibility of the team to determine if all 65,536 ports need to be scanned and deems it not always necessary to scan for all ports. The Consensus Intrusion Database Project site is used as a reference to determine the ports to be scanned. As a result, a list will be obtained with the open, closed and filtered ports and discovered protocols. 4. The final step within the identification phase is “services identification” where active examination of the application listening behind the service is performed. As a result of this phase, service types, applications and patch levels can be determined.
Team
The penetration testing team should divide their roles and responsibilities to be most effective. Each member should be aware of their role and the affixed procedure.
Tools
According to SERSC, the last most important part of the test is the toolset. The penetration testers are to be expected to have excellent knowledge on the usage of important tools.
In order to facilitate the test, the company has to provide information regarding the scope and range of the test. This information should be true and accurate. Also, a timing table should be agreed upon, so that the tests can be carried out in a non-harmful period. All information is considered to be confidential.
According to SERSC, the penetration tester must be held responsible for all damage that occurs to the reason of testing. The penalty for the damage should be agreed upon and stated in the contract prior to the testing.
SERSC does not deem the penetration tester responsible when timing of a Denial of Service attack is not agreed upon.
In addition, when a penetration tester sub-contracts parties, the client does not have to provide written consent.
Analysis of the SERSC penetration testing method
The SERSC considers the used penetration testing method as one of the crucial factors of success in a penetration test, however, the method provided by the SERSC is very generic and cannot guide as a detailed method for performing a penetration test. We noted that a number of statements are either wrong, not relevant or not adequate. Additionally, the step of exploiting is not mentioned within the framework, resulting in a testing outcome which only contains findings resulting from the scanning phase.
Within the method, it is stated that the penetration tester is fully responsible for all damage that occurs to the reason of testing. We think that downtime of the system is always a risk when performing a penetration test and should be accepted by the client before penetration testing is performed. Therefore, we recommend to refrain from all tests which may result in a Denial of Service and agreeing upon this within a contract. Additionally, we recommend to perform the penetration testing activities on a non-production environment (such as development or staging) to prevent downtime of the live environment.
The SERSC considers it the responsibility of the team to determine if all ports need to be scanned and deems it not always necessary to scan for all ports. We believe a penetration tester should always scan for all open ports on the system and cannot identify a reason why this should not be necessary. Refraining from scanning all open ports might result in the penetration tester missing a specific service running on an exotic port which might be highly vulnerable. In our opinion, it is not acceptable to use subcontracted parties without written consent by the client. As the information which can be obtained by successfully exploiting a vulnerability can be most confidential, special care should be taken to prevent access to this information to unknown external parties. Additionally, special care should be taken with regard to
confidentiality within the contract to define measures to be taken when confidentiality is compromised.
4.3.3 SANS penetration testing method
The SANS institute provides expert trainings on various IT related topics. They have presented a penetration testing approach [12] which is also used within their training courses. The approach consists of five main phases.
Planning and preparation.
The first part of a penetration test should be the kickoff meeting between the penetration testers and the organisation. Within this meeting the scope and objectives and the parties involved should be discussed. Additionally, the form in which the results or outcome of the test is presented should be agreed upon.
An important part to discuss is the timing and duration of the penetration test to ensure that regular business operation is not disrupted. SANS indicates that a penetration test can always result in crashing of systems. If this cannot be tolerated, some systems or networks may need to be excluded from the test.
Additionally, it should be discussed if the staff of the organisation should be informed before the penetration test is carried out. The test can for example be performed without prior notification to test the monitoring and incident response capabilities. However, this can also result in a negative effect if, for example an administrator notices unauthorised access on a system and decides to disconnect the system from the network resulting in unavailability of the system.
As with the other methods, SANS indicates that data should be treated as confidential and legal documents should be signed between the penetration testing company and the client.
Information Gathering and Analysis
The second part of the penetration test is information gathering including host discovery (reconnaissance) and port scanning using automated tools.
After gathering this information, the next step is to identify vulnerabilities that exist in each system. An analysis is performed on the obtained information to determine any possible vulnerabilities. This step is performed using automated tools and manual testing.
Penetration attempt
The third phase which is distinguished by SANS is the ‘penetration attempt’ phase which is roughly identical to the ‘exploitation’ phase mentioned earlier. SANS mentions that the scope for performing the penetration attempts should be chosen carefully since a penetration test is time-boxed.
Analysis and reporting
After conducting the tests, a report should be created for the organisation containing the penetration testing process performed and detailing the identified vulnerabilities in the order of criticality to help the organisation with decision making.
A detailed and exact list of all actions performed should be kept during the penetration test to make sure all modifications and files left behind can be cleaned up.
Analysis of the SANS penetration testing method
We noticed that a number of specific tools are mentioned within the SANS penetration testing method. It should be noted that these tools might not be up to date and are replaced by other tools since the release of the method. Testers following this method may not be aware of the latest version of specific tools and may be testing with outdated applications. This will result in an incomplete overview of findings. Therefore, we recommend refraining from naming these specific tools within the penetration testing method and providing a more generic overview. Regarding the other aspects, the framework provides adequate and detailed information.
4.3.4 NIST 800-115 penetration testing method
NIST 800-115 provides an overview of technical security testing and examination techniques [1]. Additionally, various testing approaches are mentioned. Also, the term ‘overt’ and ‘covert’ are introduced pointing to the choice to inform or not inform operational employees.
The document contains a chapter specific on penetration testing, differentiating four phases: planning, discovery, attack and reporting.
Planning
In the planning phase, rules are identified, management approval is finalised and documented and testing goals are set. No actual testing is performed in this phase.
Discovery
The discovery phase consists of two parts. The first part is the start of actual testing and covers information gathering, reconnaissance and scanning where network port and service identification is conducted to identify potential targets. In addition, other actions are performed such as banner grabbing to identify the used application versions. The second part of the discovery phase is vulnerability analysis which involves comparing the services, applications and operating systems against vulnerability databases using automated tools and the testers knowledge.
Attack
NIST further splits the attack phase in four steps: Gaining access, escalating privileges, system browsing and install additional tools. These steps are described in Figure 7Figure 7:
Figure 7: NIST: Penetration Testing method
NIST indicates that most vulnerabilities fall into the following categories which can be identified by performing a penetration test:
Misconfigurations Kernel flaws Buffer overflows
Insufficient input validation Symbolic links
File descriptor attacks Race conditions
Incorrect file and directory permissions Reporting
According to NIST the reporting phase occurs simultaneously with the other three phases. The requirements of the reporting phase are identical to the methods presented before.
Analysis of the NIST 800-115 penetration testing method
The NIST framework is an extensive framework containing a detailed overview of the steps to be performed during a penetration test and describes the risks if using concurrent automated scanning tools. In addition, the attack phase is described in detail, containing relevant information for non-technical readers to understand the process of penetration testing.
4.4
Comparison
In this chapter, we provide the main differences and similarities with regard to the penetration testing methods.
Main differences and similarities
The main differences between the analysed penetration testing methods concern the level of detail described within the documents and completeness of the testing methodology.
The main similarities identified within the described approaches is the fact that multiple phases are used which are named uniquely within each approach. Usually, a penetration test starts with a planning and preparation phase in which the scope is determined, legal documents are signed and the testing days are determined.
Next, the penetration testing phases start. Within each method, various names are used for each phase, mostly including similar actions:
KPMG SERSC SANS NIST
Phase 1 Mapping Information gathering
Information gathering and analysis
Discovery
Phase 2 Scanning Information gathering
Information gathering and analysis
Discovery
Phase 3 Exploiting - Penetration attempt Attack (gaining access, escalating privileges, system browsing, install additional tools)
Phase 4 Reporting Reporting Analysis and reporting Reporting Table 1: Definition of penetration testing phases
Overall conclusion
From this analysis it can be concluded that the KPMG, SANS and NIST penetration testing methods provide a solid base for performing a penetration test. Each of these methods consist of various phases in which the test should be performed. We think that the following four phases are key within a penetration test:
The identification of systems and applications within the IT environment in scope of the penetration testing engagement (mapping);
The identification of services and known weaknesses on systems and applications that are likely to be vulnerable for exploiting (scanning);
Exploiting the identified vulnerabilities, or determining how difficult it would be to do so given unlimited time, based on a certain level of skills and experience (exploiting).
Documenting the identified weaknesses and vulnerabilities based upon their likelihood and impact (reporting).
Other than the definition of these phases, no major differences exist within these models. All in all, we believe that these three frameworks are fit-for-purpose and provide a decent base for commencing penetration testing activities.
We noticed that the penetration testing method proposed by the SERSC lacks depth and detail and as such is considered to be inadequate as base for penetration tests. We decided to incorporate the analysis of this framework within our thesis to show the reader that care must be taken in selecting the penetration testing methodology to be followed. Due to the observed shortcomings, this framework will not be used for further analysis within this thesis.
IT risk categories
The following table shows the risk categories and a motivation if risks for the particular category can be identified by penetration testing. For background information on the risk categories, please refer to chapter 3
Risk Category Covered by penetration testing
Motivation
Strategic Risk No IT related risks can result in downtime of critical processes and incorrect business decisions which are strategic risks.
Penetration testing can only identify IT related risks and does not consider the impact on the strategy per se. This would require a detailed impact assessment. Environmental Risk No IT related risks can result in environmental damage,
for example in the case of industrial environments. Penetration testing can only identify IT related risks and does not consider the impact on the environment per se. This would require a detailed impact
assessment.
Operational Risk Yes The downtime of critical processes can lead to operational risks.
Penetration testing can be used to identify risks for the operational processes on operating system,
Compliance Risk Yes Penetration testing can be used to identify risks related to non-compliance to laws, rules and regulations. E.g. SOX and PCI-DSS.
5
IT Risk Management
5.1
Introduction
Risk management is the identification, assessment, and prioritisation of risks (defined in ISO 31000 as the effect of uncertainty on objectives, whether positive or negative) followed by a coordinated and economical application of resources to minimise, monitor, and control the probability and/or impact of unfortunate events or to maximise the realisation of opportunities. [15]
Risk assessment is one of the key components of an organisational risk management process as described in NIST Special Publication 800-30[17]. Risk assessments are used to identify, prioritise, and estimate risk to organisational operations (i.e., mission, functions, image, and reputation), organisational assets, individuals, other organisations, and the Nation, resulting from the operation and use of information systems.
The purpose of the risk assessment component is to identify: (i) threats to organisations or threats directed through organisations against other organisations or the Nation; (ii) vulnerabilities internal and external to organisations; (iii) impact (i.e., harm) to organisations that may occur given the potential for threats exploiting vulnerabilities; and (iv) likelihood that harm will occur. The end result is a determination of risk (i.e., the degree of harm and likelihood of harm occurring). [4]
Risk management can be performed on various levels in an organisation. For this study we will focus on IT Risks.
IT risk management can therefore be regarded as, the application of risk management to Information Technology in order to manage IT Risks.
5.1.1 A framework for integrated risk management in IT
In 1992, Mykytin et al [18] have described an IT risk framework. This framework provides a good basis and understanding of generic IT risk management processes. Even though this framework was written over 20 years ago, it still provides a good basis and understanding of general IT risk management frameworks. Also, as will be discussed later, the overall structure that is displayed, is very similar to present frameworks.
According to Mykytin et al to [18], there are four major components within the risk management process:
1 Risk identification 2 Risk analysis
3 Risk reducing measures 4 Risk monitoring
The components and activities that belong to these components should take place as early as the planning stage of systems development and continue throughout the development process. The entire process is an ongoing cycle as can be seen in Figure 8.
Figure 8: Risk Management Cycle
Risk Identification
Risk management for IT begins with the risk identification process, which allows organisations to determine the potential impact of internal and external threats on the entire IT environment. The IT environment consists out of three levels according to Mykytin [18].
Application Level: The application level focuses on the risks of technical or implementation failure of IT applications. Such risks may arise from both internal and external sources.
Organisational Level: At the organisational level the focus is on the impact of IT throughout all functional areas of the organisation. The growing reliance on IT to obtain strategic benefits can make the organisation subject to various types of risks.
Interorganisational Level: Organisations nowadays have IT networks that surpass the organisational boundaries. These networks play an important role in enhancing interfirm relationships. According to Mykytin the top three threats for networked environments are: natural disasters, intrusion by computer hackers and weak and ineffective control.
Risk Analysis
The next step in the risk management cycle is the Risk Analysis. In this step, the risks identified in step 1 are assessed. There are several methods available to comprehend these risks, for instance a qualitative or a quantitative approach is possible.
A qualitative analysis is performed on on the expected risks and their corresponding losses. It consists of several different parts and analyses.
Dependency analysis: determines the importance of an Information System and the processes it supports. It also determines the importance of the supported process to the organisation so it can determine what the damage will be if the Information System fails. Configuration analysis: determines the objects that are part of the information system and
the relations between these objects.
Vulnerability analysis: determines the vulnerability of every object for several threats and the amount of security these objects need.
Measure analysis: determines the security measures that are needed to protect the
Information System against threats, in such a way that the risks that remain are acceptable to the Organisation. [19]
Quantitative analysis resembles qualitative analysis but on important points (threats) a quantification is wanted. It uses the formula ― “Risk = chance of damage * damage”.
The problem however with quantitative analysis is however, that it is important that the chances and actual damage are known. This is a problem within ICT, considering this is a relatively new business and corporations are not very open on sharing their security issues. [19]
Risk Reducing Measures:
Implementing measures to reduce IT risks is the third phase of the risk framework proposed by Mykytin.
Once the IT Risks are identified and classified, necessary steps should be taken to ensure the entire IT environment is protected from risks.
The framework recognises a number of measures for various types of risks: Measures for natural disasters
Measures for reducing data security risks
Measures for reducing risks from computer viruses Measures for reducing strategic risks
Measures for reducing legal risks
According to Loch et al (1992) [20], in 1994 IT managers considered natural disasters as the greatest threat to IT systems which can be discussed nowadays.
Risk Monitoring:
The final step in the IT risk management cycle is Risk Monitoring. The purpose of this step is to actively verify and monitor whether the measures are appropriately implemented. It is used to determine if the risk reducing measures, actually reduce the expected losses. It serves as an ongoing audit function.
5.1.2 Conclusion
There are quite a large number of risk management frameworks available online. Each framework uses different terminology and has a different specific approach and methods. However the frameworks investigated in this thesis tend to have a similar structure as the framework described above.
Risk assessment is performed on a predetermined frequency and is restarted once the risk management cycle is restarted. It provides a temporary view of the assessed risks and is used to determine any further actions in the risk management cycle.
5.2
IT Risk Frameworks
In the field numerous risk frameworks are used. In this thesis we will only investigate IT related risks. In addition, we will not focus on regulatory compliance frameworks such as PCI-DSS (Payment Card Industry – Data Security Standard) as these are considered to be control frameworks. Nor will we investigate ISO 27001, considering this is an information security framework and mainly focuses on establishing an Information Security Management System and security controls. Other frameworks are more generic and provide overall guidance in the risk management cycle.
We feel that penetration testing should be a mandatory task in the regular IT Risk Management process and should not just be adhered to as part of regulatory compliance.
In practice, three frameworks are commonly used. Each of these three frameworks have a different perspective on how to approach risk management and what activities/purposes and results it yields. Therefore we have selected the following three frameworks as our baseline for this thesis:
American standard: NIST 800-30 – Guide for conducting risk assessments – Information security (2011)
The purpose of NIST 800-30 is to provide guidance for conducting risk assessments of federal information systems and organisations. Risk assessments, carried out at all three tiers in the risk management hierarchy, are part of an overall risk management process—
providing senior leaders/executives with the information needed to determine appropriate courses of action to take in response to identified risks.
International standard: ISO/IEC TR 15443:2012 – Framework for IT security assurance We have decided to investigate this particular framework, to determine how IT security assurance can be provided. Even though penetration testing can only provide negative assurance, we do expect penetration testing to be mentioned in some way.
ISO/IEC TR 15443 is a multi-part type 3 Technical Report to guide the IT security
professional in the selection of an appropriate assurance method when specifying, selecting, or deploying a security service, product, or environmental factor such as an organisation or personnel (known as a deliverable). The aim is to understand the assurance type and amount required to achieve confidence that the deliverable satisfies the stated IT security assurance requirements and consequently its security policy.
ISACA – Risk IT
The Risk IT Framework fills the gap between generic risk management frameworks and detailed (primarily security-related) IT risk management frameworks. It provides an end-to-end, comprehensive view of all risks related to the use of IT and similarly thorough treatment of risk management, from the tone and culture at the top, to operational issues. In summary, the framework can enable enterprises to understand and manage all significant IT risk types, building upon the existing risk related components within the current ISACA frameworks, i.e. COBIT and Val IT.
In the following sections we will investigate the three frameworks and provide a summary of each of the models.
5.2.1 American standard: NIST 800-30 – Guide for conducting risk assessments – Information security (2011):
Figure 9: NIST Risk Management cycle
The purpose of ‘NIST 800-30 – Guide for conducting risk assessments’ is to provide guidance for conducting risk assessments of federal information systems and organisations. US Federal organisations are obligated to comply to the guidelines. The framework however also provides guidance to other organisations. Risk assessments, carried out in the entire risk management hierarchy, are part of an overall risk management process --- providing senior leaders/executives with the information needed to determine appropriate courses of action to take in response to identified risks. [16]
The framework provides practitioners with practical guidance for carrying out each of the three steps in the risk assessment process (prepare for the assessment, conduct the assessment, and maintain the assessment) and how risk assessments and other organisational risk management processes complement and inform each other.
The NIST publication focuses on the risk assessment component of risk management. It provides a step-by-step process on how to prepare for risk assessments, how to conduct them and how to maintain a currency of risk assessments over time.
Risk assessments can be conducted at all three tiers in the risk management hierarchy – Tier 1 Organisation risk, Tier 2 Mission / Business Processes and Tier 3 Information Systems. Figure 10 illustrates the risk management hierarchy defined in NIST which provides multiple risk perspectives from the strategic to the tactical level.
Figure 10: Risk Management Hierarchy
According to NIST, risk is a measure of the extent to which an entity is threatened by a potential circumstance or event. It is typically a function of the adverse impacts that would arise if the circumstance or event occurs and the likelihood of occurrence. Information security risks are risks that arise from the loss of confidentiality, integrity or availability of information or information systems.
In the process identified by NIST there are four main steps that can be identified, with each their own tasks and sub steps. These main steps are:
Preparing for the risk assessment: The objective of this step is to establish a context for the risk assessment.
Conduct the assessment: The objective of this step is to produce a list of information security risks that can be prioritised by risk level and used to inform risk response decisions. Maintaining the risk assessment: The third step in the risk assessment process is to maintain
the assessment. The objective of this step is to keep current over time, the specific knowledge of the risk organisations incur.
Risk Monitoring: The fourth step of the process concerns monitoring and is covered in NIST Special publication 800-39. As such, this step is not covered within our thesis.
In this section we will only provide a summary of the steps where penetration testing activities could be performed (Step 2, Conducting the risk assessment).
Conducting the risk assessment
a. Identify and characterise the threat sources of concern to the organisation, including the nature of the threats and for adversarial threats, capability, intent and targeting
characteristics.
b. Identify potential threats, relevance to the organisation and the threat sources that could initiate the events.
c. Identify vulnerabilities and predisposing conditions that affect the likelihood that threat events of concern result in adverse impacts to the organisation.
d. Determine the likelihood that threat events of concern result in adverse impacts to the organisation, considering (i) the characteristics of the threat sources that could initiate the events; (ii) the vulnerabilities and predisposing conditions identified; and (iii) organisational susceptibility reflecting safeguards/countermeasures planned or implemented to impede such events.
e. Determine the adverse impacts to the organisation from threat events of concern
considering: (i) the characteristics of the threat sources that could initiate the events; (ii) the vulnerabilities and predisposing conditions identified; and (iii) organisational susceptibility reflecting safeguards/countermeasures planned or implemented to impede such events. f. Determine the risk to the organisation from threat events of concern considering: (i) the
5.2.2 International organisation: ISACA – Risk IT
Figure 11: ISACA Risk IT Risk Management cycle
The ISACA – Risk IT Framework is dedicated to help enterprises manage IT-related risk. The framework complements ISACA’s COBIT and it is to be used to help implement IT governance and enterprises that have adopted (or are planning to adopt) COBIT as their IT governance framework can use Risk IT to enhance risk management.
IT Risk is business risk - specifically, the business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise. It consists of IT-related events and conditions that could potentially impact the business.
IT Risk can occur with both uncertain frequency and magnitude, and it creates challenges in meeting strategic goals and objectives. IT risk can be categorised in various ways:
IT Benefit/value enablement risk – Associated with (missed) opportunities to use technology to improve efficiency or effectiveness of business processes, or as an enabler for new business initiatives.
IT Programme and project delivery risk – Associated with the contribution of IT to new or improved business solutions, usually in the form of projects and programmes. This ties to investment portfolio management (as described in the Val IT framework).
IT Operations and service delivery risk – Associated with all aspects of the performance of IT systems and services, which can bring destruction or reduction of value to the enterprise.
The ISACA – Risk IT framework contains nine steps to perform the full risk management cycle. Considering we are focussing on the role penetration testing holds within these risk frameworks, and we have identified that the penetration testing activities take place during the risk identification and analysis phases, we will only provide a summary of the activities where we believe that the penetration testing activities could be performed.
1. RE2 Analyse Risk
RE2.1 Define IT risk analysis scope
In this step the breadth and depth of the risk analysis will be determined. The scope is based on risk focus areas, strategic decisions or as a response to indicators. The final risk analysis scope is set after a final consideration of the criticality of assets, costs to analyse and potential overarching regulatory requirements.
RE2.2 Estimate IT risk to and from critical products, services, processes and IT resources
Identify threats against risk assets (i.e. the assets that fall within the scope of the risk analysis). Estimate the probable frequency of occurrence and magnitude of the business impact and estimate the maximum amount of damage that could be suffered (e.g. a worst-case loss when specific risk factors converge).
RE2.3 Identify risk response options
Examine the range of possible responses to the risk: accept, exploit, mitigate, transfer or avoid.
RE2.4 Perform a peer review of IT risk analysis results
Perform a peer review of the risk analysis results before sending them to management for approval and use in decision making.
2. RR2 Manage IT Risk
RR2.1 Inventory controls, capabilities and resources
Based on control accountability mappings, inventory the controls, capabilities and resources applied against risk issues or in place to take advantage of opportunities. Classify controls as predictive, preventive, detective, corrective, or monitoring, and map them to specific IT risk statements and aggregations of IT risk.
RR2.2 Monitor operational alignment with risk tolerance thresholds
Ensure that each business line accepts accountability for operating within its individual and portfolio tolerance levels and for embedding monitoring tools into key operating processes. For key risk issues, monitor control performance and effectiveness, and measure variance from thresholds against objectives. Obtain buy-in from management on indicators that will function as KRIs. When implementing KRIs, set thresholds and
checkpoints (e.g., weekly, daily, continuously), and configure where to send notifications (e.g., line management, senior management, internal audit) so the recipients can respond or adjust their plans. Integrate KRI data into ongoing performance indicator reporting. Inputs To Outputs
RR2.3 Respond to discovered risk exposure and opportunity
Emphasise projects that are expected to reduce the potential frequency and severity of adverse events/losses and balance those projects with projects enabling the seizing of strategic business opportunities. Hold cost/benefit discussions regarding the contribution of new or existing controls toward operating within risk tolerance to specific objectives. Select candidate IT controls based on specific threats, the degree of risk exposure, probable loss and mandatory requirements specified in IT standards. Monitor changes to the underlying business operational risk profiles and adjust the rankings of risk response projects.
RR2.4 Implement controls
Take appropriate steps to ensure the effective deployment of new controls and adjustments to existing controls. Communicate with key stakeholders early in the process. Before relying on the control, conduct pilot testing and review performance data to verify operation against design. Map new and updated operational controls to monitoring mechanisms that will measure control performance over time and prompt management action when needed. Identify and train staff on new procedures as they are deployed.
RR2.5 Report on IT risk action plan progress
Monitor IT risk action plans at all levels to ensure the effectiveness of required actions and to determine whether acceptance of residual risk was obtained. Ensure that committed actions are owned by the affected process owner(s) and deviations are reported to senior management.
Appendix A.1 provides a full summary of the ISACA – Risk IT framework.
5.2.3 International standard: ISO/IEC TR 15443:2012 – Framework for IT security assurance
The objective of ISO/IEC TR 15443:2012 is to describe the topic of security assurance, providing the fundamental concepts of the topic and present various security assurance techniques. A framework in which an appropriate security assurance can be made is provided. From our perspective, it is interesting that a framework exists which claims to be able to provide positive security assurance, where in our daily work, we can only provide negative assurance using penetration testing. A penetration test without any findings does not result in positive IT Security assurance (due to time boxed approach and dependency on the skill set of the tester) but only provides information with regard to the current state of the IT in scope.
The framework provides guidance to the IT Security Professional in the use of security assurance to achieve confidence that a given deliverable satisfies its stated IT security assurance requirements. This report examines security assurance techniques, and security assurance
methods proposed by various types of organisations whether they are de-jure or de-facto in nature.
The security assurance framework focuses on providing an understanding of how to obtain security assurance in a given life cycle stage of a deliverable.
In pursuit of this objective, ISO/IEC TR 15443:2012 comprises the following: [5] the terms and definitions relating to the topic of security assurance;
the fundamental concepts relating to security assurance;
guidance to the selection, application, composition and recognition of assurance methods; a presentation of common and unique properties specific to assurance methods;
a framework model to position existing assurance methods and to show their relationships. In this thesis we will mainly focus on the framework described to determine the existing assurance methods and their relationships.
Structure of security Assurance
Figure 12Figure 12, displayed below portrays the relationships between the security expected by a deliverable and the security assurance processes that contribute to providing the required security assurance.
Security assurance requirements specifications:
Security assurance requirements are elucidated by an analysis of the security requirements for the deliverable, influencers, security requirements (policies), business drivers and the target environment for the deliverable. A risk assessment is then performed to provide an in-depth look at the asset sensitivity, vulnerabilities and the threats to determine the residual risk and recommendations for existing and proposed safeguards.
Guidance on risk analysis can be found in ISO/IEC 27005. ISO/IEC 15408 contains information on security functional and assurance requirements for IT products and systems specific to traditional IT security evaluations.
Security Assurance cases:
A security assurance case is an overall package of security assurance related to the IT system. It demonstrates how and with what confidence, the security assurance requirements for an IT system have been met.
Security Assurance Evidence:
The security assurance case is supported by security assurance evidences which are artifacts in support of the security assurance claims.
Security Assurance Arguments:
Security assurance arguments substantiate security assurance claims. There may be one or more security assurance argument to substantiate a security assurance claim.
Techniques:
In the next section the three possible techniques provided by the framework will be explained. Effectiveness or evaluation: An evaluation method allows for the security assurance claim to
be tailored in order to meet the deliverable at hand or specific requirements of the stakeholder specifying the assurance requirements.
Correctness (or conformance): A correctness method makes an assurance claim based on conformance to a standardised specification. Typically there is little flexibility. The system either meets the specified requirements or it does not.
Predictive assurance: Environmental factors associated with the organisation responsible for the deliverable, which cannot be discounted due to a recognised history of special
performance such as consistent and repeated performance to meet its security policy or to meet the assurance claims.
