Scoping for your first security assessment
This post is part of a series and you might want to read Preparing for your First Security Assessment first.
Scope is the term we use to define what effort and where that effort is going to be directed. Determining scope is perhaps the most important component of setting up a successful first security assessment. Defining your scope too broad may mimic that of an attacker but might not be feasible for your budget. Too narrow and a tester may miss problems in vital application components. And perhaps most importantly, you don’t want business operations severely impaired due to testing.
In this post we’ll walk you through determining scope and effectively communicating that information to your security consultant. For clarity we’ll talk about scoping a collaborative (white box) application assessment.
The first step is to note all the components of your application. This includes publicly facing services and back-end, private services, as well as the underlying databases which support the entire application. A diagram of how all of these components work together may be beneficial. You’ll want to include metadata about each component, such as what language it is written in. It may also be helpful to document all of the REST endpoints and their parameters, especially for publicly facing services.
You’ll want to catalog your database schema and take account of what kind of data you are storing; in some cases, certain datasets may be off limits to testers, but mainly you’ll want to figure out the most sensitive data that your application stores and relate that to your testers. This will give your testers a goal as for what kinds of data they should put the most effort into retrieving from the application.
Sensitive data includes personally identifiable information (PII) such as name with date of birth, social security numbers, credit card numbers, bank account information, geospatial information (especially if its stored with a date time), health data (PHI), or any proprietary information that would negatively impact your business should it become public. That could include trade secrets or other intellectual property. Note that this data doesn’t necessarily need to be stored in a database. Image files, for one, could contain sensitive information. For example, an image of a prescription contains PII and PHI.
You should document where sensitive information enters the application, as well as where it exits (is displayed to the user), plus any locations where it is transferred to a third party service. These will be important to your tester.
Next you should look at areas of your application that perform destructive actions or have big side effects. This would include endpoints such as those that delete data permanently, overwrite pre-existing data en masse, or send emails to multiple people. You’ll want to note these endpoints so your testers know to be extra careful with them — or avoid them altogether. For example, contact us forms may send an email — a tester could end up sending hundreds of email to someone if they don’t know they should be careful when testing the contact us form.
Altogether, you should be able to hand your testers a document containing the server ip / hostnames for your application, a list of server ip / hostnames not to test (if applicable), a list of critical information your application collects, and perhaps a list of areas of the application not to touch. Additionally, it will be useful for testers to have a list of HTTP/REST endpoints and their parameters, if that information is available.
If you have an application that you have security concerns about the ^Lift Security team is here to help.
