How to Validate Your Security Program: Part 10

Note: This is the tenth of a multi-part series that provides 15 important perspectives from which to validate your Security Program. If this is the first article you have seen in this series, please read the WHY VALIDATE? introductory article before launching into the validation steps.

An attribute is a quality or feature regarded as a characteristic of something. What we are calling the “15 Validation Attributes” are 15 characteristics that you can use to both validate and strengthen your security program.

Validation Attribute: Well-Founded

Definition:

1. based on sound judgment, reasoning, or evidence; adequately substantiated

Over the years I have heard or read, in one form or another, statements asserting that a security program’s basic and most important foundation is a management-approved risk treatment plan, based on a documented risk picture.  The “risk treatment plan” could actually be a collection of risk treatment plans, each one reflecting the scope of a particular security improvement initiative.

This makes sense if you think about organizational security as a static picture. Which it isn’t.

The Reality of Business Risk

Extending the foundation analogy, it could be said that a security’s foundation would be weakened over time because changes to the business and the business environment (such as new threats, new vulnerabilities, new assets not fully covered by protective measures) result in the security program elements becoming less-aligned to the business, and thus less effective.

This is why standards-based security management systems follow the Plan-Do-Check-Act cycle of operation. This results in catching and fixing any security effectiveness backsliding, as well as continual improvement to the security profile.

Restated to take the above factors into account, a security program’s basic and most important foundation is an approved risk management approach, including a well-designed risk assessment program.

It is not uncommon to find that a security function’s application of risk assessment is a bit piecemeal, where the performance of risk assessments over time is triggered by things occurring at random. These include (for example) incidents, management inquiries, accidentally discovered vulnerabilities, realization that re-assessment is overdue, news of another organization’s recent assessment, and so on. Performing assessments every few years when the thought strikes provides no assurance that risk are sufficiently accounted for by the security program.

Risk Assessment Program

A risk assessment program is a documented and management-approved approach to performing risk assessments that:

• Is based on a Risk Assessment Policy (purpose, scope, objectives, periodic policy review)
• Lists and describes the types of assessments to be performed
• Specifies that each assessment will create or update a risk treatment plan
• Establishes a baseline assessment/reassessment schedule
• States what will trigger an off-schedule assessment
• Identifies the resources needed to perform each assessment
• Is informed of relevant business changes and impacts as part of the organization’s change management process

Most security functions do perform assessments and can easily eliminate the risk-capture gaps by defining a simple assessment program. Usually the resources and knowledge needed already exist. It’s just a matter of defining the program and applying it. Sometimes the use of assessments is appropriate and sufficient, in which case it is a simple step to document the ongoing practices, make management aware of them, and formalize the support already being received by establishing the written policy.

As mentioned in the previous validation attribute (Part Nine), Risk treatment and planning can often be updated using micro-assessments, which are a narrowly focused short assessments that provide support for decision-making and planning. Full-blown assessment projects are not the only way to ascertain whether or not any parts of the security program need updating. One benefit of micro-assessments is that they are small efforts, which means that they can easily be performed without compromise to other duties.

Validation Steps

Step 1. Review the assessments that have been performed over the past five years.

• Make a list of the assessments that you or others have been performed.
• Describe each one including its purpose.
• Identify the resources needed to perform the assessment.
• Characterize the level of effort (people, required to perform each assessment

Step 2. Add other types of assessments to the list.

• Consider the assets to be protected and what threats could target them. Assessments can be typed not only by threat, such as Information Asset Insider Threat Assessment (download micro-assessment template here), but by asset type or location, business unit, or relevance to specific stakeholders or critical business processes.

Step 3. Determine the minimum frequency at which each assessment should be performed.

Step 4. Determine what will trigger off-schedule assessment performance for each assessment on the list.

Step 5. Write an appropriate policy that specifies the purpose, scope, and objectives for the assessment program, includes a list of the assessments already identified, what resources and specifies annual policy review to assure ongoing business alignment.

Step 6. Determine the annual budget that will be needed, making note of the staff resources to be utilized that don’t require additional funding.

Step 7. Determine the annual budget that will be needed, making note of the staff resources to be utilized that don’t require additional funding.

Step 8. Obtain the necessary approvals, and in doing so be sure to find out which stakeholders would like to be informed about assessment activity.

Final Note

Establishing a formal risk assessment program adds to the stature of the security function, enhances stakeholder support, and ensures that the overall security program remains well-founded going forward.