Most of us would agree that planning ahead beats reacting to developing and unexpected situations. The nice thing about security testing is that it isn’t hard to plan for. Even if you aren’t able to schedule a test right now, you can start preparing for when one is needed. Let’s take a look at a few things you can do right now to prepare for an assessment.
Defining the Purpose of Security Testing
I know this one sounds kind of self explanatory, but you really do need to think about what the purpose of your testing is. Obviously, you want to improve the security posture of your organization by finding and fixing vulnerabilities. You definitely don’t want an attacker to find them first. You also need to find out if you have specific requirements for security testing. If you are handling payment card data, then you are required to perform vulnerability and penetration testing. You may have internal and/or external compliance requirements for third party testing.
You need to define the aims of your security testing because you will probably have specific reporting requirements for each interested party. Companies that are required to receive annual audits for PCI frequently have two versions of a penetration test report. One is for internal use and the other is for the auditor to review. You need to make sure that you are providing only the information that the auditor needs and not oversharing. Oversharing results in the auditor deciding that they need to review out of scope systems because they saw something in a report.
Determining the Type of Security Testing
Next you need to determine what type of testing you need to have done. Do you need a vulnerability assessment or a full penetration test? (More on this to come in a future post.) Do you have web or mobile applications that need focused testing? Or would a general network penetration test be more appropriate? You need to make a list of the assets that should/must be tested. As you go through this process you might end up finding applications or network subnets that you didn’t even know existed.
Knowing what needs to be tested makes it much easier for you to decide how to structure testing. You can build testing scenarios that more accurately represent the risks your organization faces. Sure you can have a generic penetration test performed, but wouldn’t it be more effective if you could tailor the test for your needs?
Setting the Frequency of Assessments
Determining how often to test is also important to your security program. Security testing should be performed enough to keep a reasonably accurate view of your security posture. You don’t want to over do your testing though. If you are constantly getting hammered with the results of a test, then you and your team may become demoralized. That’s counterproductive and just no fun.
First, look at your requirements for security testing. What are the drivers behind testing? What reporting deadlines do you have? You need to make sure that you are hitting those targets. It’s extremely frustrating for the you and your security testing firm if you are up against a short deadline. Your testing firm(s) may already be scheduled and not have availability for you. You end up stressed out trying to get some kind of testing done in the required time, but do not end up with the test you really need. If audit will be looking for your penetration test report in September, then start making arrangements for your assessment in May or June. This will give you plenty of time to design and schedule the test.
Once you have the deadlines in hand, you can start to figure out your frequency. You may decide that you need a third party network penetration test performed annually. Then an internal team can conduct monthly vulnerability assessments. If your production web application goes through three major releases each year, then you may want to have each release tested prior to launch. You can also decide when the application security test will need to be done and which environment it will be tested in. You and your penetration testing firm can then schedule accordingly.
Who Needs the Data and How To Deliver It
You will also need to decide who will need access to the findings of the security testing. A good assessment report should include a well written, brief summary for management. The executives need to know (at a high level) what was found, what the risks are related to the issues and what it takes to fix them. They rarely care about technical details. So get them the information they need to make the risk decisions and be ready with supporting material if needed.
The systems administrators will need more technical information. They will need to know which systems had issues, what were the vulnerabilities and an idea of how to fix them. Frequently this can be done by fixing configuration or installing updates. Using your existing ticketing system is probably the most appropriate way to communicate this information. If you have software developers, then you’ll need to also get them the data they need to code fixes. Their defect tracking system is probably the best place for this data.
If your company has never done security testing, then be ready for bad news in the first round of testing. It’s usually shocking to people when they see the evidence of how bad things are for the first time. Don’t panic! Let everyone know that this is normal for initial testing. If they expect bad news from the outset, then it’s much less demoralizing later.
The ideas in this post aren’t new or earth shattering. However, it is important to go through this process and document what you find. You will have most of the information that a consulting firm will need to scope a test. You will also have the information needed to make your case for budget. Getting budget is always difficult and you may not get everything you want. However, you will be able to present what needs to be done and why. Finally, you will be able to structure your assessments to be more useful to your organization.