Positioning of Penetration Testing and IT Risk Management ... · Testing and IT Risk Management...

Positioning of Penetration Testing and IT Risk

Management Frameworks investigated

September 2013

Scriptienummer 1090

Jip Hogenboom MSc

Nick Peterman MSc

Jip Hogenboom MSc Nick Peterman MSc

Thesis EDP Audit, Vrije Universiteit AmsterdamSeptember 2013

i

“If you don’t invest in risk management,

it doesn’t matter what business you’re in,

it’s a risky business”

Gary Cohn



ii

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

Amstelveen, September 2013



iii

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.



iv

Contents

1 Preface ii

2 Abstract iii

3 Introduction 1 3.1 Research question 4 3.2 Approach 4 3.3 Scoping 5

4 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 5.3.3 International organisation: ISACA – Risk IT 3735

6 Interview findings analysis: 3936 6.1 Approach 3936



v

6.2 Summary of interviews 4037 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 9.1 List of Figures 6458



1

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.

Figure 1: Security testing hierarchy



2

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]



3

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. Figure 3: IT risks in the overall landscape



4

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.

Phase 4. Finalise research



5

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



6

contains a summary of ISACA Risk IT and Appendix B contains an overview of the main writers for each chapter.



7



8

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]



9

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



10

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]

2. SERSC (Science & Engineering Research Support Society) [11]



11

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.



12

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.



13

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:



14

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.



15

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



16

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.

Cleaning up



17

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:



18

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.



19

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);



20

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, application/database and network level.



21

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.



22

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.



23

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.



24

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.



25

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.



26

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.



27

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.



28

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.



29

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 impact that would result from the events; and (ii) the likelihood of the events occurring.



30

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).



31

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



32

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



33

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.

Figure 12: The relationship between security in the deliverable and security assurance



34

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.



35

Selecting Security Assurance Techniques:

The selection of an appropriate security assurance and technique is a decision that should be based on the organisational security assurance policy, business requirements and type of deliverable.

The selected assurance technique should be compatible with the organisation’s environment and be capable of examining the desired attributes and life cycle stages of the deliverable.

The assurance authority needs to determine the correct mix of assurance techniques to satisfy the organisations requirements.

Security Assurance ratings:

The selected assurance method can offer a mechanism for determining the amount of assurance offered. These may be stated as e.g. security levels or evaluation levels.



36

5.3 Risk Categories in frameworks

In this section we will investigate what risk categories are included in the various IT risk frameworks. Using this information we will identify where any gaps can be identified and where additional information should be provided to capture these risks.

5.3.1 American standard: NIST 800-30 – Guide for conducting risk assessments – Information security (2011)

NIST 800-30 specifies the various types of risks in the following manner, it states that risk assessments can be conducted at all three levels in the risk management hierarchy. These levels are: the organisational level, mission/business level and information system level.

A number of examples of risk areas are provided per tier which can be related to the categories defined in the following way:

Risk Category NIST Motivation

Strategic Risk Yes NIST propagates an overall risk assessment on tier 1 (see chapter 5.2.1) organisational level (Chapter 2.2.1 – Risk assessments at the organisational tier) which includes strategic risks. At tier 1, risk assessments can affect for example, organisation wide information security programs, policies, procedures and guidance.

Environmental Risk Yes NIST identifies various threats which are related to environmental risks and are to be considered in the risk assessment (Table D2 – Appendix D).

Operational Risk Yes NIST considers operational risk on all three tiers (organisation, mission / business process and information systems).

Compliance Risk Yes NIST considers compliance to federal legislation, regulations, directives, policies, standards and guidance in tier 3 – Information systems.

NIST covers all of the specified Risk Categories, the comparison with penetration testing is performed in chapter Error! Reference source not found.7.



37

5.3.2 International standard: ISO/IEC TR 15443:2012 – Framework for IT security assurance

The ISO standard 15443:2012 does, unlike the other two frameworks discussed, not provide a full risk management framework. The ISO standard provides guidance on how to obtain assurance on IT Security. The standard refers to a number of other ISO frameworks which should be used to perform a full risk assessment and complete the risk management cycle. Therefore we will not complete the assessment of which risk categories are covered by the ISO standard in this thesis.

We have decided to investigate this particular framework to determine how positive IT security assurance can be provided. Even though penetration testing can only provide negative assurance, we did expect penetration testing to be covered.

5.3.3 International organisation: ISACA – Risk IT

ISACA provides a full risk management framework, starting from the governance level and leading to the risk evaluation and to the risk responses required.

All risk categories are identified in the section Risk Evaluation (section RE1-3). However the different categories of risks are handled in separate steps throughout the entire process. Below are the steps listed which provide more specific attention to each category.

Risk Category ISACA Motivation

Strategic Risk Yes ISACA specifies that strategic risks can be determined and identified in sections RG2.1 and RG2.2.

Environmental Risk Yes Methods to identify and classify environmental risks are stated in sections RE1 and RE2.

Operational Risk Yes Operational risks can be determined in the step RG2.2.

Compliance Risk Yes The compliance risks are identified in section RE1.1-4 and specifically verified and in RR1.2.

ISACA covers all of the specified Risk Categories, the comparison with penetration testing is performed in chapter 7.



38



39

6 Interview findings analysis To determine the need for additions to the IT risk management frameworks, we performed a number of interviews with Subject Matter Experts (SME’s) in the field of IT risk management and security testing (including penetration testing).

6.1 Approach

We interviewed several experts to ensure the subject is covered from different perspectives. We decided to interview employees on different levels within different organisations, from ‘operational’ to ‘upper management’.

The following persons were interviewed, due to possible confidentiality issues, the interviewees remain anonymous.

Name Occupation Sector Years of Experience

X1 PCD (Process Control Domain) Security Auditor

Energy & Natural Resources 6

X2 Incident Analyst Energy & Natural Resources 4

X3 Manager IT Advisory – Security IT Advisory 7

X4 Director IT Advisory - Security IT Advisory 23

The main focus of our interviews was to derive an overview of the position of penetration testing in various organisations and within their IT risk management process. In addition, we were interested in their experience with incidents which could have been prevented if a strict IT risk management process would have been adhered to.

The main interview questions were drafted as follows. These questions were used as a baseline. Depending on the information provided during the interview, we asked follow-up questions to obtain detailed information with regard to the various subjects. Paragraph 6.2 contains a summary of the interviews and the information obtained.

1. How is the IT risk management process designed within your organisation or other organisations you know of?

1.1. Which steps are included?

1.2. Are IT risk management frameworks used?

1.2.1. If yes, which?

1.2.2. Why these?

2. Is penetration testing a standard activity within the IT risk management process and why?

2.1. Where in the process is penetration testing supposed to be performed?



40

3. Is penetration testing included within the used IT risk management framework?

3.1. If no, why and how is this performed anyway?

Please note that the questions are highly dependent on the particular organisation and were only used as a baseline to ensure the overall subjects were covered.

We created interview notes of all of the interviews which were validated by the interviewees before including them in this thesis. A summary of the interviews and main conclusions are provided in the following subchapter.

6.2 Summary of interviews

Each interviewee provided feedback based upon his personal experience within the organisation/field of penetration testing and IT risk management. In this chapter a summary is provided with the main conclusions which were derived from the interviews.

Please note that the text in the following subchapters reflects the opinion of the interviewee.

6.2.1 X1 - PCD (Process Control Domain) Security Auditor

The interviewee is employed within the internal audit department and focuses on Process Control Domains (Industrial Automation) which are audited differently than regular IT environments.

The interviewee states that the risk management process is performed in three ways within his organisation.

- Self assurance: risks are being determined and classified by the departments themselves.

- A special organ that performs risk assessments. They also verify and advise on the performed self assessments.

- Internal/External audit: This group reviews the 2nd and 1st layers.

The interviewee states that his organisation is using a self developed risk framework, based on standard frameworks in the field. The reason they created their own framework is considering the fact that PCD is being audited differently than regular systems. The dangers that emerge during the audit need to be mitigated appropriately.

For instance, a failing valve can lead to large risks for human safety, penetration tests are usually not performed on production environments. Additionally, a penetration test can only be considered if the environment is sufficiently ‘mature’. The interviewee states that testing environments rarely exist within the PCD Domain. Some may exist, however not all vendors supply a proper testing system. Therefore it is crucial that the appropriate measures are taken into account prior to testing.

The interviewee mentions that penetration testing can only provide ‘negative assurance’. When a penetration test does not result in any findings, no assurance can be provided. A test is performed at a particular configuration at a specific moment in time and can never be ‘complete’. Also, the results are largely dependent on the allocated budget (time) and the skillset of the tester. The organisation for that reason mostly hires external staff to perform the



41

penetration tests as the internal employees lack the skillset or knowledge to perform the tests.

Penetration testing does provide an added value next to using IT risk management frameworks within an organisation. Due to the large risk for production environments within PCD environments, penetration tests should not be mandatory within this field but only be executed with due care.

6.2.2 X2 – Incident analyst

The interviewee is employed as an incident analyst and is confronted with IT related risks in his daily work. This way he/she can provide input from a different angle and provide examples of incidents which could have been prevented if the risks were identified at an early stage (e.g. by performing a penetration test).

Within the organisation of the interviewee, ‘Externally facing’ systems are frequently tested by performing vulnerability scans to identify possible risks. Reason for periodically retesting these systems is to find vulnerabilities that were not known at the time of the earlier test. The tests are performed to fin vulnerabilities in software, find configuration errors and to identify default passwords.

Two examples are provided of cases which show the importance of effective IT risk management:

A small external website was developed and commissioned within a very short timeframe. Due to urgency of delivery, no penetration test or vulnerability scan was performed. When the website went live, multiple incidents were raised due to an SQL-injection vulnerability which was actively exploited by adversaries.

A number of years ago, when the organisations risk management process was not adequate yet, an application was commissioned. This application changed ownership and more and more functionality was added over time. Due to these changes and the lack of a proper process, the vulnerabilities were never assessed, resulting in an incident.

These incidents might have been prevented by performing a penetration test and fixing the resulting findings.

Penetration testing cannot uncover ‘all’ risks, such as people copying or storing ‘most confidential’ data in public places. Therefore, penetration testing should be part of a larger process.

The interviewee mentions that penetration testing should be performed with care, sometimes a vulnerability scan may be sufficient to uncover most important risks. A penetration test cannot be performed in all occasions, a risk assessment should be performed.

A proper follow-up of the identified risks and vulnerabilities is very important and should not be accepted without analysis. The person analysing the risks should be capable for the job.



42

6.2.3 X3 - Manager IT Advisory – Security

The interviewee is employed as Manager IT Security within the advisory department of a large consulting firm. Within his daily work, he/she visits numerous organisations and is aware of their IT risk management processes and their need for penetration testing. As such, he/she is able to provide input from the view of different organisations.

The interviewee mentions IT risks are sometimes hard to assess on impact and likelihood within different layers within an organisation due to inadequate technical or business knowledge to translate the IT risk to the business risk.

Findings are often downplayed due to the financial cost of resolving them or the negative impact on the responsible employee.

As an example case, the interviewee mentions he/she saw in practice that risks were accepted by a business owner who did not have any insight in the relationship between various findings. A business owner usually does not have adequate security awareness to know if the identified risk is his responsibility resulting in the signoff of a risk waiver on inadequate information. Since the risk department only checks if there is any signoff, this will be sufficient to accept the risk.

Within organisations it is a common assumption that when a process is working appropriately, the operational effectiveness is also correct. For instance within change management procedures. In this process it is easy to verify whether the created tickets also have been executed, however this only tests the information that is known (the tickets), not the unknown changes (without a ticket). This could be resolved by logging all ongoing activities, however this is not easy to monitor due to the large amount of data.

To be able to determine whether any other changes have been implemented a configuration review can be performed. This allows the old and new situation to be compared and the changes to be validated. Also for some systems (firewalls for instance) a baseline verification can be performed, if the baseline differs from the current situation, a ticket should be available. If not, an unauthorised change has been performed. These solutions are within a small organisation however not very practical due to the large amount of work they require.

According to the interviewee systems can important from three different angles, namely: Confidentiality, Integrity and Availability.

Verifying the confidentiality of a system is hard to determine, it is important to have the logging and monitoring process set up right. Besides those, there are very few options of validating issues or risks. The integrity of systems can be determined by hashing and overall checksums. The availability is generally of least interest to attackers, if the system goes down, the attacker can not make any changes anymore either.

The interviewee describes the need for a process which regularly checks if the design and configuration of a system are adequate. Penetration testing and configuration reviews are a good way to assess the current state of the IT environment. It should be noted that penetration testing focuses on technical issues, where in most organisations manual controls are implemented which can mitigate the impact of a vulnerability.

The interviewee describes asset management to be one of the largest problems in risk



43

management as unknown systems cannot be subjected to proper risk management.

The interview provides an example from the field:

A copier broke down in the HR department of a large organisation. The employees called the supplier and ordered a new copier. This copier was delivered with the default configuration (DHCP enabled, scanned documents are shared with anyone) resulting in the sharing of all scanned documents on the network. As the HR department processes a large amount of privacy sensitive documents this resulted in a major incident. Since a new IP address was allocated to the device, it was unknown at the risk management department resulting in bypassing of the IT risk management process and other procedures.

Penetration testing can also be used to identify the internet presence of organisations. In practice, this usually leads to the identification of more systems than known by the organisation. There should be processes for applying for a website within the organisation which include risk management.

It should be noted that the culture within the organisation is very important. The interviewee describes an example from the field:

We performed a penetration test at a large international organisation. We had multiple critical findings which were reported to the client after which they were resolved. When we performed another penetration test a year later however, the same findings were identified. Asking for the reason for this, the interviewee was informed that a call was made from the Head Office to this branch stating that the services which were closed and settings which were changed had to be reset since specific functionality was required by the business.

IT risk management cannot function adequately if it is bypassed by the upper management.

The interviewee describes that in some organisations penetration testing has been executed by the IT managers themselves. These IT managers generally do not have any knowledge on how to efficiently and thoroughly perform these tests and simply use a vulnerability scanner with default settings. This would result in very little or no findings, which can lead them to believe their IT systems were secure.

The interviewee indicates penetration testing is an essential part of the IT risk management process to identify risks. Penetration testing is required more and more as part of ‘regulatory compliance’ where regulatory authorities indicate penetration testing should be performed mandatory (e.g. Digi-D and AFM). The need for penetration testing is often only recognised when incidents already have occurred.

The results can be used to increase security awareness within all layers within an organisation to clarify the impact of vulnerabilities. If performed regularly, penetration testing can help to obtain an overview of the progress made.

Due to this added value, it is important that penetration testing is incorporated within the IT risk management frameworks. This also ensures internal and external audit activities can focus hereon.



44

6.2.4 X4 - Director IT Advisory – Security

The interviewee is employed as Director IT Security within the advisory department of a large consulting firm. Within his daily work, he/she visits numerous organisations and is aware of their IT risk management processes and their need for penetration testing. As such, he/she is able to provide input from the view of different organisations.

The interviewee indicates that the penetration testing methodology used within his organisation has been developed based on practical experience.

The interviewee indicates there are two ways of performing IT risk management. On organisational level or at service level. On the organisational level the entire organisation is in scope and the focus lies on identifying risks and selecting mitigating controls. On service level the focus tends to lie more on verifying the specific services.

The question arises how to determine whether all the controls are sufficient throughout the entire organisation. Are all security measures sufficient, throughout the entire organisation? Penetration testing can in these cases be used to test the security of the entire scope of IT infrastructure.

Penetration testing can be used to test the security of a new application; either when the application is implemented or periodically. This could be dependent on the classification of the systems. An example is given of an organisation which requires a penetration test before going live on all business critical systems or systems handling “most confidential” data.

Penetration testing can be used as a control to perform Compliance based monitoring (vulnerability monitoring).

Additionally, penetration testing can be implemented on organisational level where a thematic approach can be used to identify generic issues within an organisation (such as identifying insecure Windows shares).

Compliance based audits can lead to a false sense of security if no penetration tests are performed. A compliance based audit can lead to a positive statement where penetration testing can lead to critical findings.

Risk management activities can be divided in three main groups, prevent (prevent risks), detect (detect risks) and response (response to risks). The interviewee states that there is currently too much focus on Control Selection (preventing risks), the focus should lie more on detective risks.

Penetration testing is not included in financial audit control frameworks (such as SOx), where it can be an added value to an organisation. Reviewing whether a hacker can access certain systems or functionality aids in identifying risks, which can be used to determine generic controls.

The interviewee expects an added focus on technical fact finding in the future, partly as part of mandatory regulatory compliance and increased exposure. Organisations understand that in order to answer the question if their organisation is vulnerable, regular penetration tests should be performed.



45

In a number of control frameworks, penetration testing is explicitly mentioned. As an example, the PCI DSS framework includes mandatory periodic penetration tests. It is also mentioned in the SANS top 20. These control frameworks pay more attention to specific controls and their specifications.

The interviewee would like more help with control selection within the IT risk management frameworks. This would help organisations with selecting the correct controls. As an example, penetration testing could be mentioned as a control to identify vulnerabilities.

6.3 Main conclusion

The following main conclusions can be derived from the performed interviews with interviewee X1, X2, X3 and X4:

Penetration testing can potentially be a risk itself (e.g. when performed on live critical environments such as Process Control Domains);

There are occasions where security incidents could have been prevented when a penetration test would have been performed (and identified issues would have been resolved) before IT-systems were commissioned;

The need for security testing/penetration testing is often only recognised when security incidents already have occurred;

Penetration testing is often mandatory as part of regulatory compliance in specific sectors;

Penetration testing or vulnerability scanning is an essential part of any IT risk management process;

Risk management frameworks do not provide sufficient support with selecting the appropriate controls;

Specific controls should be provided to facilitate penetration testing on a periodic basis;

Compliance based audits can lead to a false sense of security if no penetration tests are performed. A compliance based audit can lead to a positive statement where penetration testing can lead to critical findings.

These statements underline the need for penetration testing as part of the IT risk management process within organisations and as such the need for penetration testing to be included in IT risk management frameworks. Therefore, we recommend updating the IT risk frameworks to include penetration testing.

In the following chapter, we provide our suggestions for updating the IT risk frameworks.



46



47

7 Analysis and recommendations

7.1 Positioning of penetration testing in IT Risk Frameworks

This thesis revolves around penetration testing and how this is incorporated within risk frameworks. In this section we will analyse the information described in chapter 4 (Security testing) and chapter 5 (IT risk management) to determine the exact place penetration testing holds in each framework. We will investigate whether it is mentioned at all. If not, we will provide indicators where we would expect the penetration testing activities to be mentioned.

The interview findings show, penetration testing can be a part of the security monitoring processes within an organisation which consists of three parts: compliance monitoring, vulnerability identification and incident detection.

Figure 13: Security Testing in an organisation

As a part of security monitoring, penetration testing helps identify security weaknesses and to mitigate or consciously accept the security risks. These activities can be identified in the following steps:

Implementing controls, for new or changing applications and IT infrastructure.

Compliance testing of the operational IT services.

Incident intelligence validation, answering the question of specific security issues apply to the organisation and how incidents should be responded to.



48

Vulnerability verification, answering the question if the noted issue is a relevant risk to the organisation.

We will investigate whether the frameworks identified in chapter 5 contain the appropriate reference to penetration testing . We will use the steps described by interviewee X4 (paragraph 6.2.4) to locate and map the information in the frameworks to the appropriate penetration testing activities.

7.1.1 NIST 800-30 – Guide for conducting risk assessments – Information security (2011)

In the NIST guide there are no references of penetration testing during the risk management cycle. However it does state in the following citation that the guide can in fact be used by penetration testers, even though it does not provide any specific details on how or what should be done or used by penetration testers.

“This publication is intended to serve a diverse group of risk management professionals including:

Individuals with information security/risk assessment and monitoring responsibilities (e.g., system evaluators, penetration testers, security control assessors, risk assessors, independent verifiers/validators, inspectors general, auditors).” [18]

Even though NIST does not mention penetration testing specifically, the steps described in the risk assessment process do align with the steps where penetration testing adds value (control selection, compliance testing, incident intelligence and vulnerability verification).

Therefore considering the added value penetration testing could provide, we would expect penetration testing to be included in the following sections.

Security Control Selection

Risk assessments can help organisations select appropriate controls, apply appropriate tailoring guidance to adjust the controls and supplement controls based on credible threat information.

Security Control Implementation

Organisations can use the results from initial risk assessments to determine the most effective implementation of selected security controls. Updated risk assessments can be used to help determine if current security control deployments remain effective given changes to the threat space over time.

Security Control Assessments

Organisations can use the results from security control assessments (documented in security assessment reports) to identify any residual vulnerabilities in organisational information systems and/or the environments in which those systems operate.

Security Control Monitoring



49

Organisations can update risk assessments on an ongoing basis by monitoring at an organisation-defined frequency: the effectiveness of security controls; changes to information systems and environments of operation; and compliance to federal legislation, regulations, directives, policies, standards, and guidance.

7.1.2 ISO/IEC TR 15443:2012 – Framework for IT security assurance

The ISO / IEC TR 15443:2012 framework specifically describes penetration testing as a criteria for assessing the aspects of the Security Assurance Conformance Assessment method (SACA method). The place where penetration testing can be used as a part of the criteria is in the “continuous operational monitoring” section. However this particular section does not provide any details on how to perform a penetration test or the actual purpose of a penetration test.

The SACA method is a systematic process, procedure or technique for obtaining security assurance evidence and consistently verifying security assurance claims.

Part of this method is to verify the results of the SACA analysis using a specific clause. This clause describes criteria for assessing aspects of the results of a SACA method.

A part of this clause is the ‘Operational Considerations’. The framework states that assurance can be provided in the ‘development-phase’, or at some ‘snapshot’ point, the assurance provided by such methods can only be apparent if certain operational or environmental considerations are put in place. One of the criteria to test this assurance is to verify whether the method or associated policies include requirements for continuous monitoring.

Penetration testing can be part of this continuous monitoring. To meet the criteria, evidence that such testing takes place and the results from the tests will need to be recorded appropriately. (Section 10.8 book 2). [13]

Also in section 7.2 Selecting Security Assurance Techniques the techniques are determined how to obtain correctness assurance. To obtain this correctness assurance, a penetration test can be performed. The technique of performing a penetration test can be added specifically in this section. According to ISO 15443 the security assurance techniques applicable to products can be found in ISO/IEC 19790. However this framework does not make any specific note to use penetration testing or how to perform a penetration test even though this would be expected (as part of negative assurance).

7.1.3 ISACA – Risk IT

The ISACA – Risk IT guide does not mention penetration testing during the risk process model. We would expect these activities to be mentioned or referenced in the Risk analysis or Control testing phases. Based on the results with interviewee X4, previous experience and research, it can be concluded that these activities can take place in the following process steps:

1 RE2: Analyse Risk

In the Analyse Risk step of the framework the sub step: RE2.2 Estimate IT risk to and from critical products, services, processes and IT resources can be identified. In this step the risks are analysed and classified for critical products, services, processes and IT resources.



50

In this step Penetration testing could provide value to help classifying the risks.

2 RR2: Manage IT Risk

In the Manage IT Risk step of the framework the sub step: RR2.2 Monitor operational alignment with risk tolerance thresholds can be identified. In this step the risks are monitored by monitoring the control performance and the key operating effectiveness.

In this step penetration testing could aid in the testing of control performance and the operating effectiveness.

7.1.4 Summary of risk categories

In this chapter the identified differences in IT risk categories are described and an answer to subquestion 3 will be provided:

How do the risk categories identified by penetration testing differ from risks identified by using an IT risk framework?

Based upon paragraph 0 and chapter 5, the following table can be created:

Risk Category Covered by penetration testing

Covered by IT risk frameworks

Strategic Risk No Yes

Environmental Risk No Yes

Operational Risk Yes Yes

Compliance Risk Yes Yes

Table 2: IT Risk categories

As is displayed in Table 2: IT Risk categories both the Operational and Compliance risks are covered by penetration testing and IT risk frameworks. Penetration testing can thus be used to help identify specific risks for these categories only.

Based upon the tables above, we can conclude that penetration testing can play a role in the IT risk categories related to ‘Operational risk’ and ‘Compliance risk’. The other risk categories can be covered using different methods which are outside of the scope of this research.

We noted that penetration testing is mentioned only generally in the IT risk frameworks or not at all and as such can conclude that penetration testing is under-exposed within the risk frameworks even though it could uncover important risks related to the IT environment. Additionally, the impact of vulnerabilities and weaknesses can be assessed to obtain a better overview of the current state of security and the risk level of the organisation.

Therefore, we feel that the IT risk frameworks should be updated to at least mention the existence of penetration testing and providing some background on the risks which can



51

potentially be uncovered and assessed using penetration testing. Our suggestions are provided in the next chapter.



52

7.2 Recommendations

7.2.1 Suggestions for updates to the IT Risk Frameworks

We noted that IT risk frameworks put little to no focus on penetration testing. Since these frameworks are actively used, we propose to update these frameworks with specific sections regarding penetration testing, in order to increase the focus on these activities.

In order to improve the various frameworks with more information regarding penetration testing, we will base our suggestions on the generic methodology as identified in paragraph 4.4, including the steps Scanning, Mapping and Exploiting.

In this chapter, we will provide suggestions for updates to the IT risk frameworks. In particular, subquestion four will be answered:

How can the risks which are solely identified by performing a penetration test be covered and incorporated in the IT risk management frameworks?

By adding the proposed new sections to the IT risk frameworks, the frameworks will put more emphasis on penetration testing , its use and methods. This will greatly increase the chances of uncovering the IT-related risks which are typically identified by penetration testing. As a result, the overall security of IT-systems and organisations can be increased.

7.2.2 NIST 800-30 – Guide for conducting risk assessments – Information security (2011)

Based on the investigations performed in chapter Error! Reference source not found.5. we concluded that the NIST framework provides guidance on when to perform penetration testing in the risk management cycle. However, it does not provide any guidance on how to perform penetration testing itself.

Mapping

Chapter: 3.1 - Preparing for the Risk Assessment, Task 1-2 Identify the scope of the Risk Assessment (page 20)

In this chapter the scope of the risk assessment is determined. This scope is prone to risk analysis and also most likely to penetration testing. Therefore the outcome of this particular section can be used as input for the Mapping phase within the penetration testing approach. Using this information the next penetration testing steps can be executed, which are displayed below.

As such, we do not deem it necessary to add additional text for this phase.

Scanning



53

Chapter: 3.2 – Conducting the risk assessment, Task 2-3 Identify vulnerabilities and predisposing conditions that affect the likelihood that threat events of concern result in adverse impacts to the organisation (page 27)

After the second paragraph (..the space of potential risks to be assessed.), on page 27 we propose the following text to be added:

An important part of the identification of Vulnerabilities is to perform a penetration test. In order to start the penetration test the scope identified in section 3.1 (task 1-2) can be used. The second step of the testing is to start the scanning. 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 to be performed automatically or manually.

Exploiting

Chapter: 3.2 – Conducting the risk assessment, Task 2-4 Determine the likelihood that threat events of concern result in adverse impacts to the organisation, considering: (1) 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 (page 28)

After the fourth paragraph (... similar rationale for the assessment.) , on page 28 we propose the following section to be added:

The identified vulnerabilities can be assessed by penetration testing in the next step: exploiting. Exploiting is focused on exploiting 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.

7.2.3 ISO/IEC TR 15443:2012 – Framework for IT security assurance

Based on the investigations performed in chapter 5 we conclude that the ISO – TR15443 framework does not provide guidance on when in the risk management cycle to perform penetration testing.

In section ‘7.2 Selecting Security Assurance Techniques’ the techniques are determined how to obtain correctness assurance. Please note that penetration testing can only be used to provide negative assurance. A penetration test which does not result in negative findings cannot be used to provide positive assurance. However, since negative assurance can be beneficial for the overall security of an organisation, the technique of performing a penetration test can be added specifically in this section.

We propose to add the following text to section ‘7.2 Selecting Security Assurance Techniques’ right above section 7.2.1 on page 25 in ISO15443:2012-1:



54

Penetration Testing

Please note that penetration testing can only be used to provide negative assurance. A penetration test which does not result in negative findings cannot be used to provide positive assurance. However, since negative assurance can be beneficial for the overall security of an organisation, the technique of performing a penetration test is mentioned within this section.

The penetration test generally consists of three steps, Mapping, Scanning and Exploiting.

The step Mapping is the identification of systems and applications of the IT environment in scope of the penetration testing engagement. The identified services and applications are discussed with the client to determine if the scope is correct and if additional scanning and testing should be performed.

Thereafter the step Scanning can occur. 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 automatically and manually.

Finally the Exploiting step is started. The identified vulnerabilities can be assessed by penetration testing in the next step, exploiting. Exploiting is focused on exploiting 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.

In addition, we recommend to include the following text in section ’10.8.2 – Operational considerations – Criteria’ on page 18 in ISO15443:2012-2:

Penetration testing is a means that can be used to test controls for effectiveness for IT systems and networks. In section 7.2 a description what steps are required to perform a penetration test is available.

7.2.4 ISACA – Risk IT

Based on the investigations performed in chapter 5 we conclude that the ISACA – Risk IT framework does not provide guidance on when in the Risk Management cycle to perform penetration testing.

In section ‘RE2.1 - Define the IT Risk analysis scope’ the scope is determined for which a penetration test can be performed. Therefore the outcome of this particular section can be used as input for the Mapping phase within the penetration testing approach. Using this information the next penetration testing steps can be executed, which are provided below.

We propose to add the following text in chapter ‘RE2.2 – Estimate IT risk’ right above the table:



55

Penetration Testing

In section ‘RE2.2 - Estimate IT Risk’ the risks can be determined for the IT systems defined in the scope of RE2.1. In order to aid in determining these risks it is beneficial to perform a penetration test.

The penetration test generally consists of three steps, Mapping, Scanning and

Exploiting.

The step Mapping is, as mentioned earlier, already performed in section RE2.1.

Thereafter the step Scanning can occur. Scanning concerns the identification of services and known weaknesses on systems and applications which are vulnerable for exploiting. Depending on the engagement, scanning is performed automatically or manually.

Finally the Exploiting step is started which concerns the assessment of the identified vulnerabilities. Exploiting is focused on exploiting 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.

Another section where penetration testing could be useful is in section ‘RR2 Manage IT Risk, RR2.2 Monitor Operational alignment with Risk Tolerance thresholds’ on page 86. In this section it is described that the selected controls are to be tested for effectiveness. Penetration testing can be used to aid in this testing.

We suggest to add the following text in chapter ‘RR2.2 – Monitor operational alignment with risk tolerance thresholds’ right above the table:

Penetration testing is a means that can be used to test controls for effectiveness for IT systems and networks. In Section RE2.2 a description what steps are required to perform a penetration test is available.



56



57

8 Research questions revisited In this chapter, we will provide a summary of the answers to our initial research questions in order to provide the reader with an overall overview of the results of our research and study.

8.1 Conclusion

In this thesis the place penetration testing holds in IT risk management frameworks has been identified. The need for penetration testing was concluded in several interviews with experts on both IT risk management and penetration testing.

When examining the various IT risk frameworks, it appeared that the place penetration testing holds is very limited or not incorporated at all. Based on the interviews and the performed research, we developed suggestions for improvement to increase the position of penetration testing within the IT risk management frameworks.

For each IT risk framework we determined where penetration testing activities should take place and how these should be described. The recommendations were provided based upon the analysed penetration testing methodologies. We noted that each penetration testing methodology basically consists of three steps: Mapping, Scanning and Exploiting. Each of these steps were mapped to a specific section in the IT risk frameworks and a general description was provided.

As a result, we would like to propose our additions to the researched IT risk frameworks to the respective entities (NIST, ISACA and ISO) to further increase the completeness and effectiveness of IT risk management.

The summary of the answers to our main and sub research questions is provided in chapter 89.The text we propose to incorporate in the IT risk frameworks is intentionally quite generic to refrain from providing too much detail. However, dependent on the community, more specific information regarding penetration testing can be incorporated within the IT risk frameworks. These specifics would provide the reader with more information on how to perform penetration tests. Please note that the technology is changing so rapidly that it is almost impossible to keep the framework up to date.

What we can conclude from the performed research is that IT risk management is a changing field. What was considered very important in 1992, natural disasters, has now become less critical. New challenges continuously arise and so do the overall processes.

In various client cases we have experienced there is a discrepancy between IT risks and business risks. The identified IT risks are difficult to translate to business risks. Therefore it is difficult for the risk managers to put the IT risks on the agenda for the CEO. Causing them to obtain less budget than required or the company putting effort and resources in the ‘wrong’ risks.

What we have also noted is that the risk management processes are becoming more and more standardised and are obtaining more focus each year. Various ITGRC tools, for instance RSA’s Archer, are now being implemented. These tools help structure the IT risk management processes, align and organise data across the entire organisation and help leadership put focus on the areas that are relevant.



58

8.2 Research questions

Our main research question was defined as:


The four sub questions we defined are answered in the sections below.

1. What is penetration testing, what various types of activities does it include and which IT risk categories can be identified?

A penetration test is an activity which can be performed as part of security testing. It is a method of identifying weaknesses and vulnerabilities in a computer system or network by simulating an attack from the view of a malicious person. This can be either a malicious outsider (e.g. a hacker) or insider (e.g. a disgruntled employee).

Penetration testing can be performed in multiple ways. The main differentiating factor is the amount of information which is being shared with the penetration tester prior to performing the penetration test. The various means of testing are: White box, grey box and black box. In a white box test the penetration tester is informed all details of the IT infrastructure such as configuration settings and source code of applications (simulating a malicious insider). In a black box test the penetration tester is only provided the scope of the test, but no further details (simulating a hacker). A grey box test is usually performed with application accounts to identify the effectiveness of the segregation of duties and to determine if users with specific access rights are able to perform malicious actions.

A penetration test can never provide positive assurance with regard to the security of an environment. If no vulnerabilities or weaknesses are identified, it does not mean that they do not exist. This is due to a time-boxed approach which is largely dependent on the skillset of the assessor.

Most companies follow a penetration testing method to ensure the test is performed as efficient and complete as possible. Multiple methods have been developed over the years. We noted that the method should be selected carefully, as not all methods we analysed were complete and thorough.

Overall the penetration testing activities consist of the following three steps:

Mapping: identifying the systems and applications within the IT environment in scope of the penetration testing engagement.

Scanning: the identification of services and known weaknesses on systems and applications that are likely to be vulnerable for exploiting.

Exploiting: focuses on exploiting identified vulnerabilities, or determining how difficult it would be to actually do so.



59

The outcome of these steps would lead to a report which can be used to help determine vulnerabilities in computer systems or networks. Which could in itself lead to(mitigating) actions to be performed.

Penetration testing can only identify risks related to Operational and Compliance risk categories. Other risk categories, for instance Strategic risks or Environmental risks cannot be determined by penetration testing since only IT related risks are considered.

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?

Risk management is the identification, assessment, and prioritisation of risks 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. Risk management frameworks are frameworks that provide a disciplined and structured process that integrates information security and risk management activities into the system development life cycle. Risk management frameworks describe various steps to perform the process, however in general the following main steps can be identified:

Risk identification: allows organisations to determine the potential impact of internal and external threats on the entire IT environment.

Risk Analysis: the identified risks from step 1 are assessed. Risk reducing measures: implementing measures to reduce the IT risks. Risk monitoring: Actively verifying and monitoring whether the measures have been

implemented appropriately. It serves as an ongoing audit function.

During our study we have identified and used three IT Risk frameworks which are commonly used in practice. These frameworks are:

American standard: N IST 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

ISO/IEC TR 15443 is a multi-part 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).

ISACA – Risk IT



60

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 a similarly thorough treatment of risk management, from the tone and culture at the top, to operational issues.

The identified risk frameworks cover the majority of the used risk categories. Market risk and Credit risk are excluded considering we have concluded they are not affected directly (merely indirectly) by IT. The other categories, Strategic, Operational, Compliance and Environmental are covered.

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. Security testing activities and guidelines are generally covered in security frameworks such as NIST 800-115 and ISO 27001.

The term security framework has been used in a variety of ways, but it has become an aggregate term for the various documents and associated programs for a variety of 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.

IT Security testing 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.

Figure 14: Security testing hierarchy

In the various used risk frameworks, the use of penetration testing is barely covered. In some frameworks it was briefly mentioned as a possible option, but not as a mandatory step.

3. How do the risk categories identified by penetration testing differ from risks identified by using an IT risk management framework in practice?

Risk management frameworks provide a good overall picture of all possible risks within an organisation. The frameworks cover four out of the six identified risk categories, where penetration testing alone only covers the Operational and Compliance risks. Penetration testing



61

however is a valuable asset to the organisations and also the frameworks due to the specificity of the risks which can be identified. It provides a clear insight in the objectives of an attacker and the possible vulnerabilities within the IT infrastructure.

Penetration testing provides additional information for the risk manager, which can be used to reduce the amount of risk an organisation faces. Based on various interviews with SMEs in the field, we conclude that penetration is of an added value. Various cases were provided where penetration testing could have aided the risk management process. They provide examples of cases where penetration testing could have prevented incidents from occurring, and can provide information to aid in selecting appropriate controls for an asset.

Even though penetration testing cannot in fact identify risks in categories the risk frameworks miss, we still believe penetration testing adds large value.

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?

To ensure that the risks which are being missed by following only the risk frameworks, but can be found by penetration testing, are also taken into account in the risk management cycle, it is important to add penetration testing to the existing risk frameworks.

Based on the performed SME interviews, the necessity is shown to performing regular penetration testing in organizations in addition to using risk management frameworks.

Therefore we suggest to specifically include the use of penetration testing within the various risk frameworks. We also suggest to elaborate on how to perform these tests in generic terms. Information on what steps need to be taken will aid the risk manager in creating/following an improved risk management process. Detailed specifics on penetration testing will not add value, considering the speed in which the field is continuously changing. The framework would require too frequent updating (almost on a daily basis) to be able to incorporate detailed penetration testing descriptions.

Based on the answers to the various sub-questions we have now answered our main research question And provided recommendations to improve the frameworks.

In this thesis the place penetration testing holds in IT risk management frameworks has been identified. Based on various interviews with SMEs, the need for penetration testing has been concluded. Penetration testing can aid the risk management frameworks in identifying risks which can harm an organisation.

Based on the performed interviews and research, we developed and provided suggestions for improvements to the IT risk frameworks to increase the positioning of penetration testing. We have identified at which location the penetration testing activities should be included in each IT risk framework and how these activities should be described (considering the mapping, scanning and exploiting phase). We then provided specific recommendations based on the analysed penetration testing methodologies.




62

As a result, we would like to propose our additions to the researched IT risk frameworks to the respective entities (NIST, ISACA and ISO) to further increase the completeness and effectiveness of IT risk management.



63

9 Bibliography

[1] NIST, “National Institute of Standards and Technology Special Publication 800-115,” 2008.

[2] IsecT LTD, “Information Security Frameworks from Audit to Zachman,” 2011.

[3] D. A. U. Press, “Systems Engineering Fundamentals,” Fort Belvoir, Virginia, 2001.

[4] Bankersonline, “Riskmanagement Strategy,” [Online]. Available: www.bankersonline.com/tools/riskmgt_strategicrisk.doc.

[5] WiseGeek, “What is environment Risk Management,” [Online]. Available: http://www.wisegeek.org/what-is-environmental-risk-management.htm.

[6] McKinsey & Company, “Managing Market Risk: Today and tomorrow,” 2012.

[7] Wikipedia, “Credit risk,” [Online]. Available: http://en.wikipedia.org/wiki/Credit_risk.

[8] BASEL II, “Basel II: International Convergence of Capital Measurement and Capital Standards: A Revised Framework,” 2005.

[9] “Bankersonline Risk Management Compliance,” [Online]. Available: www.bankersonline.com/tools/riskmgt_compliancerisk.doc.

[10] KPMG, “Security testing Methodology, Tools and Resource,” 2011.

[11] SERSC, “Methodology for Penetration Testing,” International Journal of of Grid and Distributed Computing , vol. 2, no. 2, 2009.

[12] SANS Institute, “Conducting a Penetration Test on an Organization,” 2002.

[13] ISO/IEC, “Information Technology - Security techniques - Security assurance framework,” ISO/IEC, 2012.

[14] ISACA, “Risk IT,” 2009.

[15] OWASP, [Online]. Available: http://www.owasp.org/index.php/Testing:_Introduction_and_objectives. [Accessed 18 March 2013].

[16] De Nederlandsche Bank, “Thema's DNB toezicht 2013,” DNB, 2013. [Online]. Available: http://www.dnb.nl/binaires/thema dnb toezicht 2013_tcm46-284483.pdf.

[17] NIST, “Risk Management guide for Information Technology Systems - 800-30,” National Institute of Standards and Technology, 2002.

[18] K. Bandyopadhyay, P. P. Mykytyn and K. Mykytyn, “A framework for integrated risk management in information technology,” MCB University Press, 1999.

[19] N. Peterman, “Threat modeling of Enterprise Content Management Systems,” Vrije Universiteit, Amsterdam, 2009.

[20] K. Loch, H. Carr and M. Warkentin, “Threats to information systems: today's reality, yesterday's understandings.,” MIS Quarterly, 1992.

[21] National Institute of Standards and Technology, “Guide for conducting Risk Assessments,” NIST, 2011.

[22] B. Schneier, “Bruce Schneier,” 7 August 2008. [Online]. Available: http://www.schneier.com/blog/archives/2007/08/assurance.html.



64

[23] International Standard (ISO 31000), ISO 31000.

[24] J. Emblemsvag and L. E. Kjolstad, “Strategic Risk Analysis - a field version,” Emarald, 2002.

[25] M. v. Veen and M. Smeets, “The added value of IT security testing for IT Auditing,” Rotterdam, 2009.

[26] Wikipedia, “ISO/IEC 27005,” [Online]. Available: http://en.wikipedia.org/wiki/ISO/IEC_27005.

9.1 List of Figures Figure 1: Security testing hierarchy .............................................................................................. 1 Figure 2: IT risk categories ........................................................................................................... 2 Figure 3: IT risks in the overall landscape .................................................................................... 3 Figure 4: Place of penetration testing in the full picture ............................................................. 98 Figure 5: Penetration Testing Phases ...................................................................................... 1211 Figure 6: SERSC Penetration Testing Method ....................................................................... 1413 Figure 7: NIST: Penetration Testing method .......................................................................... 1817 Figure 8: Risk Management Cycle .......................................................................................... 2321 Figure 9: NIST Risk Management cycle ................................................................................. 2725 Figure 10: Risk Management Hierarchy ................................................................................. 2826 Figure 11: ISACA Risk IT Risk Management cycle ............................................................... 3028 Figure 12: The relationship between security in the deliverable and security assurance ........ 3331 Figure 13: Security Testing in an organisation ....................................................................... 4743 Figure 14: Security testing hierarchy ...................................................................................... 6055 Figure 15: ISACA Risk IT Framework ................................................................................... 6560



65

A Appendix A

A.1 ISACA Risk IT

The risk management process as described in the ISACA – Risk IT is displayed in the graph below.

Figure 15: ISACA Risk IT Framework

In the process number of main steps can be identified, with each their own tasks and sub steps. In the following section we will provide a summary of these tasks and steps according to the model displayed above.

In this thesis we will only focus on the steps where Risks are identified and classified. These activities are found in steps 5 and 8 since in these steps risks are analysed and managed. In both steps we would consider security testing as an asset to improve identification and establish the impact of risks. Considering these steps are in scope for this thesis, we will provide more information on these activities in the summary below.

3. RG1 Establish and Maintain a Common Risk View

3.1. RG1.1 Develop an enterprise-specific IT risk management framework



66

3.2. RG1.2 Develop IT risk management methods.

3.3. RG1.3 Perform an enterprise wide IT risk assessment

3.4. RG1.4 Propose IT risk tolerance thresholds.

3.5. RG1.5 Approve IT risk tolerance.

3.6. RG1.6 Align policy and standards statements with IT risk tolerance.

3.7. RG1.7 Promote an IT risk-aware culture.

3.8. RG1.8 Promote effective communication of IT risk.

4. RG2 Integrate with ERM

4.1. RG2.1 Establish enterprise wide accountability for managing IT risk.

4.2. RG2.2 Establish accountability for IT risk issues.

4.3. RG2.3 Co-ordinate IT risk strategy and business risk strategy

4.4. RG2.4 Adapt IT risk management practices to organisational risk management practices

4.5. RG2.5 Provide adequate resources for IT risk management.

5. RG3 Make Risk-aware Business Decisions

5.1. RG3.1 Gain management buy-in for the risk analysis approach

5.2. RG3.2 Approve IT risk analysis results.

5.3. RG3.3 Embed IT risk considerations in strategic business decision making

5.4. RG3.4 Accept IT risk

5.5. RG3.5 Prioritise IT risk response activities

5.6. RG3.6 Track key IT risk decisions.

6. RE1 Collect Data

6.1. RE1.1 Establish and maintain a model for data collection

6.2. RE1.2 Collect data on the external environment

6.3. RE1.3 Collect timely event, incident, problem and loss data

6.4. RE1.4 Identify risk factors

6.5. RE1.5 Organise historical IT risk data

7. RE2 Analyse Risk

7.1. 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. Set the final



67

risk analysis scope after a final consideration of the criticality of assets, costs to analyse and potential overarching regulatory requirements.

7.2. 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. Estimate the maximum amount of damage that could be suffered (e.g. a worst-case loss when specific risk factors converge).

7.3. RE2.3 Identify risk response options

Examine the range of possible responses to the risk: accept, exploit, mitigate, transfer or avoid.

7.4. 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.

8. RE3 Maintain Risk Profile

8.1. RE3.1 Map IT resources to business processes.

8.2. RE3.2 Determine the business criticality of IT resources

8.3. RE3.3 Understand IT capabilities.

8.4. RE3.4 Connect threat types and business impact categories

8.5. RE3.5 Maintain the IT risk register

8.6. RE3.6 Design and communicate IT risk indicators

9. RR1 Articulate Risk

9.1. RR1.1 Report IT risk analysis results

9.2. RR1.2 Report IT risk management activities and state of compliance

9.3. RR1.3 Interpret external IT assessment findings

9.4. RR1.4 Identify IT-related opportunities

10. RR2 Manage IT Risk

10.1. 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.

10.2. RR2.2 Monitor operational alignment with risk tolerance thresholds



68

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

10.3. 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.

10.4. 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.

10.5. 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.

11. RR3 React to Events

11.1. RR3.1 Maintain incident response plans

11.2. RR3.2 Monitor IT risk

11.3. RR3.3 Initiate incident response plans

11.4. RR3.4 Conduct post-mortem reviews of IT-related incidents



69

Date post:	26-Feb-2019
Category:	Documents
Upload:	hacong
View:	220 times
Download:	0 times

Positioning of Penetration Testing and IT Risk Management ... · Testing and IT Risk Management...

Documents