Positioning of Penetration Testing and IT Risk Management Frameworks investigated

Transcription

1 Positioning of Penetration Testing and IT Risk Management Frameworks investigated Scriptienummer 1090

2 If you don t invest in risk management, it doesn t matter what business you re in, it s a risky business Gary Cohn i

3 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, ii

4 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. iii

5 Contents 1 Preface ii 2 Abstract iii 3 Introduction Research question Approach Scoping 5 4 Penetration testing and security management Introduction Penetration testing How is penetration testing performed? What are the limitations? Penetration testing methods KPMG security testing method SERSC penetration testing method SANS penetration testing method NIST penetration testing method Comparison IT Risk Management Introduction A framework for integrated risk management in IT Conclusion IT Risk Frameworks American standard: NIST Guide for conducting risk assessments Information security (2011): International organisation: ISACA Risk IT International standard: ISO/IEC TR 15443:2012 Framework for IT security assurance Risk Categories in frameworks American standard: NIST Guide for conducting risk assessments Information security (2011) International standard: ISO/IEC TR 15443:2012 Framework for IT security assurance International organisation: ISACA Risk IT Interview findings analysis: Approach 3936 iv

6 6.2 Summary of interviews X1 - PCD (Process Control Domain) Security Auditor X2 Incident analyst X3 - Manager IT Advisory Security X4 - Director IT Advisory Security Main conclusion Conclusions and recommendations Conclusion Positioning of penetration testing in IT Risk Frameworks NIST Guide for conducting risk assessments Information security (2011) ISO/IEC TR 15443:2012 Framework for IT security assurance ISACA Risk IT Summary of risk categories Recommendations Suggestions for updates to the IT Risk Frameworks Suggestions for improvement Error! Bookmark not defined NIST Guide for conducting risk assessments Information security (2011) ISO/IEC TR 15443:2012 Framework for IT security assurance ISACA Risk IT Research questions revisited Bibliography List of Figures 6458 v

7 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 [1] and ISO 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 1

8 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] 2

9 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 3

10 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 , 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 4

11 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 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 [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 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 The research questions are revisited in Chapter 89 and a bibliography and list of figures is included in Chapter 910. Appendix A 5

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

13 7

14 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] 8

15 Note that in the definition above, the word method indicates there are multiple ways to perform a penetration test. The main purpose of a penetration test is to identify and report on weaknesses and vulnerabilities in IT-systems. A penetration tester (a person performing a penetration test) is required to describe the risk and impact of exploiting these vulnerabilities, to allow management to make an educated decision on how to deal with the identified risks (e.g. mitigate or accept the risk). It must be noted that a penetration test without any findings does not guarantee that the system is 100% secure. It is no more than a snapshot of a system s security at a single moment in time. However, it serves as a method to perform risk analysis and control testing. Penetration testing is considered as a subset of security testing. Figure 4Figure 4 shows the place penetration testing upholds in the full picture of security testing. Figure 4: Place of penetration testing in the full picture Other than for the purpose of risk management, penetration tests often are required from a legal perspective. An example is the Data Security Standard drafted by the Payment Card Industry (PCI DSS) requiring vendors to perform a periodic penetration test of the environment dealing with credit card data. We see that penetration tests are also performed to increase the awareness of upper management for security issues (to increase budget) or to test the intrusion detection and response capabilities of departments within the organisation 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 9

16 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 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 , 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] 10

17 3. SANS Institute [12] 4. NIST [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 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. 11

18 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. 12

19 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 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: 13

20 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 nontechnical 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. 14

21 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 15

22 confidentiality within the contract to define measures to be taken when confidentiality is compromised 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 16

23 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 NIST penetration testing method NIST 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: 17

24 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 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. 18

25 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 and analysis gathering Discovery Phase 2 Scanning Information gathering Information and analysis gathering 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); 19

26 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. 20

27 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. 21

28 5 IT Risk Management 5.1 Introduction Risk management is the identification, assessment, and prioritisation of risks (defined in ISO 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 [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 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. 22

29 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. 23

30 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. 24