- Types
- Overview of Metrics Program
- Purpose, Approach, and Objectives
- Requirements
- Benefits of Using Metrics
- Metrics Types
- Data Management Concerns
- Stakeholder Interest Identification
- Goals and Objectives Definition
- Security Policies, Guidance, and Procedures Review
- System Security Program Implementation Review
- Metrics Development and Selection
- Establishing Performance Targets
- Feedback within Metrics Development Process
- Metrics Program Implementation
- Summary
- Appendix
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Stakeholder Interest Identification
In Phase 1 of the metrics development process shown in Figure 3, anyone within an organization should be a security stakeholder. Some functions, however, will have a greater stake in security than others. A stakeholder is someone who is responsible for some aspect of security, thus should be directly or indirectly involved with metric development, implementation and reporting.
Examples of primary security stakeholders are:
- Executive Management
- Chief Security Officer (CSO)
- Chief Information Officer (CIO)
- Program Manager/System Owner
- System Administrator/Network Administrator
- IT Support Personnel
The secondary security stakeholders do not have security as their primary mission but for some aspects of their operations.
Examples of secondary security stakeholders include:
- Chief Financial Officer (CFO)
- Training Organization
- Human Resources/Personnel Organization
The interests of each stakeholder will differ, depending on the security aspects of his role and on his position within an organization’s organizational hierarchy. Stakeholder interests may be determined through multiple venues, such as interviews, brainstorming sessions, and meetings. Each stakeholder may require an additional set of customized metrics that provides a view of the security program’s security performance within his area of responsibility.
The total number of metrics should be between five and ten for each individual stakeholder. Fewer metrics per stakeholder are recommended as an organization is maturing its security program. The number of metrics per stakeholder will increase gradually with the maturity of the security program and of the metrics program.
Stakeholders should be involved in each step of security metrics development to ensure organizational acceptance of the concept of measuring security performance. Stakeholder involvement will also ensure that the sense of ownership of the security program security metrics exists at multiple levels of the organization. This will encourage the overall success of the program.
The four measurable aspects of security (business input, efficiency, effectiveness, and implementation) speak to different stakeholders. An executive might be interested in the business and mission impact of security activities. (what is the monetary and public trust cost of the latest security incident? Is there a security-related article about us in a major publication?) Security and program managers may be interested in the effectiveness and efficiency of the security program and its security controls and processes. (could we have prevented the incident, and how fast did we respond to it?) System or network administrators may want to know what went wrong with implementation (have we performed all necessary steps to avoid or minimize the impact of the incident?).