When building your organization's security program, it is helpful to have a starting framework, something that gives you a solid initial structure yet is malleable enough to fit the particulars of your situation. I've found that thinking about security as a collection of processes provides just such a framework.
To keep us all on the same page, I'll offer up my definition of a process. This isn't the most exciting stuff, but, oh well. A process is a set of measurable, controlled activities aimed at achieving a specific goal. Measured means that the activity produces metrics that can be used to help determine if the process goal is being met. Controlled means that the activity's steps are clearly defined, roles and responsibilities have been assigned, and that outputs are reviewed as necessary.
The key security processes in the infamous Kenan Security Process Framework are:
- Security governance
- Security management
- Identity and account management
- Data protection
- Software security
- System or platform security
- Network security
- Vulnerability management
- Detection and response
- Education and awareness
- Compliance
- Physical security
Assign each process to someone to manage. Depending on the needs of your organization, some managers might own multiple processes while others oversee just a single process. Small organizations will divide all of the processes across one or two folks, while large enterprises might find it worthwhile to assign a single person to each process.
The managers are responsible for fleshing out the process with appropriate policies (which define the process goals), activities, and standards as well as for measuring how well the process is operating. Three questions keep the process managers up at night: are the process goals being achieved, are the activities being executed properly, and are the activities comprising the process the right activities. Most of their time should be spent in a feedback loop of gathering evidence relevant to those questions and then adjusting the process as needed.
An organization's culture will determine how formal these processes should be, but if you're going though the effort of actually defining a security program, then at the very least document your policies with just enough detail to communicate your security goals. Then turn your attention to metrics. Make sure that you have a way to measure if your organization is approaching or veering away from those security goals.
Far too many security programs focus nearly all of their effort on policies and activities, leaving very few resources for measuring. Unfortunately, if you are not gathering metrics, your security processes are, by definition, out of control. As you build you security program, carve out ample resources for your process managers to gather the evidence they need to determine if their processes are working.
Comments