Preparing for your first security assessment

Chances are if you’ve built a software product or service you’ll want to book a firm to perform a security assessment of your application or network.

Time is limited during a security assessment, and you want to get as much bang for your buck as possible. Doing a few simple things will help maximize the value you receive from the assessment. Preparations are in order, but do not despair — we are here to help!

Ensure the scope is properly set.

Check and double-check the scope of the assessment. Make sure everything that should be evaluated is included in the scope, and that anything you do not want touched is clearly denoted as such. Likewise, notify your testers of any critical portions of the application or network that could cause mass side effects or harmful effect on business operations.

This includes things like functions that will send emails to large groups of people, production databases that are mission critical, and so on and so forth. Additionally, you should document all of your exposed services so you know what services an attacker will be hitting.

Decide what level of insight the tester will have into your application or network before performing the test.

This is colloquially referred to as “blackbox”, “greybox”, and “whitebox”. Here is a breakdown of what that means:

Black: The testers have no knowledge of the internals of the application or network before beginning the test.

Grey: The testers have some basic knowledge of the internals of the application or network before beginning the test, but do not have full insight into every nook and cranny of the target.

White: Also known as collaborative testing. The testers have access to all available network documentation and / or source code going into the assessment.

There are pros and cons to each approach, and which avenue you choose will depend on the goals of your organization and the maturity of your network or application, as well as the resources available for the test. Grey or white box works well when time is limited and coverage is very important.

Decide if the test will be conducted against a clone of the production environment, or the production environment itself.

The trade off is that if testing is conducted against a clone environment there is no chance for the test to affect paying customers or business operations substantially. On the other hand, we’ve found that cloned environments are rarely identical to production environments, so there may be things missed due to misconfiguration issues.

Also, if you decide to conduct the test against a production environment, make sure you have solid data backups before the test begins.

If you opt to hand over source code or network documentation, make sure there are no secrets included.

This includes api keys, tokens, ssh keys, database passwords, or switch passwords. For an application assessment, including secrets is like giving the tester the keys to the kingdom and will result in your needing to revoke and reissue all the secrets. For network assessments, you’re giving a huge leg up to the tester by providing things like database passwords or switch passwords — which I assure you the tester will not mind — but it creates an overly unrealistic adversarial scenario.

Perform an internal assessment of your application or network before the test begins.

Even if this is only an hour-long exercise, it will catch so-called “low hanging fruit”, which will mean the tester spends less time on easily caught issues and can focus on more advanced techniques that more adequately model a persistent attacker.

For application assessments, you should also verify simple items such as

• HTTP security headers
• Cookie flags (secure / HTTPOnly)
• Check your dependency graph for out of date components
• Check your network for exposed network services other than your application

Now that you’re prepared to kick off your first security assessment, why not reach out to the ^Lift Security team and get a quote. We’ll guide you through the process and help you ship more secure software.

If you liked this post, stay tuned — we’ll have follow up posts that deep dive into each of the aforementioned areas in the future!