Vocabulary – Risk


Dictionary defines: risk – possibility of loss

FAIR defines: risk – the probable frequency and probable magnitude of future loss.

More complete than the dictionary

COBIT and ISACA defines: risk – the combination of the probability of an event and its consequence

The term “event” is ambiguous introducing complexity

O-TTPS defines: Risk – An event or condition that has a potentially negative impact and the possibility that such an event will occur and adversely affect an entity’s assets and artifacts, activities, and operations.

Complete but verbose.

OWASP defines: risk – Risk is the possibility of a negative or undesirable occurrence. There are two independent parts of risk: Impact and Likelihood.

Relies on context for specialized terms.

CIS defines: risk – an estimation of the likelihood that a threat will create an undesirable impact.

Relies on context for specialized terms.

CNSS defines: risk – possibility that a particular threat will adversely impact an IS by exploiting a particular vulnerability

Relies on context for specialized terms

NIST CSF and 800-53 defines: risk – a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.

Not simple. Relies on context for specialized terms

PCI DSS defines: risk assessment – Process that identifies valuable system resources and threats; quantifies loss exposures (that is, loss potential) based on estimated frequencies and costs of occurrence; and (optionally) recommends how to allocate resources to countermeasures so as to minimize total exposure.

Not simple. Provides a description rather than a definition.

ESA defines: IT-related risk – the net mission/business impact (probability of occurrence combined with impact) from a particular thereat source exploiting, or triggering, a particular information technology vulnerability.

Not simple. Relies on context for specialized terms

ISO 27000 defines: risk – effect of uncertainty on objectives

Unclear by choice of defining terms.

Vocabulary – Policy


Dictionary defines: policy – a high-level overall plan embracing the general goals and acceptable procedures especially of a governmental body

COBIT defines: policy – Overall intention and direction as formally expressed by management

A good definition

ISO/IEC 27000 defines: policy – intentions and direction of an organization as formally expressed by its top management

A good definition almost identical to COBIT

ISACA defines: policy – 1. Generally, a document that records a high-level principle or course of action that has been decided on. 2. Overall intention and direction as formally expressed by management.

Not simple.

ESA defines: policy – A broad statement authorizing a course of action to enforce the organization’s guiding principles for a particular control domain.

Relies on specialized terms

NIST 800-53 defines: Information Security Policy – Aggregate of directives, regulations, rules, and practices that prescribes how an organization manages, protects, and distributes information.

Provides examples of policy rather than a definition, with specialized actions listed

O-TTPS defines: Framework – a set of best practices identified by a cross-industry forum which, if used by a technology vendor, may allow a government or commercial enterprise customer to consider the vendor’s products as more secure and trusted.

Verbose description rather than a definition.

Vocabulary – Control


Dictionary defines: control – to exercise restraining or directing influence over

ISO/IEC 27000 defines: control – measure that is modifying risk

A good definition assuming the reader understands that the dictionary defines “measure” as a step planned or taken as a means to an end

COBIT and ISACA define: control – The means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management or legal nature.

A good definition up to the 5th word.

CIS RAM defines: control – A documented method for protecting information assets using technical, physical, or procedural safeguards.

A good definition up to the 7th word.

O-TTPS defines: mitigation – Any action, device, procedure, technique, or any other measure that reduces the vulnerability or risk.

Skip the first 8 words for a good definition.

STIX defines: A Course of Action – an action taken either to prevent an attack or to respond to an attack that is in progress.

This definition uses the security jargon “attack”, but otherwise aligns well with the dictionary definition.

FAIR defines: control – Any person, policy, process, or technology that has the potential to reduce the Loss Event Frequency (LEF) and/or Loss Magnitude (LM).

Provides categories and factors impacted rather than a definition.

NIST 800-53 defines: Countermeasures – Actions, devices, procedures, techniques, or other measures that reduce the vulnerability of an information system. Synonymous with security controls and safeguards.

Provides examples rather than a definition.

PCI DSS defines: Compensating Controls – Compensating controls may be considered when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other controls.

No definition of “controls” is provided, and this is an explanation rather than a definition.

Vocabulary – Asset


Dictionary defines: asset – an item of value owned

O-TTPS defines: asset – anything you can use that is considered a thing of value (e.g., tool).

A verbose variation of the dictionary definition

FAIR defines: asset – Anything that may be affected in a manner whereby its value is diminished or the act introduces liability to the owner.

Describes what can happen to an asset rather than what it is.

ISACA defines: asset – Something of either tangible or intangible value that is worth protecting, including people, information, infrastructure, finances and reputation.

A good definition up to the 7th word.

CIS defines: Asset Class – A group of information assets that are evaluated as one set based on their similarity. “Servers,” “end-user computers,” “network devices” are examples, as are “email servers,” “web servers” and “authentication servers.”

No definition provided for “asset”, so a person has to infer that an asset is a type of information system component.

Vocabulary – Introduction

The words risk, threat, and vulnerability are the vocabulary of security professionals, but the are not used consistently. This series of blogs will explore common information security vocabulary starting with a dictionary definition, then listing other definitions with a brief analysis. Often the dictionary provides multiple meanings, so I have selected the one that best fits security.

The vocabulary includes:

  • Asset
  • Control
  • Policy
  • Risk
  • Threat
  • Vulnerability

I have evaluated the definitions using the following basic principles:

  1. Keep it simple
  2. Avoid complicated terms
  3. Avoid specialized terms
  4. Avoid circularity

Sources referenced include:

  1. Dictionary https://www.merriam-webster.com/
  2. The Center for Internet Security® (CIS) Risk Assessment Method Version 1.0 For Reasonable Implementation and Evaluation of Controls (2018)  https://www.cisecurity.org/
  3. The National Information Assurance (IA) Glossary CNSS (2003) https://www.ecs.csus.edu/csc/iac/cnssi_4009.pdf
  4. COBIT https://cobitonline.isaca.org/l3-main?book=framework#framework-glossary01
  5. Common Vulnerabilities and Exposures (CVE) http://cve.mitre.org/
  6. The Open Enterprise Security Architecture (ESA) (C02, ISBN 978-90-8753-672-5), 2011
  7. The Open Technical Standard: Risk Taxonomy (FAIR) (C081, ISBN: 1-931624-77-1), January 2009, published by The Open Group.
  8. ISACA https://www.isaca.org/Pages/Glossary.aspx?tid=2011&char=C
  9. The International Standards Organization’s Information technology – Security techniques – Information security management systems – Overview and vocabulary (ISO 27000 – 2018)  http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
  10. The NIST Framework for Improving Critical Infrastructure Cybersecurity (CSF) Version 1.1, 2018 https://www.nist.gov/cyberframework
  11. The Security and Privacy Controls for Federal Information Systems and Organizations     (NIST 800-53)  Revision 4, 2013
  12. Open Trusted Technology Provider™ Standard (O-TTPS) Version 1.1 Mitigating Maliciously Tainted and Counterfeit Products https://publications.opengroup.org/c147
  13. OWASP https://www.owasp.org/index.php/Glossary
  14. The Payment Card Industry (PCI) Data Security Standard (DSS) and Payment Application Data Security Standard (PA-DSS) Glossary of Terms, Abbreviations, and Acronyms Version 3.2, 2016 https://www.pcisecuritystandards.org/document_library
  15. The Security Development Lifecycle (SDL), Michael Howard and Steve Lipner, Microsoft Press, 2006, ISBN 978-07356-2214-0
  16. STIX™ Version 2.0. Part 2: STIX Objects, Committee Specification 01, 19 July 2017 https://oasis-open.github.io/cti-documentation/resources#stix-20-specification

Security and Exchange Commission – Statement and Guidance on Public Company Cybersecurity Disclosures


The U.S. Computer Emergency Readiness Team defines cybersecurity as “[t]he activity or process, ability or capability, or state whereby information and communications systems and the information contained therein are protected from and/or defended against damage, unauthorized use or modification, or exploitation.

Why this Announcement

Cybersecurity risks pose grave threats to investors, our capital markets, and our country. Companies that fall victim to successful cyber-attacks or experience other cybersecurity incidents may incur substantial costs and suffer other negative consequences.


Disclosure about the board’s involvement in the oversight of the risk management process should provide important information to investors about how a company perceives the role of its board and the relationship between the board and senior management in managing the material risks facing the company. Disclosure regarding a company’s cybersecurity risk management program and how the board of directors engages with management on cybersecurity issues allow investors to assess how a board of directors is discharging its risk oversight responsibility in this increasingly important area.

What the SEC Expects

The company’s financial reporting and control system are expected to provide reasonable assurance that information about the range and magnitude of the financial impacts of cybersecurity incidents and risks are disclosed, such as:

  • Remediation costs
  • Increased cybersecurity protection costs
  • Lost Revenue
  • Litigation and legal risks
  • Increased insurance premiums
  • Reputational damage
  • Damage to competitiveness, stock price, and long-term shareholder value

How is this Accomplished

Companies are expected to maintain comprehensive policies and procedures related to cybersecurity risks and incidents, which must include appropriate and effective disclosure controls and procedures to make accurate and timely disclosures of cybersecurity risks and incidents that are material to investors, including the concomitant financial, legal, or reputational consequences, and to avoid generic cybersecurity-related disclosure.  Cybersecurity risk factor disclosure may include:

  • prior cybersecurity incidents, including their severity and frequency
  • the probability of the occurrence and potential magnitude of cybersecurity incidents
  • adequacy of preventative actions taken to reduce cybersecurity risks and the associated costs
  • aspects of the company’s business and operations that give rise to material cybersecurity risks and the potential costs and consequences of such risks
  • costs associated with maintaining cybersecurity protections, including any applicable insurance coverage
  • potential for reputational harm
  • litigation, regulatory investigation, and remediation costs

Policies and Procedures

Companies are expected to adopt comprehensive policies and procedures related to cybersecurity and to assess their compliance regularly. They must ensure that relevant information about cybersecurity risks and incidents is processed and reported to the appropriate personnel, including up the corporate ladder, to enable senior management to make disclosure decisions and certifications.

How the Security Program Supports this Expectation

An organization must at least have a plan for their security program, ideally evolved to a security management system. Components of the management system should include management of risk, policy , assessments and incidents, which each play a part in meeting SEC expectations. It is key that the security program leader is the senior manager guiding disclosure decisions and certifications through the Chief Executive Officer.


International Threat Rating System

How to Provide Transparency

In the 2010’s, the organization was primarily US based, with an employee presence in many countries. This US based intranet had a few portals to the internet but was otherwise an isolated network with segments that served literally hundreds of buildings or campuses across the US. All other locations accessed the intranet by connecting through the perimeter. Over time selected organization buildings at international locations were connected to the intranet.

The criteria for approving and international connection to the organization intranet included business and security considerations. The dominant element in the security criteria was country threat, which was subjectively understood by security personnel, particularly those involved in investigative support. But there was no means to objectively define the threat to executives. Frustration and anger was common.

By this time, I had been studying and using FAIR for several years. My partner in the International organization had become aware of a variety of country rating systems. This spawned the question: can multiple country rating systems be combined and weighted to provide a transparent country threat rating?

The solution had three elements. First all sources had to be normalized to a 0-100 score. Second, each rating was aligned with an element of the FAIR taxonomy elements related to threat, specifically Threat Event Frequency (emphasizing Probability of Action) and Threat Capability. Finally, the elements were given weights, recognizing that some had a stronger correlation to threat than others. Organization ratings that informed this analysis were also incorporated. The result was displayed as a sorted list of threat ratings; those below a threshold could be allowed to connect to the intranet. While executives who were told no were still not happy, the method made the decision process transparent thus eliminating surprises.

Implementing New Security Service

From Requirements through Operation

The emergence of the Advanced Persistent Threat triggered a frenzy of strategic planning resulting in identification of a list of prioritized control improvement projects. Most fell within the responsibility of existing teams. However, one did not have an obvious owner. After a few less than successful attempts by others, I stepped up to lead the project.

The Lockheed-Martin “Kill Chain” is a common means to refer to the stages or steps that the threat actor takes from the beginning of an attack to succeeding in their objective. My assignment was to reduce the probability of information theft at the point where the threat actor controlled an identity in the system that had authorized access to Office files contain in Windows file shares. The contributing fact is that access is granted to file shares as needed to perform assignments, but the access authorization frequently remains in place long after the need has ceased. I first became aware of this problem in the late 1980’s, but it had defied solution all that time.

Steps in the project included documenting the objectives and ultimately the requirements for the solution. My earlier work in developing and maintain the security control framework lead me to review our security requirements manual for relevant requirements. I was delighted to discover text that could be incorporated into the project requirements document, rather than having to invent requirement text. There were two relevant requirements: removing unneeded access authorizations, and monitoring for anomalous behavior. Detailed functional requirements were developed to support the requirements.

A market search was performed to identify candidate solutions. The candidate products were each evaluated against the detailed requirements. Only one product was responsive to all main requirement areas, so it was ultimately selected and implemented. I’ll skip all those details except one. During the proof of concept (pre-production) phase we operated the system with a very limited scope of file-share servers. During that time, we discovered that one user was reading an extraordinary number of files. We ultimately turned the data over for investigation as a potential insider threat. Of course I was not in a position to learn the outcome of the investigation. But it was heartening to confirm the solution met the expectation.

Quantifying Information Risk

A FAIR Way from Fear, Uncertainty and Doubt

Organization executives started paying attention to computing security in the early 1990’s. Digital networks had been established to support selective communication with suppliers, evolving to include massive digital product definition data. On one hand executives expressed vague fears, uncertainty and doubt about the potential for data loss, yet at the same time challenged costs for proposed security control improvement projects. The typical security executive presentation at least introduced the idea of a scale balancing security costs against the potential for loss but relied on personal persuasion to gain support for projects.

The organization used a 5×5 risk grid for reporting schedule, cost and technical risk associated with projects. Placement of a “risk” on the grid was the subjective judgement of a project manager, with adjustments to the status associated with a “risk mitigation” plan. The security function adopted use of the risk grid primarily because it was recognized. While many organizations labeled any technical “vulnerability” finding or a non-compliance as a risk, we used the grid to communicate only the primary risk scenarios for the organization. An example for illustration: Theft of proprietary information by insiders. Note that the asset (proprietary information) and the threat agent (insiders) are specifically identified. While this focused attention of the few key risk scenarios, the lack of granularity in the 5×5 matrix made communicating progress on risk reduction impossible.

The FAIR methodology first came to my attention around 2010. I was attracted to the clarity provided by the FAIR taxonomy in understanding how to measure risk. However, lack of a tool for performing a FAIR risk analysis stymied progress at the time. Fortunately, now there is are some choices of tools available to perform FAIR risk analyses.