What would be a good way to create a security testing schedule?

Question

I've been tasked with creating a formal security testing schedule / calendar for our organisation's applications, as most of our current testing (scans, pentesting, etc) is done ad hoc.

I'm wondering if anyone has created something similar for their organisation, and what process was used in order to build this schedule.

My current thoughts are the following:

1. Create a list of applications arranged into criticality categories based on the function they provide / consequences of successful attack (e.g. mission critical, critical, non-critical)
2. Determine what needs to be determined for each criticality level through testing, and determine which tests will be done for each (e.g. Red-team testing only done on mission critical).
3. Determine the regularity of tests and types of tests for each criticality category.
4. Create a testing schedule.

I've not had much opportunity to think about how often tests / types of tests should be done, so I'm very open to referrals to material I could review to get a better understanding.

Answer 1

"Testing" only won't do it.

1. Risk Assessment

Frequency: Bi-annually

• Document information assets (systems, networks, infrastructure components, etc.)
• Identify threats to those assets (vulnerabilities, attack vectors, etc.)
• Examine and review how security controls and measures that are in place mitigate or eliminate the risk of those attacks (access controls, processes, policies, security standards, etc.)
• Identify security needs, remedies or areas for improvement

When categorizing assets, don't simply look at the importance of the service it provides to the organization (e.g. mission critical), but look at the risks that are associated with potential compromise, the value of the information, the impact of potential compromise. A system could be totally unimportant to the organization's daily business, but it might be of great importance in terms of the information it can provide to an attacker, if compromised. We had a running joke at the office - one of our pentest engagements wasn't going anywhere, the web servers and public infrastructure of the client were all rock solid, but we managed to compromise the CFO secretary's laptop. Interestingly, it had a copy of the company's financial statement - days before it was going to be officially released. Since the client was a publicly listed company... you know where this goes.

2. Security Audit

Frequency: Quarterly

Unfortunately, many forget that most issues can be identified by looking at things from the inside, rather than testing from the outside. A properly done audit may reveal issues that you might not be easily revealed during a pentest (let's have a look at the accounts defined for that Tomcat manager). Here are some basic points:

• Review configurations (servers, routers, switches, firewalls)
• Verify policies are enforced (e.g. make sure accounts of ex-employees have been removed, look at passwords and when were they last changed)
• Look at how backups are configured and done, encryption of sensitive data, how access control is implemented (including physical - badges and other seemingly unimportant items)

_

3. Systems Lifecycle

Frequency: On-going

Every time IT bring up a new system, add a network, or provide a new service, or decommission an old one, the infosec team must be involved to review, analyze and implement security measures. Make it a part of the process.

4. Vulnerability and Patch Review

Frequency: Weekly

When you receive those security bulletins, if they contain items that are directly related to products/systems you've got installed, pay attention. Also, don't "assume" all is patched on Tuesday - WSUS may work fine, but you've got to run some basic checks and look at the logs.

There are more items, but this is already too long, and I'm not writing a book. Additional things to look at:

• Security events, incident reports and incident response
• Security awareness days
• Security round-table (involving the CEO)
• ...

Answer 2

There are a few resources I'd like to point you towards in order to fully comprehend the tradtional and non-traditional approaches to penetration testing resourcing. Two books, one: "CISO's Guide to Penetration Testing: A Framework to Plan, Manage, and Maximize Benefits", and the other, "Effective Penetration Testing" by Kevin Pescatello and Matthew Larsen. In the former book, chapter 5 covers four types of tests: parallel shared, parallel isolated, series shared, and series isolated. The tests, ideally, should be coordinated based on how they connect in terms of data and execution flows -- the most-connected systems will likely be parallel-shared tests, as an example.

Additiontally, I've been reading a lot on risk lately, especially because of a book, "Measuring and Managing Information Risk". There are many interesting ways to model risk for penetration testing calendaring, such as placing Internet-facing first, indirectly-facing systems second, and isolated systems last -- but also taking into consideration the control factors from loss prevention, variance detection and response, and decision enablement. What are the values of your assets? What is the efficacy of your current control sets?