Security Program Management
This article is the first in a series of articles organized by the concepts framed out in the National Institute for Standards and Technology (NIST) Special Publication 800-53, the Security and Privacy Control Catalog that is used as part of NIST’s Risk Management Framework (RMF) to specify the granular areas of Security and Privacy to be addressed in Enterprise Risk Management strategies when it comes to managing risk to information resources. NIST RMF isn’t for every organization, it’s a large undertaking that is suited for entities with the requirements and/or resources to manage information security risk with great attention to detail and an integrated understanding (by leadership) of how IT Risk affects the organizational mission.
Why start here?
This first article focuses on Security Program Management on purpose. Program Management (PM) is intended to underly all security related activities. So, it makes sense to address and instantiate PM first.
Decide. Define. Implement.
PM involves the establishment of Program plans, strategies, organization-level procedures, etc… Decisions to “be secure” have to be made, detailed definitions of what that decision means must be established, and those defined decisions must be implemented as technologies, procedures, agreements, training, practices, guidelines, etc…
Organizational leadership must make the decision that their organization will practice “security.” While leaders are typically focused on running the business, they still need to understand that the bottom line is, most businesses today rely heavily on information. So, information must be viewed as the strategic asset that it is. Any leader can understand that risks to strategic assets need to be discovered and managed. So, since information resources are an important strategic asset, a high-level decision needs to be made to manage risk to information resources.
A few things come about as a result of that high-level decision – two of the most important being: 1) a Security Program Plan and 2) Policy Set.
The Security Program Plan should describe what the Security Program looks like in the short term and where it is headed in the long term (3-5 years). The Policy set should take the control framework (in this case NIST 800-53) and define all the specifics that apply to the Organization (specifics like password length & complexity requirements, vulnerability scanning windows & timeframes, and security patch requirements for high, moderate, and low criticality security vulnerabilities, etc…)
The policy definition, especially if it’s built from NIST SP 800-53, will include Security Program Management requirements – specifically to formally define:
- roles & resources associated with the Security Program;
- Organization-level procedures like the Plan of Action & Milestones and the System Authorization processes;
- Strategies, plans, and programs related to:
- risk management
- enterprise architecture
- External & Internal threat Awareness;
- Leadership expectations in how the Security will perform & its impact on business operations;
- Expectations of the Security Workforce; and
- How the Security Workforce will interact with and lead/train the whole of the organization.
The implementation of the Program-level policy requirements will manifest itself in any number of ways. In the form of formal and informal processes, step-by-step instructions, web sites and pages, tools, technologies, etc… While many security programs will share similar foundations, program structure, placement within the organization, procedure details, etc… will have to be developed to fit the organization while still meeting the objective of the policy requirement.
Get Started and Never Stop
One of the most important aspects of NIST RMF and the 800-53 Control Catalog is Continuous Monitoring. Often though, Security Professionals will hinder a Security process from ever getting off the ground in the pursuit of perfection. Getting started is more impactful than doing nothing while waiting on the perfect process. Once an activity is started, it can be matured over time.
Security Program Management should be the first component acted on once leadership buy-in is “codified” and that decision has its granular details defined (in policy). It underlies and supports every activity performed as part of the Security Program.