Most people who have worked in a security and risk management environment will understand that keeping up to date with tools, techniques and skills is as much a part of a job in the IT industry as actually doing the job! In the very specific yet evolving world of penetration testing – a method for assessing and managing risk by thinking and acting like an attacker to ‘penetrate’ a web application, system or network – the various attack vectors (routes in) and vulnerabilities change constantly, and it can be a daunting challenge for security teams and IT managers to maintain a constant state of protection. There are a multitude of reasons why an organisation will penetration test and it has become part of the quality assurance process. Done correctly and for the right reasons, penetration testing can be considered one of the most effective ways of identifying and plugging gaps. Imagine securing your home for instance: we spend time and money on ensuring intruders can’t break into our house, with locks on our windows and doors, alarms and intrusion detection systems. However, seldom do we hire an ethical ‘burglar’ to try to test that by going as far as they can to break in. With that in mind, a good penetration test can exploit weaknesses within an organisation that go beyond what a routine vulnerability scan may produce, such as seeking to exploit weaknesses in employee security awareness or, more commonly, to expose weaknesses in software systems.
This chapter will delve into some of the core concepts surrounding what effective penetration testing looks like and how it is deployed, while demystifying some of the nuances and key differences between terms such as ‘vulnerability testing’ and ‘Red Team testing’.
UNDERSTANDING WHAT PENETRATION TESTING WILL ACHIEVE
Penetration testing is, in effect, a kind of risk discovery and management tool. It is a way of testing the stability and security of IT systems against attacks perpetrated by computer hackers.
Typically, penetration testing employs a series of manual and automated techniques to simulate an attack. The tester attempts to gain access to a network, acting as if no such access has been authorised. Effective testing attacks through several system entry routes or ‘attack vectors’, often simultaneously.
Penetration tests attempt to find and exploit system vulnerabilities, and to discover weaknesses within IT systems which may derive from poor or improper system configuration, hardware or software flaws, or operational weaknesses. Penetration tests should be run against all external-facing connections and applications.
Testing is usually carried out from the position of a potential real-world threat actor, and it considers what they may hope to achieve in breaching a system.
A threat actor is a malicious hacker with the intent and capabilities to find weaknesses in systems and networks for the purpose of gaining unauthorised access.
While many large companies in sectors such as defence and finance will conduct penetration testing internally, for most, penetration testing is conducted by an independent, qualified (by CREST for instance) penetration testing expert instructed with a carefully considered ‘Scope of Works’ (the Scope) and often using a scientifically based, repeatable approach (CREST, 2017). Many firms provide this service. Their testers will deploy exactly the same tools as their nefarious counterparts, to make the test as realistic as possible. Only this approach can test how far actual hackers are able to penetrate networks and systems.
Tools for the job
Well-funded state-sponsored or government hackers might develop their own exploits (for example, as exposed by WikiLeaks with the release of CIA hacking tools1). This is expensive and time-consuming, and serves to only benefit the government which builds them. These exploits are designed to penetrate serious vulnerabilities not known (or disclosed) to manufacturers and are known as ‘Zero Day’ (sometimes termed ‘0Day’) vulnerabilities. These are particularly problematic and can introduce large-scale systemic risk because they provide a weakness in a particular software system that allows cyber criminals or nation-state actors to control a system or device or deliver malware. Because the vulnerability is undisclosed, this means that every system affected is vulnerable to its spread, quickly causing potential devastation dependent on the payload delivered; a payload being a component of the computer virus that maliciously executes. This can be anything from spam, to a remote access tool, to a destructive malware designed to wipe data.
Tools deployed by penetration testers are the same that criminals will use to gain unauthorised entry in nearly all other instances. The most common tool used by both good and bad sides of the hacking community, is the popular Kali Linux distribution.2 Various tools are then used within that; for example, Nmap,3 first released in 1997, which is a network mapping and security auditing tool that will provide anyone using it with critical information on the network inventory. Another is Metasploit,4 a framework tool for verifying vulnerabilities and developing exploits.
Effectively, Kali Linux comes with a suite of tools that help with information gathering and the deployment of exploit payloads. The tools are the same used by both sides – it is the exploit payloads (malware) that make the difference. If there is a new undiscovered vulnerability within a system, then a well-funded attacker might take great time and effort to write a specific piece of code to breach that system. However, most of the malware used by nefarious hackers (for commoditised or even targeted crimes) and security researchers (penetration testers) is still open-source. It is important to note that Kali Linux and its suite of tools can test the security of any IP-connected device and is not limited to Linux targets.
What penetration testing is, and what it is not
Several terms can be conflated with penetration testing. One is ‘vulnerability testing’ or ‘vulnerability scanning’, which is not the same as penetration testing. Penetration testing differs from vulnerability testing (or scanning) in that the tester will go further than simply uncovering system weaknesses. By behaving like a hacker, the testers will take the next steps to exploit the system’s vulnerabilities or overcome security measures – for example, by gaining access to data or simulating the compromise of an organisation’s physical security.
Simply put, the key difference between a vulnerability scan and a penetration test is that a vulnerability scan may scan your internal network to compare details about the organisation’s attack surface5 with known Common Vulnerabilities and Exposures (CVE)6 and security gaps in services and ports, or scan the external network for vulnerabilities. This in itself is generally enough for a low-budget test.
Vulnerability scans use off-the-shelf products to scan IP addresses or IP ranges. A penetration test must be conducted by a skilled tester. A penetration tester will use vulnerability scanning as part of a penetration test and take the output from the scan to then further exploit any vulnerabilities. A well-scoped penetration test will identify the extent of the problem, which requires a level of investigation to identify what type and potentially the volume of information that could be accessed. Penetration testers will use automated tools, but the ability to interpret the responses of the tools is what sets them apart.
Organisations will need to take a risk-based, cost-effective approach to penetration testing and thus organisations with strict budget constraints and that wish to avoid embarking on a penetration testing programme should as a bare minimum carry out vulnerability assessments. This is always the first step an organisation should take at any rate because, as explained, it will highlight any vulnerabilities and will allow the organisation to: (i) validate the corrective action taken to close out known vulnerabilities; and (ii) following a penetration test, identify any vulnerabilities which were not identified during the routine vulnerability scanning.
Vulnerability testing is typically automated, and searches for known vulnerabilities. Critically, penetration tests involve real people who behave like actual skilled hackers. In this way they are unlike automated systems, and go far beyond security compliance testing, which checks if specified security protocols are in place, rather than testing their effectiveness. Vulnerability testing is a very quick process; proper, effective penetration testing may take days or weeks.
There are some good practices that organisations should adopt when undertaking vulnerability testing. A main consideration is to conduct continuous scanning and point-in-time assessments in consideration of received vulnerability, exploit and threat information. From this, organisations should conduct a gap analysis from the results and apply secure configuration and patch management.
Another type of testing sometimes conflated with penetration testing is ‘Red Team Assessment’. This involves an element of physical or electronic social engineering, and therefore end-user engagement in the testing process. It incorporates the practice of manipulating humans, rather than systems, to gain access to systems, and to test detection and response.
In effect, Red Team Testers run short cons (deceptions) against employees to determine and measure awareness and human vulnerabilities. With a phone call, phishing email or even a personal site visit, Red Testers will attempt to convince staff or others to reveal passwords, download code or unwittingly grant access to an unauthorised user in other ways, often over many weeks. Red Tests are not intended to be comprehensive, but rather to find a way to achieve the tester’s goals. Much like penetration testing, Red Team Testing is determined by scope and can test multiple threat scenarios or very specific localised areas. In many instances, Red Teams are provided very specific areas of an organisation to focus on and exploit areas of weakness. The objectives are normally set from outputs of the Security Operations Centre (SOC) and include a multi-layered attack simulation to test human, network, applications and physical security. Similar to penetration testing, this is mostly carried out by external professionals, with only large organisations able to retain in-house services. Needless to say, the skill and complexity required to carry out this type of security function is by and large un-scalable.
One Red Tester metaphorically compared penetration testing versus Red Testing to pirates versus ninjas: pirates (penetration testers) are strong, execute brute force attacks and are good at plundering and long-range combat. However, pirates are loud, can be slapdash, and highly visible.
Ninjas (Red Testers), in contrast, are fleet, stealthy and dedicated to training and hand-to-hand combat. However, ninjas have no armour and are slight of size (Hayes, 2016).
Red Team Testers try to penetrate with stealth – testing the organisation’s security processes and procedures. Whereas penetration testers are not trying to hide their objectives. Red Testing is suited to large organisations with sophisticated, mature systems and a broad security programme.
Establishing buy-in
Penetration tests are an excellent method of determining the strengths and weaknesses of a network of computers and network devices. Such testing serves many valuable purposes – these include:
• Identifying vulnerabilities that may be difficult or impossible to detect with automated network or application vulnerability scanning software.
• Assessing the magnitude of potential business and operational impacts of successful attacks.
• Meeting compliance standards which require regular penetration tests to ensure system security. For example, the Payment Card Industry Data Security Standard (PCI DSS7) requires annual penetration testing, and ongoing testing after any system changes.
• Penetration testing is essential as part of the change management process in critical web application development or IT infrastructure changes to ensure no new vulnerabilities have been introduced into the system by the changes.
It is important to align penetration test outcomes with realistic and reasonable requirements and expectations, as part of an overall technical security programme. This requires a risk management approach which considers, for example, the potential impact of a serious hacking incident resulting in a major data breach, variations in the general threat, or major alterations to business or systems processes, all of which could result in a potential loss.
As a component of a strategic view of security management, penetration testing can deliver many different and desirable benefits. The necessity and extent of the testing to be conducted should be based on the drivers and the criteria behind them, which are multiple. They may include compliance demands, awareness of actual attacks (successful or otherwise) on similar organisations; the impact of such attacks; significant changes to IT systems or operational processes; or a contractual obligation. Risk appetite is another factor to consider for reasons previously mentioned in this chapter. Typically, a combination of these factors drives penetration testing.
Senior management buy-in is essential, which means the language of penetration testing proposals and reports should provide context as well as technical review. They should avoid the extensive use of technical jargon which may not be understood by others within the organisation, and define such language when it is essential (even a phrase such as ‘attack surface’ is meaningless to most non-specialists without explanation), both at the outset and through to the reporting stage. This approach will help senior management and boards of directors to better understand the need for and benefits of testing. Budgets in most organisations are typically limited and mid-level managers can find it hard to get the necessary budget allocated, so using plain English is vital when making the case for penetration testing.
At this early stage, a test programme proposal should be prepared. It will set out the purpose of the activity, and outline potential benefits to the organisation, including the obvious (such as meeting a regulatory requirement) and the less tangible (for example, helping to avoid the reputational damage that can be incurred following a major security breach). In some cases, regular penetration testing in the past may be cited as a reasonable precaution to limit liabilities during a legal challenge.
The test programme proposal should also consider any potential limitations or pitfalls of testing.
Penetration tests have limitations, of course. For example, penetration testers must operate under certain constraints – such as time – which a real hacker would not necessarily face. Nor is a real hacker limited by any scope of testing. It is important to be aware of such limitations, and to design penetration tests accordingly.
DELIVERING MAXIMUM VALUE FROM PENETRATION TESTING
When considering penetration testing it is important to establish what exactly it is that needs to be achieved. Delivering maximum value from conducting penetration testing will depend entirely on the testers setting out a clearly defined statement of works and delivering within that. While there can be shortcomings in terms of not setting a clear scope and the very fact that systems frequently change, testers with the right tools and end-user engagement can expose critical business vulnerabilities and advise on delivering remediation – and this should always be at the forefront of the receiving organisation’s mind.
Scope of testing
The scope of testing should be determined based both on the goals of the test and on the budget. To be effective, however, penetration testing requires an adequate budget and should not be minimised due to budgetary restriction, as half-measure penetration testing is a pointless exercise.
It is the job of the test programme proposal to justify and secure adequate funding for the scope of testing necessary. The scope may include the preferred profile of the threat agent, which could range from an external hacker with limited skills and no knowledge of the target system, to an internal user attempting to gain access to ring-fenced areas of the organisation’s network. When the PCI DSS is to be applied for example (PCI Security Standards Council, 2015), all the ‘people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data’ are considered to form the ‘cardholder data environment’. The standard requires penetration testing of public-facing potential entry points, as well as potential access points from within the system.
The terms black-box, grey-box and white-box are sometimes applied to penetration testing. The first implies the tester has no knowledge of the system, the third that full knowledge is provided in advance. Grey-box is often preferable, as it provides some internal knowledge of the network, such as a demonstration of the application being tested, and access to login credentials or internal architectural diagrams. This can reduce testing time without providing testers with too many keys to access before testing is under way.
Scope also defines the networks and systems to be tested. It may be that only public-access systems are to be tested, for example. Regardless of the approach, the challenge of defending the network perimeter is key to any testing. Firewalls should be installed and configured correctly at the time of testing. Penetration testing is one way to ensure this frontline defence is adequate.
At the outset, the client and tester should agree the scope and type or types of attack that will be implemented, and set clearly defined objectives. For example, it should be decided whether to adopt a white-, grey- or black-box attack approach, based on the business, sectoral and architectural risk analysis that preceded the process. Questions such as the range of IP addresses that will be swept and ‘ping’ tested should be agreed (the decision about the advanced supply of IP addresses to the tester is one to be made in the scope-setting process). Service Level Agreements (SLAs) should specify from the client any explicit permission to exploit any vulnerability as it is rare to have approval to exploit these at will. It would be prudent at the on-boarding, due-diligence stage to check with the vendor that they are insured to be able to provide such services. Penetration testing firms should have technology professional indemnity and cyber liability coverages.
Less technical variables should also be considered and agreed. For example, the client should ensure the price quoted is in line with overlying agreements. If the test service provider states its test will take five days, the limitations of testing within those five days should be defined. Once the objectives and scope of a given test are agreed, the client and the testing organisation should agree on the methodology to determine, after the fact, if the test objectives have been achieved.
Statement of works
Once a scope has been agreed, a clear statement of works should be provided, and a legal authorisation of those works provided in return. The latter should clearly state that the penetration testing organisation engaged can, in essence, ‘attack’ the contracting organisation without repercussions.
Timescales and delivery deadlines should be included in the statement of works. These variables will be dependent upon the type of attack required, the external and/or internal infrastructure to be tested, and the level of systems information the company wishes to provide before testing commences (all of which should be identified by the scope). When a penetration tester is given more information to reduce the level of reconnaissance required, testing will require less time. However, tests conducted by highly briefed testers do not provide a true reflection of the approach which might be adopted by a sophisticated threat agent.
Addressing potential shortcomings
Penetration testing has some shortcomings. One concerns timing. Any system can be tested at only one point in time and systems always change and evolve. So setting up a regular programme of testing with the appropriate time frequency is a prudent approach. Another shortcoming is scope. If satisfactory evaluation and planning are not carried out, the process can become a box-ticking exercise for the sake of compliance. It must be aligned to business goals and threats. The business, sectoral threats in the context of business risk analysis, and architectural risk analysis that precedes penetration testing will provide a useful map of priorities for the eventual penetration tests themselves. Understanding the threat by sector is critically important, as this analysis can help to determine the appropriate scope of testing. The same is applied when threat modelling against architectural considerations as this will help identify attack surfaces.
Testing on live systems carries risk, and the organisation should truly understand that risk before engaging in live testing. Often testing is carried out in non-work hours, which does not necessarily reflect the true operational environment (because, for example, many network devices may be switched off and un-ethical hackers work internationally and maintain unsociable hours).
At any time, penetration testing critical operating technology can be expensive and dangerous. There can be instances where aggressive vulnerability scans can cause network components to crash. If the limitations of tests are not well understood, it can in itself provide a false sense of security, especially in contrast to simple vulnerability scanning. No system is ever completely secure. However, penetration testing can help to build very high levels of confidence in the security of a system and the data it holds. To underpin this confidence, testing must not be a one-off process. When budgeting, a follow-up test should usually be factored in, since effective testing includes fixes: test, adjust and remediate, test again, then report.
Selecting the right tools
It is essential to ensure that penetration test outputs are accessible to existing cyber-security tools and programmes. The use of a risk tracking or vulnerability management tool assists in this by continuously detecting for common vulnerability exploits. Larger companies may have tracking remediation tools that follow developers’ progress as bugs are repaired. Many organisations, particularly in the public sector, add vulnerabilities found in penetration testing to the organisation Risk Treatment Plan (sometimes called Risk Register). They may use these tools to grade the criticality of various security threats to prioritise remedial action. For example, a critical vulnerability that could expose large databases via the internet may require immediate mitigation, while similar data sitting on old unsuitable operating systems that run in isolation and do not connect directly to the corporate network may be a lower priority (although the potential vulnerabilities of such data warehouses should not be ignored).
In environments where software applications are built and managed internally, remediation tools should fit within a developers’ software development lifecycle (SDLC). Ideally, a secure development programme will have been adopted early in the SDLC to prevent rather than identify vulnerabilities, although development should include penetration testing. At the post-implementation penetration testing stage, project management within a formalised process is necessary to ensure the capture of data and the validation of results and outputs throughout the lifecycle of the project. For the majority of organisations, however, third-party software applications are the norm for many functions and will carry an element of risk.
In security, an organisation is only as secure as its weakest link and third-party security assessments, dependent on criticality of the software asset, is essential. However, a major factor for consideration when reviewing a software provider is to assess the terms and conditions for guarantees that they penetration test their application. It is highly likely that they are providing the same service to other clients and will likely need to provide assurances that they are not introducing risk to their clients. As such, a software-as-a-service (SaaS) vendor will require clearly defined separate and limited rules of engagement for any of their customers who wish, in the course of due-diligence, to conduct a penetration test. Without this, the testing company risks being liable to potential prosecution.
End-user engagement with testing
As stated earlier in this chapter, for the majority of organisations penetration tests will be conducted with the assistance of a third-party penetration testing provider, although there will be certain organisations that will retain internal qualified testers – such as the UK Ministry of Defence (2013: 76) and large financial institutions. However, for those using third parties, in many cases, it may be appropriate to include administrator and end-user engagement with security testing programmes. If conducting a grey-box test for example, it is likely that the tester will require network or systems information from internal users – such as developers and other IT members.
Red Team Assessments, also discussed earlier, do involve end-users. They may unknowingly become involved, as Red Team testing involves the human side of breaching security, typically through physical and electronic social engineering.
In most cases, sensitive information will be shared with end-users only when testing has been truly disruptive to the business and demands immediate remedial attention. This and other reporting conditions and lines, particularly with senior management, should be agreed between testers and clients at the outset. A clear reporting line to senior management is an essential channel particularly for use when a critical threat to the business is uncovered.
Quality assurance
The role of a penetration tester is to determine what an intruder is able to do to gain access to a system or network and maintain access to that system or network, and what they could do with any information they find there. They do this with persistence and the deployment of learned skills to exploit weaknesses in targeted systems. Penetration testers should demonstrate to their clients any problems which they encounter or have uncovered. In some instances, the client will be unable to interpret the implementation instructions set out in the penetration tester’s report. In such cases it is important that the tester is able to add clarity through illustration – for example, by delivering information to replicate the exploit to infiltrate a vulnerable part of the system and how to fix it via patches and code changes, among others. This is an important component of the validation process, because it delivers to clients the information necessary to understand vulnerabilities completely, and the processes employed by testers to exploit them.
When highlighting vulnerabilities, the importance of validation is underlined through its ability to identify false positives. Such wayward results can leave the client attempting to implement remedial actions to repair bugs and vulnerabilities that do not in fact exist. Validation should dramatically reduce the chance of this frustration occurring. It is part of a quality assurance process which should include the implementation of an auditing and tracking procedure.
Quality assurance on the part of the penetration test service provider is very important and must extend well beyond the actual outcome of the testing itself. Contracts can be lost for simple mistakes such as spelling errors in reports. In all cases, senior personnel (such as, in the UK, a qualified CHECK Team Leader) should at the very least review all penetration tests at all stages of the process. A UK-qualified CHECK Team Leader senior penetration tester will possess the background, experience and knowledge to assure the quality of the penetration testing work of junior testers. According to the UK National Cyber Security Centre (NCSC),
a CHECK team is composed of at least one CHECK Team Leader and a number of CHECK Team Members who have passed any of the NCSC accredited CREST, Cyber Scheme, or Tigerscheme examinations. Only the NCSC may confer CHECK Team Leader/Member status.8
Review
Test review cycles should be set in consideration of the types of test to be deployed. One-off annual penetration tests for compliance are a norm, but penetration testing should also be conducted following major system changes or projects, as a component of security best practice, and as part of a holistic information security regime. Some large or extremely systems-dependent organisations opt for continuous testing, but this can be a significant consumer of management, staff and physical resources, potentially requiring weekly meetings and ongoing report reviews. It is common for large organisations to run regular monthly or weekly vulnerability scans and then engage with penetration testing teams annually or when major changes occur. For most medium to large organisations, a kick-off meeting or series of meetings before the test will be followed by daily wash-ups to highlight any considerations or requirements from either the testing team or organisation being tested, which may be handled as conference calls.
A penultimate meeting will consider important concluding questions, such as whether the overall aims and objectives of testing were achieved (and if not, why not), and should determine what next steps should be taken to meet the scope objectives. Another purpose of the meeting is to discuss a summary of the vulnerabilities uncovered, and to identify any critical databases which may be externally facing. A final wash-up should review and discuss an interim report that provides a summary of the entire testing process, its methodologies and its findings.
Recommendations for remediation
When the testing has been completed, the recommendations for remediation set by the tester should act as, or be interpreted much like any work instruction. In some instances, the IT manager or IT security manager will need to link the tester directly with the internal responder (for example, a developer), because internal personnel may not be able to rectify the issues identified, or may need further information to do so. It is not uncommon for the penetration tester to work alongside the appropriate personnel within the client firm’s IT department to ensure these messages are delivered.
Benchmarking
Any firm that has engaged in a penetration testing programme should apply some basic benchmarking both of the penetration testers and the developers who will implement the remedies. At the most practical level, this could involve a simple assessment of the value-for-money of the penetration testing programme adopted. That said, there are many organisations who simply run a programme to satisfy governance requirements. Clients should consider the clarity of remediation recommendations made by their testers, and assess the speed of implementation of such remedies. If developers’ coding practices are revealed to be sub-standard, more dialogue will be needed, perhaps alongside the introduction of structured methodologies to enable them to learn from their errors. Companies may seek to assess their security performance against an internal score card, or an international standard such as the Common Vulnerability Scoring System (CVSS), which provides a methodology to capture the main characteristics of a vulnerability and translate that vulnerability into a numerical score to reflect its severity. It allows informed allocation of resources to implement remediation. CVSS is a published, free international standard.9
PENETRATION TESTING AS PART OF A HOLISTIC INFORMATION SECURITY PROGRAMME
Penetration testing is a key part of a holistic information security programme. It should be considered as part of the overall security testing programme and its goals. As such, the frequency and depth of penetration testing should be aligned with other development and cyber-security projects. Some internet-based systems are tested annually. Other tasks demand project-based tests, such as code development and firewall configuration. A project test schedule is also needed when a heightened need for security is identified. For example, after a high-impact incident such as a malware or social engineering attack, an organisation is at a weak point. Once forensics have confirmed which part of an organisation has been exposed, it is highly likely that there will be IT-specific project streams working to reduce the likelihood of a repeat event. During this phase the organisation will be at a heightened level of security and might engage in penetration testing to measure the effectiveness of any change programmes. It could be that an organisation hasn’t suffered an incident but has received a threat or near miss event. This could trigger the need to conduct project-based testing. Project-based testing may adopt one of many approaches, including wireless, application and comprehensive infrastructure testing.
One of the easiest ways to gain access to a network is through its wireless networks, so it is very important that Wi-Fi networks are segregated for internal private and guest Wi-Fi. It is important to make sure wireless configurations are as secure as possible. Using high-powered antennas and tools (such as the WiFi Pineapple,10 a wireless penetration testing tool that acts like a ‘man-in-the middle attack’) hackers can attract users to log on through their access point, and then use software to track and log what connecting users do through its receiver. Segregation and strong encryption help minimise risk.
A man-in-the-middle attack is a form of interception attack. It is where someone has gained unauthorised access to communications between two parties for the purposes of eavesdropping or impersonation.
If conducting an infrastructure (network) attack it should form part of the penetration testing scope, as it is an easy route in for an attacker if there is no separation.
RISK ASSESSMENTS AND RELEVANCE TO LIVE-SYSTEM LIFECYCLES
Certain steps need to be taken before starting a penetration test to identify critical platforms and applications and also the internal IT personnel who will be part of the process. There are inherent risks that need to be properly assessed and where necessary, redundancies in place to manage and mitigate these.
Risk analysis and assessment
A risk analysis and assessment is critical before engaging in penetration testing. This is conducted in part to determine live systems’ roles in enterprise IT. A first step is to identify, understand and map what data is held and how that data is classified. Critical platforms and applications can be identified through this process. A confidentiality, integrity, availability (CIA) assessment should form part of this process in order to determine the impact of a CIA breach:
• ‘Confidentiality’ is the rule-set that limits access to information held on systems to those authorised to see that information.
• ‘Integrity’ is the trustworthiness of that information – assurance it has not been tampered with at the stage of processing, transit or storage.
• ‘Availability’ is a promise of reliable access by those entitled to view and use the data.
Further, regulatory considerations may be at play, such as the aforementioned PCI DSS. All these factors should be included in the risk assessment process.
Live-system lifecycles
Live-systems personnel should be included in the process of penetration testing. Throughout the planning and testing periods, liaison with specified IT personnel responsible for live systems is an important link. The personnel who understand the environment best should always be on hand for consultation. If, for example, networks are undergoing penetration testing, the service manager of a data centre (DC) may need to be involved. Dependent on the size of the organisation and if cyber-attack response is part of the scope of the test, the individuals running the Network Operation Centre (NOC) and the Security Operation Centre (SOC) must be informed well in advance of any port scanning. In addition, developer or application support personnel should be on hand. Change management procedures must be followed closely, communication channels must be clear and people available and ready to provide assistance when needed. Another factor to consider is access to the DC. For some tests, it is a requirement to perform them at the DC and for many organisations, the DC is not run by them. Gaining the relevant access needs to be identified in the scope and clearly managed to avoid delays. Considerations can include but are not limited to the location of the DC and what tier of security the DC is – the higher the tier, the more security it will have in place.
System lifecycles and workloads should be considered in cyber-security threat schedules. This too should be considered in the risk assessment process, as it is important to understand where organisational vulnerabilities may lie. The global NotPetya attack during summer 2017 provided an excellent example of a system lifecycle threat. The malicious code used an auto-run function within a critical software update. It sought to gain administrator access, then to leverage that access across victim companies’ entire networks. The potential impact of such attacks increases when companies ‘whitelist’ software updates, thus affecting live systems. Logic Bomb threats – malware timed to deploy at the time of an attacker’s choosing – are another way to hack systems in alignment with system lifecycles.
System lifecycles may drive penetration testing schedules and scope when upgrades or maintenance operations are performed. PCI DSS requirements state that penetration tests must be performed at least annually to ensure that the controls assumed to be in place are still functioning effectively after any significant change to any part of the network infrastructure, after any application and software upgrade or maintenance, and immediately after a significant event. However, what is deemed significant is dependent upon the organisation’s risk appetite and assessment. When a change could impact the security of the network or allow access to cardholder data, for example, it may be considered significant by the organisation in question.
With an ever-increasing connectedness between people and systems, the need for organisations to penetration test those systems is expanding not only in scope but also in frequency. It is important to understand what you are trying to achieve when conducting a penetration test and the differences between this and vulnerability scanning.
When considering the services of a penetration testing company, understanding their background, qualifications and the frameworks they align to should be part of the procurement cycle. Whether conducted by internal or external resources, penetration testing should be realistic, have reasonable requirements and give support to the overall technical security programme. In all instances, it must be a risk-based, cost-effective approach to ensure money, time and resources are not wasted and objectives are achieved in line with the clear statement of works set out.
Before setting out on conducting a penetration test, organisations need to ask themselves, ‘who is a threat to me and why?’ and ‘what does cyber risk mean to me?’. These two questions help identify the foundations for risk management – and the where and how of penetration testing might be applied.
CREST (2017) Penetration Testing Programme: Maturity Assessment Tools. Available at: www.crest-approved.org/wp-content/uploads/Penetration-Testing-MMAT-Guide-2017.pdf
Hayes, K. (2016) Penetration test vs. red team assessment: The age-old debate of pirates vs. ninjas continues. Rapid 7 Community, 23 June 2016. Available at: https://community.rapid7.com/community/infosec/blog/2016/06/23/penetration-testing-vs-
red-teaming-the-age-old-debate-of-pirates-vs-ninja-continues.
Ministry of Defence (2013) Reserves in the Future Force 2020: Valuable and Valued. Available at: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/210470/Cm8655-web_FINAL.pdf
PCI Security Standards Council (2015) Information Supplement: Penetration Testing Guidance. Available at: https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf