If you complete pen and/or other testing, what are the impacts or outage risks, and what about additional items found and scope changes?
This is an excellent question and a key one to ask, both for Cyber Essentials and our other assessments, the external IP enumerations, unauthenticated vulnerability assessments, our ongoing monthly pen-testing solutions, and our internal pen-testing solutions.
EXTERNAL IP & SYSTEMS PEN TESTING
This is an interesting point, as whilst we request your authorisation via the order to test the external IP address and, of course, cover our testing within our T&Cs, it's all a bit irrelevant, really, as we are testing your externally exposed services, those that are on the internet and available to anyone! -- you know, available to anyone right now, yes, that is correct!
We NEVER aim to cause any issues, but any testing could result in an issue—that is EXACTLY WHAT YOU WANT AND NEED!
Thus, you are better off finding an issue and having our testing, whilst unlikely, cause a problem or an issue you need to remediate, as we will have only completed a scan, attempt to use what we found, and with a preference not to cause any problems, but, remember, this is your external facing service, so if we cause a problem, you have an even bigger one, as a script-kiddy, threat actor, hacker and alike, would have caused far greater devastation, and may have caused you irreparable damage or potential losses.
YOU NEED TO TEST AND HAVE ISSUES
In a perfect world, any testing will deliver you absolutely no results; that is what you are after: absolutely nothing found, nothing to deal with, and no risks; thus, in its appearance, there is no reason to spend any money on testing! - perfect, the result you want, but that is indeed what you want, but what if we were to find something?
We find something, whether it's just a "Heads-up" or impacts you briefly, is a "Heads-up that you have a significant issue!" which, if it wasn't us finding it, you could have suffered far more. So, you'll need to fix this now and make sure someone who isn't able to do what we've done to you is safe.
WHAT ARE YOU TESTING - THE SCOPE?
For your external testing, you provide us with the IP addresses for which we will scan, enumerate, and penetration test. Other than that, anything we identify (just as a script kiddy or threat actor would) is absolutely in scope!
You would not want this to be any other way!
If you don't want us to test something, don't make it available to everyone else in the world. If you do and don't know, fantastic; we will find it. If you do, and you know, then make sure you remove the global access before we test and keep it off in the future—it's your systems and your safety we are trying to protect by identifying weaknesses.
So, if it's available externally and globally, we will find it on your requested in-scope IP addresses and test it without regard (like an attacker) for what it may be or what may happen. This is absolutely a test, just like an attacker would complete, to ensure you are safe and secure.
INTERNAL TESTING SCOPE
In fairness, this is focused on internal systems and services, so you are being more prescriptive about what we are testing and, therefore, with the assumption that an attacker has to actually be on the network before they can leverage attacks. However, you are providing a scope to us, and we will address systems and services based on that scope; this may identify other issues, systems, services or risks that you didn't expect, but again, that is what an attacker (those you are asking us to check against) would leverage as well, so again, we should indeed check whatever we find.
Systems or services you have not spelt out to us that are found could be impacted by scanning (just as they could from an attacker), and surely that is what you are asking us to check. However, you can always ask us to avoid anything you need to avoid.
Significant and identified scope drift, additional devices, recommended scope changes, and similar will always be advised where we can determine in advance; likewise, additional testing identified during any purchased event will also be advised, all of which are your options whether to proceed with recommendations or not.
INTERNET OF THINGS / OPERATIONAL TECHNOLOGY
These are a significant risk to organisations and testers, as while they are a potentially easy route to break into a network, they are also the sort of device that may respond poorly to testing. It is critical that if you have IOT or OT devices in our testing scope, it is absolutely essential to let you be tested, and we know.
A scan could, for example, merely set a printer/copier to eject all of its pages (an Operational Technology Device—OT), which is annoying but not a massive issue. However, the same scan on a 100-foot-tall crane outside in the carpark that is now spinning around in circles after having been probed/scanned is somewhat more of an issue.
Therefore, it's essential to let us know the scope and be specific to ensure we stay within those boundaries. However, if something new and missed by you appears in scope, whilst we will always do everything possible to advise you before testing, testing may have hit the device, which we are unaware of, and have outcomes we are also, therefore, not in control of. Thus, you will have to address any issues after the fact.
Significant and identified scope drift, additional devices, recommended scope changes, and similar will always be advised where we can determine in advance; likewise, additional testing identified during any purchased event will also be advised, all of which are your options whether to proceed with recommendations or not.
CONCLUSION
If you request testing from us, we will ensure that whatever scope you have requested is tested to ensure its safety and security. You should always have a backup of any system and a process to recover systems in the event of any issue. Therefore, this is your responsibility and just good business practice. If you have any problems in testing, just imagine what may happen if you were a threat actor.
RANSOMS/BACKUP/RECOVERY: Why would anyone ever pay a ransom? You should have a backup accessible and air-gapped and ready to allow swift recovery to a Recovery Point Objective (RPO - the point in time you can live with recovering to) within the Recovery Time Objective (RTO - the time you are happy to wait to recover to the RPO), for any and every system you have in place. If you don't have your backups now (e.g. Microsoft Office 365, GSuite, Xero, etc.) that aren't relying on the vendor, and you are not happy, you can switch that system off right now and continue operations; you need to rethink your backup strategy/business continuity planning and risk assessment.
Testing a system's security may carry some risks, yes, but those are managed and reduced to the minimum possible. That, however, is not how an adversary/threat actor will work, so you both need and should require full testing to ensure you are safe and secure.