Given the importance of information security testing — including vulnerability scanning, vulnerability assessments and penetration testing — I find it interesting how little thought goes into the actual scoping of such work. Quite often, the scope of security testing has too many constraints.
Struggling With Scope
In large enterprises, for example, there’s often interest in conducting an external penetration test or perhaps focusing specifically on one or two core Web applications. That’s all fine and good. However, the problem is that the entire environment is not being fully assessed. In fact, I have worked in many large enterprise environments where a comprehensive security assessment has never been performed.
It’s often a similar situation in midmarket enterprises: They will want to do external security testing but perhaps not look at the internal environment. This goes for on-premises LAN/WAN systems as well as systems in the cloud.
If there’s any group of businesses that seems to do things well, it’s small businesses such as cloud service startups, health care providers and nonprofit organizations. Perhaps the tighter scope and smaller budget allow these organizations to look more closely at everything across the board.
At the end of the day, regardless of the organization’s size, that’s exactly what needs to be assessed: everything.
What Goes Into Security Testing?
There is no right or wrong answer to the question of how to perform ongoing security testing in your organization — unless critical systems and related business requirements are being overlooked. Unfortunately, I’m convinced that’s often the case.
Don’t get me wrong; I’m not naïve enough to think organizations have an unlimited budget to do the most thorough and comprehensive security testing. The economics of security don’t work that way. The problem that I’m seeing is that these organizations are claiming to be secure and signing contracts stating that they’re testing their environments. Yet what they are claiming hasn’t been done.
If you’re in charge of information security in your organization, you have to be careful about how you approach this. You don’t want to skim the surface of your environment, and you certainly don’t want to over-commit to doing everything if you’re not equipped for it. Know what you’re signing up for, what your committing to and for what you’re being held accountable.
Recommendations for Professionals
Make sure that there are checks and balances in place between those writing the requirements and running the project as well as others who are requesting that the work be done, such as auditors and management. If an outsider such as a consultant or security firm recommends that you do things a bit differently — perhaps adding in more systems to test or testing things in different ways to ensure that you get the best results — heed that advice. It could be that one nugget that ultimately prevents a breach down the road.
You have to ask yourself: What is my goal? Perhaps the goal is to determine whether specific systems or applications are secure. Maybe the goal is to ensure that all external-facing systems are in check. Or it could be to ensure that all systems are being tested so you can get a true measurement of your information risk. In all but the oddest of cases, it should eventually be the latter.
Read the interactive white paper: Preempt attacks with programmatic and active testing