Penetration testing can be done well or done badly; this chapter explores how to do it well. We will cover what could be tested, some common testing methodologies that could be used, the documentation typically used to commission penetration testing, and the documentation resulting from the exercise itself.
WHAT IS MEANT BY ‘BEST PRACTICE’ AND ‘GOOD PRACTICE’?
Best practice is the broad term used by technologists to describe the best possible way of completing a task or overcoming a problem. The term suggests that there is a guidance document or manual somewhere that sets out the ‘one true way’; however, this is often far from reality. The exact definition of what best practice means in a given situation is often debatable and is mired in the context of the challenge at hand.
It is easy for best practice to become an overwhelming beast, expending effort on ever-increasing levels of detail to make the task at hand perfect in every way. However, when it comes to penetration testing, it is far more important that the test is completed and, based upon the results, the necessary corrective actions are performed, rather than attempting to design the perfect testing programme. With this in mind, it is often better to require ‘good practice’, as this can enable the testing programme to achieve great things, without the unending pursuit of perfection.
Good practice, within the management context of penetration testing, means maximising the results for the budgetary limits and other constraints you are working within. To achieve this, ensure that pragmatism is in mind, for example, by working through the following overarching tasks:
1. Work with asset owners and map the entire attack surface.
2. Either use an existing risk analysis or perform a very quick risk analysis of each of the assets.
3. Prioritise the assets by the level of risk perceived.
4. Do not delay – commission an appropriate test of the highest priority target.
5. Present the summary of findings at the highest level in the business.
6. Secure budget for correctional activities and testing the next highest priority target.
7. Take a breath – and repeat…
Good practice activities for penetration testing practitioners occur between points 4 and 5 above and will vary depending on what type of exercise has been commissioned. Choosing the right type of testing is fundamentally important to getting the right job done, as it does not matter what good practice the practitioner puts into place if it isn’t the right work in the first place. The main levels of testing services are: commodity; consultative; and full-spectrum Red Teaming.
Commodity testing services are about time and cost efficiency, which predominantly involve automated testing and will discover flaws considered as ‘low-hanging fruit’. Consultative testing services will strive to understand the target’s context, how the target actually works in the background, and will discover flaws that are only discoverable by putting all of the understood elements together. Full-spectrum Red Teaming builds on consultative testing, encompassing the entire spectrum of the organisation in one exercise; thus drawing on the flaws present on one target to attack another target.
There are some elements of good practice that all levels of testing services should have in common. For example: establishing clear and concise testing boundaries; establishing which in-scope systems are fragile and may experience difficulties following aggressive testing techniques; and ensuring the test is a fair representation of the system under scrutiny, whether that be regarding methods of sampling, or ensuring that no other security system gets in the way which could produce false-negatives.
BUILDING ON THE TESTER’S EXPERIENCE
Commissioners of consultative tests can lean heavily on the penetration tester to provide guidance and advice about how the penetration test will go, and how to get the most from it. They should expect advice regarding the breadth and depth of test coverage, what the results actually mean and ways that the testing programme can be improved in the future. They will probably also want advice on what corrective actions are possible, and how to fix the identified issues. After all, the penetration tester has invaluable knowledge of potential corrective actions as they have probably seen similar situations before, and they will have knowledge about how best to thwart their hacking efforts next time. This is a fairly common desire; however, there are a few problems with this.
First, defending and attacking computer systems take two very different skillsets and mindsets. There will be overlap, but the attackers are best placed to educate the defenders in how the attack was completed, not in the extreme detail of the configurations and methods of preventing the attack from happening again. Once the education is finished, the defenders should be able to perform the analysis required to determine the best course of action.
It is worth taking a moment to think about the consequences of asking the penetration tester for specific corrective actions though, as the tester might have a conflict of interest if they answer. Such a conflict of interest exists if the penetration tester ends up testing the work that they have been instrumental in implementing. This is similar in concept to a gamekeeper also being a poacher – the two roles can’t work together. As a result, most penetration testers attempt to maintain objectivity by helping with everything other than actually fixing the problem. Typically, the advice provided by the tester will be high-level, won’t include any product recommendations and will be more specific about any known pitfalls or possible undesired outcomes, rather than the way that it can be fixed. That said, sometimes there is only one way to fix the problem, in which case it is quite common to be given links for further reading online; for example, specific vendor guidance. Beyond this, any further advice may introduce bias into the testing process and will result in a loss of the objectivity provided by the penetration tester which is essential to the role.
The issue here, though, is that most organisations do not just want to be told that they have a problem – they want the solution as well. Understandably, this objectivity can be very frustrating, and can even damage the relationship you have with the tester. One of the best things to do in such a situation is to make it clear to the tester that there will be a rotation of penetration testers for the next time this particular target is tested; that way, they can feel less inhibited and give more specific advice. Although commissioners of penetration tests probably still won’t get product recommendations, it is always a good idea to test the solutions being suggested before putting them live. Generally, it is a good rule of thumb to employ separate ‘poachers and gamekeepers’ – that way, there can’t be a conflict of interest.
PENETRATION TESTING METHODOLOGIES
Penetration testing methodologies come in two main forms: a high-level approach to discovering and testing for vulnerabilities and weaknesses; and a definitive list of all the types of vulnerabilities and weaknesses that are known to exist. These two forms have significant differences when used to complete a penetration test. The most notable examples of these two forms are the Open Source Security Testing Methodology Manual (OSSTMM; Herzog, 2010) and the Open Web Application Security Project (OWASP) testing guide.1 The OSSTMM is a guide to those commissioning the test as well as to those executing the test but it leaves the specifics to the organisations and individuals involved to determine significant details about the tools and tests to be completed. The OWASP Testing Guide provides very specific details about the test actions that should be taken.
Penetration testing methodologies can be quite contentious. This is because some penetration testers see methodologies as constraining and an affront to their creativity when it comes to their expertise and tradecraft. Equally though, it could be argued that it is only through the use of industry-accepted methodologies that commissioning organisations can be sure of what they are getting and how it compares with any other penetration testing exercise. A good penetration tester naturally follows the good practice that is outlined by high-level methodologies. They fundamentally understand how to simulate threats, how to develop attack strategies and execute those attacks. If there is confidence in the penetration tester, having a detailed methodology is likely to be something that does not need to worry you too much. Similarly, the more prescriptive penetration testing methodologies can be a great checklist for penetration testers to ensure they have covered everything they should have, but experienced penetration testers will not need to lean on these so heavily.
It has been argued that detailed methodologies are a continuation of the trend for penetration testing to become commoditised. Commoditisation is a double-edged sword, in that it makes penetration testing more accessible, in a number of ways, to the large numbers and variety of organisations that require these services. Some individuals voice concerns that the other side of commoditisation, however, is that it assists inexperienced penetration testers to operate fraudulently within the industry who are unable to detect complex vulnerabilities. As such, it is important for the organisation to use a methodology that is proportionate to the situation and appropriate for the entire context of the penetration testing exercise. This proportionate approach appears to be supported by the UK’s National Cyber Security Centre (NCSC).2 The guidance that the NCSC publishes advocates that each testing company has a defined and documented testing methodology3 which requires certain testing and reporting elements be present in testing methodologies, but doesn’t prescribe the details of those elements. This allows the penetration testing provider to work within their own constraints and based on their own expertise and experience.
All penetration testing methodologies have at their heart a drive for a minimum quality standard, consistency and strong coverage. These are clearly desirable qualities and are what gets rightfully pushed by the standards and compliance bodies; however, the potential negative effects that overly detailed and prescriptive methodologies may have rarely get discussed. The following points should be considered when deciding to what depth a methodology should go:
• A detailed methodology could reduce the opportunities and motivation for the penetration tester to use their expertise. This could occur if the requirements of the methodology encourage use of basic tools and techniques and therefore allow for a poor job to be completed. Or perhaps, the methodology requires significant effort to achieve ancillary tasks while not actually getting results from the testing itself.
• A detailed methodology could well raise the minimum standard, and it might well result in consistent penetration test results, but that is the minimum standard, and may not be the standard deserved by the sensitivity or magnitude of the system and organisation being tested.
• Consistency and a minimum standard might still be a useful requirement, for example, if the organisation is paying for less-experienced or junior consultants and they want assurance that a minimum level has been achieved, or perhaps if two products are being compared before one is to be chosen and implemented.
In theory it would be possible to write a penetration testing methodology that solves all of these problems and forces a high-quality, consistent test to be completed with strong coverage. However, such a methodology would be time-consuming and difficult to achieve. It could be that the organisation can have their consistency without losing that expertise-led investigation and get the best of both worlds. Unfortunately, this approach fails to realise that penetration tests are almost exclusively time-bound exercises and it is often not possible to satisfy both of these qualities. The organisation must understand these trade-offs and choose the approach based on its requirements.
There are circumstances where having a detailed methodology isn’t optional. Perhaps the organisation has a client-assurance, compliance or legal reason for mandating a particular penetration testing methodology or level of depth that a methodology must achieve. One such example would be where the organisation is required to be compliant with the Payment Card Industry Data Security Standard (PCI DSS).4 In such a case, the sales process should have identified this and the test provider will be allocating penetration testers that know how to work with the requirements. The good news is that most requirements to follow a methodology, including PCI DSS, are relatively flexible, stating that the methodology must be ‘industry-accepted’. There are a few caveats here, because for example, PCI DSS does specify some small but very significant parts of the testing methodology, such as what is in scope and that boundary tests must be completed.
In the case of PCI DSS, the penetration testing methodology is the responsibility of the organisation being tested. That doesn’t mean the organisation can’t have assistance in creating it, but it does mean that the penetration testers are not responsible for validating that it will achieve the desired compliance goals. Even though the methodology is made specifically for a particular scope, that doesn’t mean it can’t be an industry-accepted methodology. In practice, the methodology must achieve industry acceptance by being able to stand up to scrutiny and critical evaluation. The onus is on the organisation being tested to take responsibility for its methodology because PCI DSS recognises that each environment is different and it is best known and understood by those that operate it. This is obviously a good idea as it should prevent any gap in coverage; however, in practice, many organisations struggle creating the methodology on their own and may enlist the assistance of the PCI QSA (qualified security assessors) or penetration tester. Expect to add a day or two, or maybe longer depending on the size of the environment, where assistance is taken from the QSA or the penetration testers before the penetration testing exercise.
DOCUMENTATION BEFORE, DURING AND AFTER A PENETRATION TEST
In this section we will look at the documentation and reporting activities that should be completed at various stages throughout a penetration testing lifecycle. This will include documentation that is needed for the commissioning process, final authorisations so that testing can get under way and in what form the exercise will be reported back to stakeholders.
Exercise build-up (before)
Exercise requirements questionnaire
Many testing consultancies like to formally try to capture the test requirements and the size and type of the exercise before they do anything else. Sales people particularly like this as it gives them a structure which they can follow while still getting the information required by the testers. It also means they have an excuse to communicate with the prospective client which inevitably means they can apply the art of relationship building. Smaller companies might not bother with this stage as the tester might be directly involved with the client from the beginning, in which case, they will understand more than a scoping document could record within a half hour conversation.
This is a stage that is not to be confused with the formal penetration test scope. Often the information assimilated at this stage will be used as part of that scope, but it will also try to collect information about the nature of the service which will help the provider when estimating the amount of time and effort that will be required to complete the work.
The proposal
Also known as a quote or formal test scope. This document sets out what the testing vendor is going to provide, exactly which systems or set of systems is in-scope, when and how long the service will be, the approximate outcomes and, finally, the cost. If there are any specific data safeguarding requirements they may be documented within the proposal or the contract. For example, the penetration testing vendor might keep evidence for a set period of time, or store it with certain security controls.
The contract
This is a standard business contract in most ways, though there will be some extra bits of note. Mainly, the additions are present owing to the fact that the activities carried out as part of a testing exercise are illegal to perform. According to the Computer Misuse Act 1990 there are four associated criminal offences:
1) unauthorised access to systems; 2) unauthorised access to systems with the intent of committing or facilitating further offences; 3) the unauthorised modification of computer material; and 4) making, supplying, or obtaining articles for use in breaking into computer systems.5
To perform any modern testing services, a tester will almost certainly break all four.
With 1) it can be argued that it is very difficult to give permission for the tester to access something when the method of access and the specifics of what is being accessed cannot be defined until after the exercise, and worse still, that the recipient of the exercise does not understand the tasks being carried out.
With 2) lateral movement is a very common tactic among real attackers and should be simulated whenever appropriate; as such the tester is aiming to commit further acts of hacking.
With 3) simply by using a system the user makes changes to computer material, performing invasive tasks such as a penetration test can make much larger changes.
With 4) most penetration testers come fully armed, either with tools and exploits acquired from the internet, or with tools and exploits they have created for specific purposes and vulnerabilities, or indeed create tools and exploits based on the systems which they find themselves attacking.
To make this more complex, there is no distinction in the act which allows information security professionals to perform the activities prohibited by the law. To make this legal problem go away, there should be a section within the contract that references these laws and specifies that the signing party agrees to indemnify the testing consultants for the purposes of performing testing services.
Authorisation to test form
It is common for this special law-avoiding part of the testing contract to be extracted into a stand-alone agreement as, in most circumstances, this will need to be re-signed for each exercise, showing an ongoing understanding from the client and to tie this understanding to a specific exercise.
Exercise briefing (during)
Payment Card Industry (PCI) penetration testing methodology
The PCI council now requires organisations being tested as part of a PCI compliance effort to have this document and use it in relation to penetration tests. Strictly speaking, this document should be provided to the tester and sales people by the client in order to ensure that they receive the correct testing, and to confirm the scope of work. It is not uncommon, though, for the test service provider to help the client understand what is required of this document, and to help them write it at the beginning of a penetration test programme.
In this situation the testing parts of the exercise will be shorter than originally designed, or the bill will be larger owing to the extra time spent on the work. It is also important to realise that the penetration tester may not be qualified to advise on the testing methodology: it might be advisable to get this document signed-off by the PCI QSA as, ultimately, this is the individual who must be convinced that the penetration testing was adequate.
Target list
This usually only applies if the target is public or resides on shared infrastructure. The testers need to make sure they are conducting their tests against systems that belong to the client organisation. Depending on the details of the test, this might not be required at the very beginning of the programme: for example, the first stages might be reconnaissance. Once the tester is ready, they might submit their reconnaissance findings and get the client to compare the actual scope with their discovered scope and confirm any differences.
Alternatively, if reconnaissance is not necessary, the tester may require a confirmation of scope at the start of the exercise – even if this has previously been discussed. This is because enterprise IT systems are increasingly fluid in their design, particularly since the advent of cloud computing. A final target list that confirms the scope of the test also prevents the tester inadvertently testing a bystander.
Notification of vulnerabilities
The people responsible for commissioning penetration tests can be quite nervous about the outcomes, as can the penetration testers and the penetration testing consultancies. A common scenario is where clients ask to be notified of vulnerabilities the moment they are identified. Unfortunately, this can be quite disruptive to testing, particularly when consultants have a limited amount of time. The easiest, though slightly risky, option for the penetration tester is to simply carry on with the task at hand and wait till the formalised reporting period. The designated time in a penetration testing exercise for reporting is often at the end of the penetration testing exercise. The client and the penetration testing company may find this unacceptable, depending on their respective risk appetites. Lots of penetration testers also don’t want the responsibility of knowing about issues that have not been reported to the client and that could be easily exploited at any moment, but find that the time pressures on the penetration testing exercise make it difficult if not impossible to report findings earlier.
In the majority of circumstances, a balance must be struck which identifies which criteria of vulnerabilities are reported upon discovery, and which are kept until the normal reporting schedule. For example, an agreement could be made that only vulnerabilities of 8.0 and above on the CVSS (Common Vulnerability Scoring System6) are reported immediately. This scheme has its own challenges though, as to be able to comply with this agreement, the penetration tester would have to calculate the score of every vulnerability as they go along.
Scoring or determining the qualities of vulnerabilities as they are found is an administrative task and any such task breaks the flow of penetration testing. Disruption to testing can impair the quality of the results which should be avoided where possible, but also more likely means that these tasks simply get forgotten in the heat of the moment. Experienced penetration testers have a gut feel about where a vulnerability’s score or other determining qualities lie, which will guide them to whether they need to take action or not. Furthermore, some vulnerabilities are very obviously at one end of the severity scale and so need little thought to determine if they deserve client attention. If you have faith in the professional qualities and experience of the penetration tester, it may be better to have a loose arrangement in place that leans on their experience about whether or not a given vulnerability requires immediate notification.
To make matters more complex, when there is the discovery of something serious, it is all too tempting for organisations being tested to want to immediately take corrective action. However, the discovery and exploitation of some vulnerabilities expose additional flaws and items of concern. If corrective action is taken it may not be possible to discover such additional flaws and as a result the organisation may end up remaining vulnerable in some form without knowing it. This means it is vital for careful consideration to be made about how to proceed if a vulnerability is reported.
Exercise debriefing (after)
The report
This is ultimately what the client pays for. It is a document that should reveal all the skeletons in the closet and tell it like it is. Reports differ according to the exercise conditions and the depth of service commissioned: some reports are a table of results, others are just an executive summary, and others still, demonstrate all the tactics, techniques and procedures used in order to obtain the results of the exercise. The decision about reporting will be borne out of the motivations behind the penetration test; for example, client assurance, internal audit, project and product development, and so on.
Presenting the report
Given that the report is the most valuable part of the exercise to the client, make sure the delivery of the report is understood. It may be important to get more than just an email; for example, it might be beneficial to get a debrief meeting where the contents are discussed and where questions can be asked; and that debrief meeting can be more effective when it happens in person or in front of the team responsible for corrective actions.
Vulnerability scoring the report will probably involve some form of severity, risk or vulnerability ranking. Consider any specific requirements for this element of the report. For example, does it need to use the CVSS? It might do if you have a client that expects such a scoring system for its understanding and use, or if the report needs to comply with regulatory or other contractual requirements. Different scoring systems take different amounts of time, so this might add to the cost of the exercise.
Some clients find vulnerability scoring difficult to understand and to appreciate. Interestingly, there seems to be equal measures of clients asking for the ratings to be increased versus those asking for them to be decreased. Almost invariably, the cause for the drive to change the score of a vulnerability is rooted in whatever political event has led to a security testing exercise to be performed. It is worth asking questions about scores that are not understood; however, I would caution those who are trying to change a score to ask themselves the question – why am I trying to change this? When there is an answer to this question, be open and honest with the tester as they may be able to help in any number of ways.
Evidence and appendices
It is possible for the testers to gather a large amount of data during their activities. Some of this data might be useful when trying to perform corrective actions. For example, it is possible to get copies of usernames and passwords that were cracked when subjected to cryptanalysis.
Think carefully about evidence and how it needs to be treated. There are several factors to consider:
• Should the test service provider destroy all data and evidence collected? If so, how soon after the test programme has completed?
• Are there any uses for the test evidence by the teams that means the company needs to be given a copy of it?
• Is it wise for the data to be kept by anyone, for example copies of people’s payslips or other personal data (there may be conflicts of interest)?
• How dangerous is the data? For example, having a list of everyone’s username and password means that until those users change their password, whoever holds that data could be held to blame for any wrong-doing that those accounts are associated with.
• If the data is useful, but the risk is above a comfortable threshold, is there another way of getting the same benefit? For example, could an alphabetically sorted list of the usernames that had their password cracked, and an alphabetically sorted list of the passwords that were discovered be suitable? This way, trends can still be seen, but the usernames and passwords are disassociated from each other, making the data less dangerous. Alternatively, does the evidence need redacting in places to protect the individuals? For example, if a cache of passport scans is found, should the names and other personally identifiable information be removed before they are entered into any report or appendix?
• How should evidence be presented? Would a raw copy of the data be most useful, or perhaps a catalogued appendix?
Evidence can be used within reports to demonstrate impact. The selection of evidence to do this needs to be in relation to the objectives of the exercise and the context of the organisation, and ultimately it needs to reflect what was actually obtained as opposed to hypothetical achievements. There is nothing more effective at rendering the results of a test inert, than a hole being picked (no matter how inconsequential) in the evidence submitted within a report.
PENETRATION TESTER TRAVEL AND BEING AWAY FROM HOME
Owing to the current worldwide shortage of penetration testing consultants, there is a very strong chance that the testers will have had to travel a reasonably long distance in order to attend the site of the test. This has several knock-on effects both on the testing exercise and on the tester personally:
• General fatigue – no one, including testers, ever sleeps as well in a hotel as at home.
• Bad back (i) – testing consultants end up packing every piece of equipment ‘just in case’.
• Bad back (ii) – meeting room furniture is fine for a couple of hours, but not for days on end.
• Extra cost – the client will likely end up paying for extra time, covering travel and their expenses.
To help the tester maintain the best level of efficiency, it might be appreciated if it is indicated that, at their discretion, the maximum amount of testing that can feasibly be performed remotely is preferred. This will allow testers to recuperate with family and friends in the evening, catch-up with the post that inevitably arrives when they are away from home and eat normal, ‘real’ non-restaurant food (a surprisingly common desire for travelling testers).
TEST TEAMS VERSUS INDIVIDUAL TESTERS
The testing exercise might be large enough to justify the use of a small team. Wherever possible, this is recommended, because the testers will be able to discuss problems with each other. Having the ability to talk directly to another tester enriches their abilities and enables them to come up with creative concepts and potential avenues of attack. Better still, when in a team, all this verbal communication can be completed without having to redact the content for fear of giving away client details, which might be required with other forms of communication such as plain-text emails.
Don’t worry if the exercise is just too short to justify the cost of a small team. Where this is the case, exercises tend to be of a low enough complexity that no significant benefit would be achieved by working in a team anyway.
THE CLIENT BEING INVOLVED IN THE TEST
Penetration testing is quite an exciting concept for managers and techies alike, particularly when it is new to an individual or to the organisation. This can often lead to a desire to watch every moment and have regular meetings and debriefs and hear about the latest exploits. As a tester, this is flattering, but is also a worry. Inevitably, the sales process has determined a number of days to complete a job and, regardless of how that number of days was established, the job needs to be completed to deadline. Unfortunately having an extra shadow or techie-soulmate can make this challenging because the discussions that take place absorb a surprising amount of time.
The truth of the matter is that penetration testing can actually seem rather boring to spectators. That is because a large proportion of what a tester tries to achieve does not actually work; after all this is the point: testing to find out whether something can be used in an unexpected way and most of the time it cannot. Hacking is not like it is depicted in television shows or movies, there is no magic button that immediately lets the adversary ‘in’. Sitting alongside the penetration tester while they are working could well just make them feel nervous and probably gives them stage-fright. It is a common observation among techies that the moment anyone is watching, the typing abilities of the person at the computer evaporate.
Even if the testers don’t have a permanent companion while they are working, having regular debriefs with them can disrupt their flow and make it difficult to remember exactly where they were up to. It can also interrupt at a critical, time-sensitive moment as the penetration tester is always going to give the client the attention they request. Both ultimately absorb precious time. It is rare to find a penetration test where there is no more testing to be done or new attack methods to theorise. It gets worse than this, though: if a penetration tester is being asked to give an update every couple of hours it can come across as betraying a lack of confidence in their abilities. From personal experience, it is often a very positive sign when the customer wants to join in with the geekiness; however, it is possible to have too much of a good thing. To get the most out of the penetration testing exercise it is a good idea to formally schedule one or two debriefs as a task at the end of the exercise. For example, have a debrief just for the organisations’ techies and a second one for management. This is where the tester can walk you through everything they have found, or give live demos, and answer any questions as well as present new ones. The two different audiences will be interested in different parts of the process and have different questions, so to be time-efficient it may be a good idea to separate the two conversations. There may also be sensitive questions that are best asked with few others to hear. These debriefing decisions will be entirely down to the operational characteristics of the organisation, though the experience of many penetration testers shows that, wherever possible, a good balance of stakeholders and a healthy level of openness breeds better results.
It is really important to maintain enough distance so that the objectivity of the penetration tester isn’t compromised. Penetration testing exercises are usually performed to give the client organisation or third parties a level of assurance on the system’s information security. If the organisation is too involved in the penetration testing that objectivity quickly erodes, which seriously diminishes the value of the testing exercise.
Larger organisations might want to formalise their involvement in security tests in advance, but smaller organisations may not see any requirement to do so. There is no right answer, as each organisation will know what its own requirements are and the context of this particular penetration testing exercise. However, it is vital that the implications of being actively involved are understood so that the adverse effects are compensated for or accepted where necessary.
Penetration testers are humans too. Health and safety is really important for all employees, contractors and consultants regardless of where they usually work and what they usually do. This applies just as much to penetration testers as anyone else and it doesn’t matter who is legally responsible. At an absolute minimum, the client has a moral responsibility to ensure that the penetration tester is well looked after and not put in any short-term or long-term danger. Don’t just think of this as whether or not the penetration tester needs to wear a hard-hat in any warehouses, but also whether the desk and the environment is suitable where the penetration tester will be for the majority of the time.
In this chapter we started off by examining the difference between ‘best practice’ and ‘good practice’, and how good practice is almost certainly good enough. We identified that while best practice is an honourable aspiration, it can be very difficult to achieve and as a result may slow down or stop a penetration test from happening. We then continued with this theme, looking at ways of making a penetration test more successful by harnessing the pragmatic. We discussed how the client being heavily involved in the test is not necessarily conducive for getting good results and that instead a balanced approach is much better. We also looked at what good practice means when it comes to the various elements of paperwork that will be required and created throughout a penetration test exercise.
Herzog, P. (2010) OSSTMM 3: The Open Source Security Testing Methodology Manual. ISECOM. Available at: www.isecom.org/mirror/OSSTMM.3.pdf