(re)Building a Security Program – part 2

June 16th, 2015

Principles, Capabilities, and Processes – oh-my!

Security is not a small topic.

And yet, in the modern “knowledge worker” oriented business where practically everyone in the organization is working deeply with technology, security is everybody’s problem.  So how to re-build a security program to meet this challenge?

Now, there are LOTS of security and risk frameworks out there.  From NIST, ISO, CIS, etc., etc. etc.  They all have good and extensive ways of describing the organization.  And, ultimately, they speak a language that is only for the information security professional.  Everyone else from the Board Member down to the front line point of sale personnel speak a very different language and trying to use these frameworks as a Communication device simply made people want to turn off.

Instead, we choose an approach to focus on the critical few and to use non-tech speak language as much as possible.  By framing the work around simple ‘capabilities’ it made it much easier to communicate.  Let’s face it “Keep Current” is a far easier to understand to a non-technical person than “Patch Management”.  If security is everybody’s responsibility we have to communicate in a way that they can understand.

security - capabilities

  • Know Your Exposures = Vulnerability Scanning, etc.
  • Keep Current = Patch Management, application / hardware refresh, lifecycle management, etc.
  • Deploy Secure Stuff = Configuration Management, hardening and build standards, etc.
  • Control Access = Identity management, attestation and auditing, etc.

 

Secondly, we did not want to “boil the ocean”.  We wanted to focus on driving practical action and decision making as new threats emerged.  The team developed the following two principles to guide the work:

 

security - principles

Structurally, we created a weekly process meeting with all of I.T. leadership to review and prioritize activity.  The bonus in this meeting is that it frequently covered topics much wider than solely security.  Instead, it allowed for the leadership team to actively explore trade-offs between application development, infrastructure and end-user support for impacts.

Check out the next part – Just the Facts Mam, Where’s the Data? This is where we will look at the dashboard / detective controls that were developed to sense and drive the change needed.

 

0 Comments