Three key questions to ask when scoping your project

The saying goes: if you fail to prepare, you are preparing to fail. This is also true for any security project – if not properly mapped out, it is unlikely to achieve its aims. Even worse, the organization will have spent time and money to be left with unanswered questions or a false sense of security.

Unfortunately, due to time constraints or a lack of resources, project scoping is often neglected. However, proper scoping is not difficult or arduous, but a simple process to highlight the key information needed for project success. It is neatly summarized by three key questions to ask at the start of any security project – the necessary what, why and how of testing.

1. Why has the project been initiated?

In other words, what is the business context behind why your organization has decided to undertake the project? This question is critical as the answer will affect the assets that are targeted in the test, the methods used to actually do the testing and the format of the deliverable once the project is complete.

For example, imagine your organization is concerned about a particular technology on your estate, or a specific part of your network, such as the security of your log-in page. You might go to a security vendor and commission a mobile security assessment. Although the security vendor would indeed test the log in page, if no vulnerabilities are found they may not mention it in the final report without this being highlighted at the initial scope, meaning you’d be left unclear on the key question behind your test.

Alternatively, the project may be to support a certain compliance requirement. This would certainly cause the final report to be presented in a compliant format for this purpose. One other initiator could be a publicized cyberattack on a peer or competitor, which triggers an investigation into whether your organization would also be vulnerable to that style of attack. Again, this would affect the test attack paths and format for the deliverable report.

2. What are the business-specific critical assets?

It’s important to understand what the critical assets are for your specific organization. These are assets which are essential for ongoing business continuity, and an attack on these assets would be the most damaging for the organization. For example, these may be the business intellectual property, payment information or client personal details.

However, no two companies are the same, and often the assets can be surprisingly varied. For example, the telecommunications industry puts a higher value on availability compared to other industries, as a long period of downtime can even cost them their license. The same is true of financial institutions, who can face fines for services being unavailable. Without understanding what the key focus is for the project, the test may be focused on other important, but lower priority assets and miss the point of the test itself.

3. How would an attacker reach the assets in question?

Now we know why you want to test your security and what the most important assets are, we need to understand the routes an attacker could take to compromise those assets. In other words, what is the level of exposure for the assets? Can they only be targeted through internet-based attacks? Or would they be more vulnerable to an internal threat?

It may be that there are multiple routes to the assets – for example your organization may be under the impression that client personal details are only accessible through the website. Investigating this question at the scoping phase may reveal that this information is also accessible by going through your internal network. This may affect how an attacker would move along the kill-chain to reach the asset. This allows you more visibility of what you are testing, and how to apply the test results. In some cases, this could lead you to expand your scope to cover more attack paths.

However, if there is an extreme risk of one route being exploited, but a lower risk for another, you may choose to only test the most likely route. To use an analogy - the likelihood of being in a car accident and having a minor injury is far higher than being fatally struck by lightning. You’d still be aware of the less likely vulnerability even if you chose not to test it during the project. Therefore, your organization has clarity on the most likely route as well as the untested vulnerabilities and associated risk, and is not left with a false sense of security.

The MWR way

Established to provide accuracy, relevance and quality to our clients, MWR’s delivery process sets us apart from other leading security firms. Our delivery managers are involved from the outset of each project to ensure consistency from the scoping stage to the final deliverable report when the project is complete. Project scoping is initiated for each and every test in order to determine, at the outset, critical information such as key assets, business context and known vulnerabilities. Such information better informs the subsequent test, ensuring accurate results that are of strategic relevance to the particular organisation’s infrastructure.

MWR InfoSecurity provide specialist advice and solutions in all areas of cyber security, from professional and managed services, through to developing commercial and open source security tools. More about MWR.