You must use penetration tests and vulnerability assessments on your service to make sure it’s secure.Vulnerability assessments help you find potential weaknesses in your service. Penetration tests proactively attack your systems to find weaknesses and help you understand how easy they are to exploit.You should carry out both frequently as you build, not as a one-off check. You should begin testing before you enter public beta.Government continually reviews its security policies. Check this guide regularly or to hear about changes to technology content in the Service Manual.You can also read the. What to testWhen you’re testing for vulnerabilities, your testing scope should be wide enough to include the whole system and not just the software involved.For example, a wide testing scope could include:.
the security of the place where you keep equipment. the interaction between an online system and a contact centreIt’s important for the service to make sure that people can’t use offline information to exploit an online system. An example of this might involve getting a contact centre team to change a user’s email address, then using a forgotten password function to access that person’s account.You must get explicit consent from any third-party supplier if you use their software and want to review it as part of your test. Check your legal contract to confirm you have consent. When to test your serviceYour team should regularly assess your service’s security, especially during major changes to your codebase (for example, when introducing a new dependency or integration). Working with third partiesYou should use a third party to test your service before it moves into public beta or uses real user data. They can help you make sure that your internal testing is good enough, but you shouldn’t rely solely on third-party testing.
How to find a third partyIf you choose to use a third party, you should use a or staff accredited to to carry out penetration testing.You can also find certified companies through the or through theIf your service handles data classified as SECRET or TOP SECRET, to find out if any special testing requirements are needed. Testing third party systems or softwareYou must agree the details of any third-party penetration tests with your security and legal team, for example:. when the tests will happen. whether they should focus on staff-related vulnerability, as well as system vulnerabilities. whether you have permission from your third-party supplier to look at their systems or servicesYou might also choose to whitelist a group of the third party’s IP addresses.
Marking them as trustworthy means you won’t mistake their work for a genuine malicious attack (unless the test is designed to test your reactive capabilities).Your agreement with the third party should include confirmation that they’re not liable for any disruption to your service and will stop their work immediately if it does disrupt your service.After the test, the third party should produce a report that explains how severe the weaknesses are and how easily they can be exploited. They might also provide recommendations on how to protect your service from malicious users. Handling security reportsWhoever did the vulnerability assessment and penetration tests should produce a report after every round of tests to explain what they did and what they found. This should be shared with the technical team, service owner and any senior managers that need to understand risks to your service.The report summary should explain the risks in language that a non-technical audience can understand. The rest of the report should contain enough detail that your technical team can review and prioritise actions to fix any issues that have been found.
Building security capability in your teamYou should aim to increase security understanding and capability within your team. Running vulnerability assessments and penetration tests yourself is cheaper and can be done more regularly than relying on a third party.Your team could include experts such as ethical hackers, security engineers or penetration testers to help keep the service secure.Find out. Increasing automated testingYou should try to automate as much of your testing as possible to find basic vulnerabilities, such as features exposed to SQL injection.There are several open source or commercials tools you can use to test the security of features, for example you can use:.or for static analysis.for input fuzz testingYou should also aim to use to find vulnerabilities in your service that could be exploited by more advanced attackers.If you aren’t sure which tools to use or what to test, speak to a security expert in your organisation or a qualified third party. Get testing adviceYou can to get standards and advice on information security.If your tests find vulnerabilities that affect other services or organisations, contact their security lead or pass the information to the NCSC.
Related guidesYou may also find these guides useful:.
.There are many views on what constitutes a Vulnerability Assessment versus a Penetration Test. The main distinction, however, seems to be that some believe a thorough Penetration Test involves identifying as many vulnerabilities as possible, while others feel that Penetration Tests are goal-oriented and are mostly unconcerned with what other vulnerabilities may exist.I am in the latter group, and what follows is my argument for why you should be too.Language is important, and we have two terms for a reason. We already have an (aptly named I might add) security test for compiling a complete list of vulnerabilities, i.e.
A Vulnerability Assessment. If there isn’t a clear, communicable distinction between this test type and a penetration test then we shouldn’t be using separate terms. Such a distinction does exist, however, and it’s a crucial one.Vulnerability Assessments are designed to yield a prioritized list of vulnerabilities and are generally for clients who already understand they are not where they want to be in terms of security. The customer already knows they have issues and simply need help identifying and prioritizing them.The more issues identified the better, so naturally a white box approach should be embraced when possible. The deliverable for the assessment is, most importantly, a prioritized list of discovered vulnerabilities (and often how to remediate).Penetration Tests are designed to achieve a specific, attacker-simulated goal and should be requested by customers who are already at their desired security posture. A typical goal could be to access the contents of the prized customer database on the internal network, or to modify a record in an HR system.The deliverable for a penetration test is a report of how security was breached in order to reach the agreed-upon goal (and often how to remediate).A good analog for this is a Tiger Team working for the government, like used to run with Red Cell. Think about what his missions were: things like gain control of a nuclear submarine and bring it out into the bay.So imagine that he’s getting debriefed after a successful mission where he broke in through the east fence, and someone were to ask him about the security of the western side of the building.
The answer would be simple: We didn’t even go to the west side. We saw an opening on the east-facing fence and we went after our target.If the person doing the debrief were to respond with, “You didn’t check the other fences? What kind of security test is it where you didn’t even check all the fences?”, the answer would be equally direct: Listen, man, I could have come in a million ways.
I could have burrowed under the fences altogether, parachuted in, got in the back of a truck coming in–whatever. You told me to steal your sub, and that’s what I did. If you wanted a list of all the different ways your security sucks, you should have hired an auditor–not a SEAL team.Another mistake people make when discussing vulnerability assessments vs. Penetration tests is to pivot immediately to exploitation. The basic narrative is: Finding vulnerabilities is a vulnerability assessment, and exploiting them is a penetration test.This is incorrect.Exploitation can be imagined as a sliding bar between none and full, which can be leveraged in both vulnerability assessments and penetration tests. Although most serious penetration tests lean heavily towards showing rather than telling (i.e.
Heavy on the exploitation side), it’s also the case that you can often show that a vulnerability is real without full exploitation.A penetration testing team may be able to simply take pictures standing next to the open safe, or to show they have full access to a database, etc., without actually taking the complete set of actions that a criminal could. And vulnerability assessments can slide along this scale as well for any subset of the list of issues discovered.This could be time consuming, but exploitation doesn’t, by definition, move you out of the realm of vulnerability assessment. The only key attributes of a VA vs.
Vulnerability Assessment And Penetration Testing Companies
PT are list-orientation vs. Goal-orientation, and the question of exploitation is simply not part of that calculation.It’s also inaccurate to say that penetration tests always include a vulnerability assessment. Recall that penetration tests are goal-based, meaning that if you achieve your goal then you are successful.