Building a Security Program – Advanced Processes – Part 3

On the journey to building a security program, or evolving the one you’ve currently got in place for your organization, there are a number of controls you’ve got to consider. Some of those controls, like the ones we talk about here, are either contingent upon other controls already being in place or require a significant level of resources to properly implement. It just makes more sense and you get more return-on-investment out of these portions of your security program once you’ve done many of the other things we presented in part 1 and part 2 of this series.

To be clear, we’re not saying that these controls are any less important than the controls we’ve covered in part 1 and 2. And as we’ve mentioned previously, these controls are not listed in their order of importance here. But they are hard to start and maintain correctly. If you’re able to work these into your security program, they are the mark of a mature organization but can be resource intensive.

Security Awareness and Training Program

The most difficult thing to secure in your organization is your people. Your employees’ actions often have a more significant impact on your security than any of your technical controls, as they are often the key to bypassing those technical controls, unfortunately. While standardized process and security management certainly helps, you’ve got to build a culture of good security hygiene and adequately train your employees. This kind of awareness and security culture can help raise the level of difficulty for many types of social engineering attacks that are the root cause of breaches. A well-rounded security awareness program should include:

• Annual training and training upon hire
• Training through multiple formats, i.e. monthly newsletters, CBTs, posters, lunch and learns, etc.
• Regular phishing campaigns
• Regular social engineering assessments

Application Software Security

If your organization is developing software internally, your security team should be involved or influencing the software development lifecycle (SDLC). This ensures that security is baked into your development team’s processes. This is not always easy, but can reduce the cost of implementing security into software while still maintaining a high-level of security in the end product. A variety of different controls can be considered here, including:

• Published software development lifecycle policy that includes security throughout
• Software change management process that documents and mitigates risk
• Code reviews conducted by peers and approved by management
• Developer training that includes secure coding practices

Incident Response Program

An incident response program of some kind is appropriate for every organization, regardless of size. However, your organization’s size and resources will definitely dictate how much of that process is in-house vs. outsourced. Incident response processes can help your organization prepare for a breach so everyone involved knows how to properly respond. A good response can not only lessen the severity of a breach, but it plays in part in preventing other breaches from happening in the future. Regardless, a good incident response program should include:

• Documented Incident Response Policy/Plan
• Documented Business Continuity/Disaster Recovery Plan – should include asset criticality and expected recovery times for all assets
• Annual tabletop exercise of the incident response plan
• Regular training for all members of the incident response team

Penetration Testing and Red Teaming

And finally, as you implement a security program for your organization and start building these processes, you’re going to need some way to measure their effectiveness and identify the remaining gaps that may exist. Penetration testing goes above and beyond any internal vulnerability management programs you may have, utilizing specialized third-parties to emulate a real-world adversary and attempt to exploit vulnerabilities in your environment. These assessments should probably be happening throughout the building of your security program, as it provides a great way to measure improvement and guide where you’re spending company dollars. But on top of that, most organizations have compliance requirements to regularly test the overall security of their network. Consider including the following assessments in your overall testing plan:

• External Penetration Test
• Internal Penetration Test
• Social Engineering Assessment
• Web Application Penetration Test (for any custom, in-house developed applications)
• Wireless Penetration Test
• Physical Penetration Test

Once you’ve done penetration testing for a while on all aspects of your organization, it may be time to move on to a red teaming exercise. While similar to a penetration test, this is the most realistic assessment you can perform on the security of your organization, and removes (almost) all scope restrictions from the testing organization, allowing them to break-in using any asset available. This includes elements of network-level penetration testing, application-level penetration testing, social engineering, physical penetration testing, and wireless penetration testing in one seamless assessment. It also allows your internal network defenders to actively respond when attempts are detected, providing a more realistic assessment.

Hopefully this three part series was useful in providing a high-level overview on some focus areas when building a security program. Even if you are taking over a security program and trying to mature it over time, you may not have considered some of the items discussed here. If you need help sifting through all this and figuring out where you stand at a strategic level from a security best practice perspective, let us know and we’d love to help.