Penetration tests need to be structured correctly, with good coverage, and should be undertaken for a useful purpose. This chapter delves into a number of topics that will make it easier to create good penetration test coverage and a simulation that aligns with the threat to the organisation and system.

PENETRATION TEST COVERAGE AND STRUCTURE

Test coverage is critical in ensuring that the penetration testing exercise being completed is done to a standard that makes it worthwhile. This section looks at several elements that will help you to ensure you get the correct penetration test coverage for your organisation’s needs.

Selecting a target for penetration testing

It is not possible to prepare perfectly for an entire security test. There are, however, a few items that can be completed that will make the experience a lot smoother, and help in getting the most out of the exercise.

Start by working with each department in the organisation and establishing a list of all the assets they manage, have dependencies on or interact with. This list should not just include those that have the most impact on the organisation, but should include those assets that they are less worried about as well.

All the organisational assets will need testing at some point to gain assurance that it isn’t possible to break into a less-important system in order to then gain access to a highly valued system. With all these systems, also list the technical details that identify them; for example, with a web application test, this might be a particular IP address, domain name or URL, while an internal network test might identify the IP address of the server, along with the network within which the system is located.

Each of the items on the asset list should be considered for the level of risk the system poses to the organisation. This calculation can be brief, as it only needs to provide a prioritisation. To make this calculation, consider the:

The second thing you will need to do is establish a budget. If budgets get handed down from top-level management and it is the first penetration test for the organisation, take whatever budget is on offer, as subsequent penetration tests will have the evidence in place to fight for a more appropriate budget. The person that has responsibility for setting the budget should start by understanding the current market’s day-rate. Following that, a broad understanding of the size and complexity of the organisation at a very high level is important. It may not be possible to then convert this size and complexity into an estimate of how many weeks of work there are regarding penetration testing, but it should be possible to understand whether there is very little tech to be tested or a lot. Whatever budget is determined, it will soon become clear whether it is enough for an ongoing programme or even for a single test. The good news is that in reality even a small budget will at least get you a basic test, and will probably give the organisation some knowledge of areas in need of corrective actions.

Test duration and scheduling

Timing and scheduling are in reference to the duration of a penetration test exercise, and the times and dates when a test will start and finish.

When it comes to test duration, there are two types of test: sampled and exhaustive. The trade-off between the two is test duration (budget) versus assurance gained. If the test is exhaustive it will cover all areas, thus taking longer; but at the same time providing a higher level of assurance. The inverse is true for sampled tests; however, that does not mean that a degree of sampling should be avoided. There are obvious limits to the efficacy of sampling: too little coverage is like sniffing cheese from 10 feet away – only the worst smelling targets will be noticed; while if sampling 95% of the target, the last bit may as well be eaten so it isn’t lonely in the fridge.

Test duration will ultimately be dictated by the budget for the exercise; however, where there is a choice to be had, the length of the test duration should be proportional to the size of the target. For example, if the exercise is a web application test and the web application only has one function, it might be considered very small, in which case the test may only take two or three days. If the web application has a large number of complex functions, it might be considered very large in which case the test duration will need to be much longer – maybe even several weeks. If there is not that much time, take on a testing team as they will be able to cut down the overall test duration by working in parallel.

At the time of writing there is a shortage of personnel in the security testing industry; this shortage means that diary availability for penetration testers can be a challenge. It is not uncommon to experience lead times of three months before a tester is available. The key here is to book the penetration test as early as is feasible, particularly if there are deadlines to be achieved. If the project requires penetration testing in a very short time frame it might be possible to get several testers to each perform a very small number of days to build up to the overall number of days that has been chosen for the required level of assurance. This tactic will provide some results; however, it is important to understand that it is an inefficient use of time owing to handing the project over between testers, and will not necessarily give good results as it is very difficult to be certain that the correct coverage has been completed. Where this method of calendar juggling is a must, try to fit in an extra day or two to compensate.

Testing can be commissioned for long-standing systems as well as those that are being developed or implemented. For those long-standing systems, it is probably sensible to not schedule a penetration test of it within a few months of it being decommissioned. There is nothing more demoralising for a penetration tester to be told at the beginning of the exercise than ‘I’m not really sure why you’re testing that… we turn it off in a few weeks’.

There are two elements that should be considered when a project is being developed or implemented: scheduling penetration testing so that it doesn’t delay the launch of the project and having security advice and testing built into the entire development or implementation timeline. It is much more efficient to get insight into the security of a system as it is being developed or implemented rather than risk having to make major changes once it is complete.

Supplier and client assurance

Client assurance is the process whereby an organisation attempts to produce evidence to assure its clients that the organisation’s systems, either specific to the client’s interest or the entirety of the organisation, are secure. This is a common driver for penetration testing, and can have an impact on the methods, conditions and frequency of penetration testing, as well as how nervous the organisation commissioning the test is about the results.

In 2013 the American retail organisation Target was breached by hackers via one of Target’s heating, ventilation and air conditioning (HVAC) suppliers. It is believed that the initial access in this breach was completed by using a phishing email against an employee of the HVAC supplier. The phishing attack then allowed the attacker to install a password harvesting tool which compromised a password that belonged to Target’s vendor access portal. The event was heavily publicised at the time and in the years following there has been significant analysis of what actually happened and how repeat incidents could be prevented. One such study by the SANS Institute (Radichel, 2019) discusses, among other areas, requirements that could have been made by Target on its suppliers. It’s fair to say that the vast majority of preventive actions that could have been taken lie with Target itself; however, strong supplier assurance could potentially have prevented the breach as well. For example, the SANS report suggests that requiring the supplier to have fully functioning anti-malware software would have prevented the password harvesting tool from being installed. However, note that infrastructure penetration test reports often include findings about the ineffectiveness of anti-malware products. This is particularly the case when those defensive technologies fail to detect the malware payloads used by the penetration testers that are generated by open-source tools.

Anti-malware products are considered as only one component within a defence-in-depth approach to information security. The anti-malware tools that are considered the most effective by security experts change year-on-year owing to the fact that the tools that create malware are constantly under development specifically to defeat the latest and best anti-malware functionality. Fundamentally, this is an arms race and it is difficult to keep up to date on both sides of the battle. These products absolutely have their place, but where they are used they must be configured correctly and their users must have reasonable expectations of their abilities.

When dealing with client assurance, the choice of penetration testing conditions and sampling may not be under the organisation’s control; it may be set by some form of client pressure that is specific to the type of client. For example, if the organisation works for a government body, that government body may specify the frequency, scope and depth of penetration testing that they require the client to have completed. In that case, the contract will dictate and prescribe the situation, and instead it becomes a case of understanding exactly what is required.

When you are required to provide assurance to clients make sure that the level of detail the client requires is understood, and what scope is important to them. For example, providing them with an executive summary and issuing summary tables is often considered enough, as they demonstrate the level of security without giving away so much detail that the client would be able to cause a breach. If the organisation is receiving assurance from its clients, this works in reverse: check the scope coverage and consider what level of detail is appropriate.

External conflicts of interest

It is generally accepted that penetration testers should not test any corrective actions that they have taken on behalf of their clients. This is too much like marking the penetration tester’s own work, which is ethically questionable at best and potentially dangerously misleading at worst. This is because there are opportunities for a conflict of interest, some more obvious than others. For example, the tester gets to charge twice, once to find the problem and then again to fix it – but if no one else sees or understands the problem, how can it be validated that the problem was there in the first place?

Such a conflict of interest does not simply apply to the individual tester; it might apply to the penetration test service provider itself. For example, does the supplier do anything else for the organisation, such as any managed services? Are its individual test consultants in a different department from those that are performing other services for the organisation? Do not automatically rule out situations like this: there may be rivalries, where one team actively wants to break the work of another team which might result in some good findings. Furthermore, if one team finds a problem, the other team is going to struggle to argue that it doesn’t need fixing without a serious amount of internal debate.

If you find yourself in a difficult situation where a split needs to be established, there is a trusted adage within the world of information security known as Schneier’s Law (Schneier, 2011): ‘any person can invent a security system so clever that she or he can’t think of how to break it’. This phrase is most commonly used in reference to encryption algorithms; however, it actually applies to the whole information security domain. This law was named after Bruce Schneier, by Cory Doctorow (2004), but it is believed that originally this was a concept coined by Charles Babbage.¹ Essentially, it means that it takes more than one perspective to be able to conclude that a system works in the way intended and is secure. In the context of a security test and its practical application, this law states that the individuals who built a system’s security defences can’t be the same as those who test those security defences.

Should there even be small indicators of a moral or ethical problem pertaining to the penetration testing programme, get to the bottom of it before it becomes something serious. Hopefully the issue will be far less significant than first thought and progress can be made, but if there is an issue, resolve it as early as possible, before it is too late.

Internal conflicts of interest

When acting as a team receiving the outcomes of a penetration testing exercise, there are likely to be a range of emotions present. Be careful not to bring a conflict of interest to discussions, and help those having a conflict of interest to consciously realise this, so that they can direct their energy appropriately. Sometimes these lines can blur and it is no longer clear what the situation is; the chances are, though, that the penetration tester just wants their work to be representative and accurate.

There are two main types of conflict of interest. These aren’t official terms but here they are named ‘suppressive’ and ‘promotive’. Suppressive conflicts of interest are where the outcome of the exercise is minimised in order to reduce the perceived impact. This can be risky because the legitimate problems may get swept under the carpet and remain vulnerable. Promotive conflicts of interest are where the drive is to make everything sound terrible in order to achieve a particular goal. This can be risky as those receiving the information could criticise the outcomes of the exercise as unnecessarily inflammatory, and also question its accuracy or entirely discredit the outcomes.

One example of a vested and clearly suppressive conflict of interest is where a product manager wants a solution to pass a penetration test: they may push the tester to downgrade vulnerability scores, as in their eyes a poor report will prevent them from making the system live. Equally, an example of a vested interest which is more subtly suppressive-conflicted is the engineer that created the product wanting to downgrade the severity of the vulnerability scores because they spent hours on the code and are proud of their efforts.

Promotive conflicts of interest can be harder to discern. An example is where there is a desire to increase the severity rating of one or two reported vulnerabilities. The tester may never know the cause of this, but it might be something simple such as gaining extra budget because ‘things are bad’, or something very specific and complex, such as building a dismissal case against a member of staff.

Size and frequency of penetration test exercises

The security world moves constantly, every day new issues, risks, weaknesses, attack techniques and vulnerabilities are made and published. It is possible to go from having a rose-coloured world one day, to being on an emergency conference call the next morning because a new vulnerability has been released. From a penetration testing perspective, the challenge of this perpetual motion is ensuring that there is adequate coverage of all current problems as well as the entire back catalogue of possible vulnerabilities.

All organisations have the flexibility of choosing the frequency of their penetration tests, but some have minimum requirements imposed upon them from external sources such as regulations, client assurance or standards compliance. Aside from these external pressures, there is no hard and fast rule for the frequency of penetration tests. It is common for annual penetration tests to occur on systems that are not actively being developed and for any significant changes to be subjected to a penetration test immediately after they have been completed. That said, the frequency with which penetration tests should be completed is best guided by the context and risk appetite of the organisation and the systems being tested.

Organisations talk about detecting ‘low-hanging fruit’: the quick-and-easy fixes that would otherwise give their attackers an opportunity to exploit. This analogy works, but only in the context of a single testing exercise, because low-hanging fruit grows over time. This analogy still has significance though, as the majority of the harvesting of low-hanging fruit will occur in the first few testing exercises. After this, those big hitters will become fewer and further apart.

This begs the question ‘what next?’ and the answer is to decide whether more depth is appropriate. There are lots of reasons why more depth might be desirable: for example, the system might hold very sensitive data or be used by very high-profile clients and so on. Overall though, it is important to realise that just because a test programme took eight days last year does not mean it is fixed at eight days; for instance, it might be desirable for it to take 10 days this year.

Organisation size

The size of the organisation has a significant impact on how penetration testing is performed, not only from a coverage perspective, but also with respect to how a threat is simulated. In reality, threat actors have as much time as they want, which means they can attempt to attack as much or as little of a targeted organisation’s infrastructure as they want. This might sound like test coverage should always be 100 per cent of the attack surface regardless of the size of the organisation, known as ‘exhaustive testing’. In an ideal world this is the case; but it is rare for this ideal situation to occur. This is where sampling comes in. Sampling has two main forms: vulnerability-class sampling and system sampling.

Vulnerability-class sampling is where the penetration tester does not try to exhaustively find every single instance of a particular vulnerability, but instead attempts to find one of each type, or classification, of vulnerability in each system. This type of sampling works best for web applications or other custom-built applications.

System sampling is where the scope is limited to a representative sample of systems and instead requires the tester to find as many different instances of problems that they can, no matter how repetitive or diverse.

For both types, following the tester’s report and educational activities, it then becomes the organisation’s responsibility to find and fix every instance of the problem. It might sound like this is the best solution for larger organisations or those with a constrained budget; it certainly helps, but the organisation must fundamentally understand that they are taking at least one risk. With vulnerability-class sampling, the risk is that the client will not be able to find all instances of the problem and will not recognise the more advanced and edge-case versions of the same problem. While system sampling, on the other hand, carries the risk that the representative sample is not actually representative, and that there is variation, for example, between office locations (which means one office is more vulnerable than the others).

Furthermore, a sampled test must be acceptable for whatever purpose the test is to fulfil. For example, client assurance or contractual obligations might require exhaustive testing. Some testers might also provide a certificate of achievement for those tests that are exhaustive and contain no concerning vulnerabilities: if this is important to the organisation, make sure the test is suitable for this purpose.

If the organisation is on the larger side, it may be appropriate to allow an exhaustive reconnaissance exercise to be completed. This will enable the organisation to understand how exposed it is to external threat, potentially identify systems that were hidden or otherwise unknown, and therefore make it possible to define an appropriate testing exercise.

There is a sweet spot in terms of security capability that is related to the size of the organisation. Table 7.1 outlines how the approach to enterprise penetration testing needs to be adjusted to suit organisation size and is based upon the author’s observations and experience. There are always exceptions to the observations shown in Table 7.1, but so far there have been few and they have usually been to the extreme.

SIMULATING THE THREAT

When designing a penetration testing programme, one of the defining elements will be an estimation of who the threat actors are and how they operate. This estimate should be taken regarding the target to be tested, as well as the overall size and sector of the organisation. By way of example, consider a retail banking group. This organisation might have the following threat actors:

Table 7.1 Security capability related to size of organisation

The behaviour of each threat actor varies according to their intent, resources and level of access. As you can imagine, testing for security considerations to defend against nation-state sponsored attacks can be somewhat more involved than testing for protecting against errant consumers trying to get something for free. This section examines elements of penetration tests that have an impact on the ability of the penetration test supplier to accurately simulate the threat and what can be done to compensate.

Pre-test ‘hygiene’ checks

Pre-test hygiene checks are those which make sure no serious problems are present before a test gets under way.

As obvious as this might sound, one of the most important checks that should be completed before any penetration testing begins is whether systems actually work as they are supposed to. Ultimately, the test service provider is being paid for their time, and not the results. To derive the most value from your budget, make sure that testers are able to get started as soon as possible when the testing time frame starts. This goes wrong surprisingly often, and in most circumstances it happens with web applications that are actively being developed.

Part of whether the system works as it is supposed to, is making sure that when the tester runs a given function it outputs data that is realistic and as expected. That is not to say it should be real data – in fact, in a test system it probably shouldn’t be – however, the data should be ‘lifelike’. This makes it clear to the penetration tester how the system is supposed to behave, and it will assist them in developing attacks that actually make sense in the context of the real system.

Software knowledge

Software knowledge is simply where a penetration tester has prior experience of or knowledge on a particular system, whether that is software or hardware.

When working with all the asset owners you may identify unusual systems. If this is the case, choose penetration testers with this in mind. This can include industrial control systems, mainframes, legacy systems or applications written in obscure programming languages. If the tester has knowledge of these systems they will be more efficient with their testing, and may find vulnerabilities that a less-experienced tester would not identify. The penetration test discipline is already very specialised, so if you add a requirement for even more specialism the cost of the service will likely increase.

Aside from these obvious specialisations, it is less important that the testing consultants are experts in the organisation’s particular network, firewall stack, operating system choice and so on. This is because the most important part of a testing exercise is the creative thinking and this is vendor-neutral. Where vendor-specific vulnerabilities need to be tested, the research part of every penetration test will pick these aspects up and check against databases of known vulnerabilities.

Level of information security maturity

Information security maturity is the measure of how advanced an organisation is in its approach to securing its data assets. Often, a high level of maturity comes with many years of dealing with information security issues and embedding appropriate activities within the standard organisational operations. There are several different security maturity models, but ultimately, they refer to the same general principles. Gartner’s security maturity model (Scholtz and Heiser, 2013) uses five levels:

Each of these models represents an improvement of the business’s capabilities, but also shows a shift from tactical focus to strategic focus.

During the development of the organisation’s information security maturity, testing exercises will change and become a smoother experience. Early testing exercises are typically very exciting, and will be very loosely constrained. This allows the penetration tester to focus on and advise on the areas that present the most opportunities for an attacker. Typically, this means that the range of the test will be very large, covering a bit of everything. Conversely, the size of the exercise is likely to be very small in terms of the number of days allocated. This is often because of budgetary constraints and penetration testers can be left with the impression that the organisation is ‘sticking its toes into the water’. Once the organisation has climbed the maturity model ladder, tests can become narrowly focused on a particular system, and are permitted to go into much more depth as a result of having a significant number of days allocated.

Not breaking things

Penetration testing service providers do not want to break things – at least, not in a permanently damaging kind of way. Most penetration testers have a strong moral compass and the act of damaging something goes against this. The motivation behind most of what penetration testers do is twofold. First, they think what they do is cool, exciting and interesting and the more advanced an attack is, the more impressive it is. And second, that by exposing these weaknesses, it makes it possible for them to be corrected and when that happens, the world is that little bit safer.

That said, accidents and unexpected consequences do happen, so wherever possible, arrange testing with this in mind – whether that is a full test system so that breakages simply do not matter or having a dedicated member of staff available for the test duration who can pick up the pieces should anything go wrong. Another tactic is to perform testing outside of standard business hours in order to have as minimal an effect as possible should the worst happen. This is a sensible precaution if there is a lot at stake; however, this will substantially increase the cost of any testing exercise.

The best thing to do is to have a rough plan of action ready should there be problems with a test. This should include lines of communication with the tester, and have enough logging in place to be able to identify the issue, diagnose the problem and implement a fix to get services back online. This logging should also try to provide a method of positively identifying that the cause of the attack actually came from the tester: there is nothing worse than not knowing whether the problem was from a real-life attacker or from the authorised penetration tester. Just a couple of examples of attributes that can identify the attacker are source IP addresses and authentication details such as usernames, passwords and session IDs.

Consultant penetration testers are paid to test the limits of the security of a given target. Things going awry are an occupational hazard and should not come as a surprise. When experiencing one of these unfortunate moments with a tester, remember that the organisation has paid for the test, and it is important that both organisations use the incident as a learning point to either prevent it from being a problem, or to get it treated differently the next time the system is tested. Think of employing a penetration test service provider as managing risk, not eliminating it. There is a risk being taken that something might go wrong; however, it is far less impactful when done in controlled conditions than when a real attacker wants to cause harm.

It is always possible that a real attack will happen at the same time as a penetration test. Do not get complacent. If a penetration test is happening and an alert pops up it is always sensible to verify the finding both from a defensive stand point and from the penetration testers’ perspective: they will want to know if you would have ordinarily spotted any of their activities. But don’t just go to the testing consultant and tell them that a system saw what they were up to; go with some detail that illuminates what the activity was and the source IP addresses or other available identifying mark. This makes it possible for the tester to confirm that the observed activity was in fact them.

Targeted and untargeted exercises

Targeted exercises are where the penetration testers are provided with a specific scope at the beginning of the engagement before any work is completed, whereas untargeted exercises require the testers to discover the targets. In both examples, the testers will need a confirmed scope before they actually start testing. Typically, an untargeted exercise will use open-source information to try to build up a picture of the infrastructure and services that belong to the organisation, as well as attempting to find members of staff and other assets.

Choosing between these styles very much depends on the objectives of the exercise and the budget available. If the objective is to form an impression of the level of risk a whole organisation has that is as close to ‘true life’ as possible, then it would be useful to explore the level of discoverability the organisation has in an untargeted exercise. Clearly though, the time that such discovery tasks take will be charged by the testers, which means the budget needs to be larger.

Where the exercise is testing a single, distinct system, there is often little point in running anything other than a targeted test as the risk profile may not change at all depending on how easy or difficult it is to discover. For example, a system that controls the buying and selling of financial assets such as stocks and shares is a high-value target so needs to be strongly resilient to attack in all circumstances.

By way of another example, a company operates a popular consumer-focused web application: the fact that it is in the public domain and is popular means that the assumption should be that it, in its entirety, the web app is going to be discoverable.

Black-box, white-box and grey-box exercises

Penetration testing can be differentiated as black-box, white-box or grey-box testing.

Black-box testing is where testing starts with a broad description of the target, a confirmation of scope when requested and, depending on the circumstances and what threat simulation is being performed, a low-privilege user account’s login details. This last point particularly relates strongly to testing web applications. Black-box testing can lead to very creative forms of attack being formed; however, it can result in an exhaustive test being longer than other types.

White-box testing is far less adversarial and involves providing information that a legitimate attacker would not have immediate access to. This could include source-code, API (application programming interface) documentation, network diagrams, database access, firewall rule sets and so on. White-box testing is mostly used for distinct systems, rather than whole organisations, that are actively being developed, as it allows the developers to gain a high level of assurance on a particular product. White-box testing works well for finding difficult to spot technical vulnerabilities, such as certain types of SQL injection, and is often very time-efficient. However, for these same reasons, it can result in reduced consideration for how the features fit together and how the system or service can be used in a perfectly legitimate way to perform tasks that it was not designed for.

Grey-box testing is white-box and black-box testing blended together. This can be as simple as running a black-box test for the first half of the exercise and then a white-box test immediately afterwards for the second half of the exercise. It can also range to the very complex, where each request for information is considered based on the current circumstances and a decision is made to permit or deny the request. Depending on the circumstances, some form of blended exercise is the most thorough and gives the highest level of assurance – but comes with the largest price tag.

IPS, WAF and other active defence systems

Intrusion prevention systems (IPS), web application firewalls (WAFs) and other active defence systems such as port-scan prevention technologies, are methods of preventing known ‘bad’ actions from happening. They look for these recognisable actions and don’t just alert when they see them, but actually respond defensively, preventing the attack from happening.

These technologies are good ways to add to the level of security present in a given system; however, they are just an extra layer of security, not guaranteed safeguards. If these technologies are in place for a penetration test, the only discovery is how good the IPS, WAF or other security technology is, not how good the security is of the actual target. That is not to say that testing a system when it is behind one of these technologies should never be done, just that it should be understood and only done when it is appropriate.

It is probably inappropriate to test a system that is behind an active defence system when the system being tested is still actively supported by the vendor or actively being developed. This is because the test will likely result in many false-negative results, and will make it hard for the penetration tester to find the more advanced attack techniques. Furthermore, the test might actually take longer to complete the same amount of coverage: several of the active defence techniques involve blocking users who make large numbers of requests. This either forces the cost of the test up, or reduces the coverage of the target system. This describes the clear majority of systems: most tests should be carried out without any active defence technology in place between the tester and the target system.

There is one circumstance in particular in which it is appropriate to test with active defences in place: when the system cannot be upgraded or is no longer in active development and cannot be replaced or decommissioned. This represents a risk that the organisation is carrying and can do little about, so performing a penetration testing exercise against it in its strongest configuration will allow the business to better understand that risk.

Input from alerting and monitoring systems

Those companies that have greater information security maturity may have alerting and log monitoring systems in place. A penetration test is a good test of the incident response procedures followed when an alert is raised, but does not indicate that the alerting and monitoring itself is effective. This is because a penetration test is typically a very short engagement over a few weeks compared with a real attack that could take place over many months.

Expect alerts to be triggered in simulated exercises; if they are not then there may be a fundamental problem with the alerting and monitoring technology. Hopefully they will trigger, because what happens next is of most interest. The level of refinement and detail that you want to measure in the incident response will be dictated by the organisation’s incident response maturity; however the fundamental questions are:

SUMMARY

This chapter has discussed the importance of good penetration test coverage and what challenges may be faced in order to achieve it. The concept of test coverage necessarily touches upon topics strongly associated with scoping the test. Once that scope has been defined, it is important to get the penetration testing to achieve the coverage that is appropriate. While the commissioner of the test may not need to deal with the issues that can hamper good test coverage, it is vital that they recognise circumstances that may make it difficult to achieve, in order to be able to take any necessary action.

Similarly to test coverage, it is easy to fail to achieve the organisation’s penetration testing requirements by inappropriately simulating the threat. This chapter also discussed some of the constraints applied to penetration tests and how they can be modified to reduce the impact on the threat simulation.

REFERENCES

Doctorow, C. (2004) Microsoft Research DRM talk. Available at: https://craphound.com/msftdrm.txt

Radichel, T. (2019) Case Study: Critical Controls that Could Have Prevented Target Breach. Bethesda, MD: SANS Institute. Available at: www.sans.org/reading-room/whitepapers/casestudies/case-study-critical-controls-prevented-target-breach-35412

Schneier, B. (2011) Schneier’s Law. Schneier on Security, blog, 15 April 2011. Available at: https://www.schneier.com/blog/archives/2011/04/schneiers_law.html

Scholtz, T. and Heiser, J. (2013) ITScore for Information Security. Available at: https://www.gartner.com/doc/2507916/itscore-information-security