When it comes to acronyms, Technology and Cybersecurity often rival various branches of government. Technology acronyms are usually somewhat bland, amounting to little more than the arcane argot of the profession, such as SOC, SIEM, and DNS. Government, however, rarely disappoints in its inventiveness, whether it is the acronym of the Puppies Assisting Wounded Servicemembers (PAWS) for Veterans Therapy Act, or the more recent proposal towards Stopping Another Non-Truthful Office Seeker (SANTOS) act, named after embattled US House of Representatives member, George Santos.
Sometimes, even seemingly plain language can cause confusion, leading to loose usage of terms that describe very specific actions. This is especially true when referencing guidance, standards, frameworks, and regulations. Even though the titles of most of these are the tell-tale sign of their expected application within an organization, too often, they are improperly treated synonymously. However, a closer look at the language within these documents can solidify their intent and applicability.
Guidance
When it comes to the forcefulness of language, the weakest class can be found in guidance documents. While a guide may be very direct in its tone, providing the procedures for an action, the overall purpose is to instruct. Whether the instruction is towards a tangible goal, such as that contained in the CIS Controls, or an intangible, such as that described in various NIST documentation, the lexicon of a guidance manuscript walks on lighter side of the language.
For example, from the introduction of the CIS Controls, the semantic treatment is that of knowledge-sharing, stating its intended purpose to, among other aims:
Share insights into attacks and attackers, identify root causes, and translate that into classes of defensive action.
Create and share tools, working aids, and stories of adoption and problem-solving.
The same sentiments are found in NIST’s Special Publication 800-207 “Zero Trust Architecture”:
Section 2 defines ZT and ZTA and lists some assumptions when designing a ZTA for an enterprise. This section also includes a list of the tenets of ZT design. Section 3 documents the logical components, or building blocks, of ZT.
Other words in the CIS and NIST documents also echo the same approach, including “discussion”, “starting points”, and “enhancement”.
Standards
Standards are practices that are commonly recognized in a particular industry, and are followed as a matter of custom. While not mandatory, a standard can have the force of authority, often disqualifying those who do not observe the prescribed information.
Of course, the most well-known standard is the Data Security Standard (DSS), which has been developed by the Payment Card Industry (PCI). PCI DSS, now in its Fourth version, uses very strong language, denoting required actions.
Although Standards contain exacting requirements, they are still mostly discretionary, as the PCI DSS states in its section about its applicability:
Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers).
What makes the language of PCI DSS particularly striking, is its objective viewpoint of a requirement, residing a safe distance from directive edicts. For example, instead of indicating that pre-production environments must be separated from production environments, the Standard states that: “Pre-production environments are separated from production environments and the separation is enforced with access controls.”
It should be noted that PCI DSS contains both the defined approach, as well as the guidance for achieving each goal.
Other Standards offer similarly objective language.
Frameworks
Frameworks are a conceptual structure that can aid in the development of a system. Frameworks are not limited to the cybersecurity industry, as there are frameworks for the management of everything, from the physical realm, to medical evaluations. Frameworks are very broad, and may contain information from guidance and standards to help an organization achieve the framework’s goals.
In cybersecurity, one of the well-known frameworks in the US is NIST’s Cybersecurity Framework (CSF). The language of the framework is clear, indicating that it draws upon other information for its source material. In the case of the CSF, its newest version makes a clear distinction about some of the confusing language of its earlier iteration by including that it “Added clarity that the Framework has utility as a structure and language for organizing and expressing compliance with an organization’s own cybersecurity requirements. However, the variety of ways in which the Framework can be used by an organization means that phrases like “compliance with the Framework” can be confusing. One has to applaud NIST for recognizing that the word “comply” has a stronger gravity of influence than was intended by the framework.
One clue about the non-compulsory language of a framework appears early on within the CSF, where it states that:
“The Framework can assist organizations in addressing cybersecurity as it affects the privacy of customers, employees, and other parties. Additionally, the Framework’s outcomes serve as targets for workforce development and evolution activities.”
Note the word “assist” in that paragraph. This is a pure signal about the intention of the document. This differs from the language of a guidance document. Other words that are used in the framework include “encouraged”, “help”, and “desired”. This is very tame language.
Regulations
Regulations use language that is strict, forceful, and as far from tame as possible. Regulations will often include language about penalties, which is absent from guidance, standard, and framework documents. The UK.gov Minimum Cyber Security Standard site offers a very clear description of words and their implications with a “Definitions” section that greets its visitors:
Definitions:
“Shall” means that there is an obligation to perform the activity, without exception.
“Should” means that there is an expectation that the activity will be performed.
While the definition goes on to describe rare exceptions, including the advice that mitigating measures, also known as compensating controls, must be in place, the words of the initial definitions make it clear about the seriousness of the UK, or any other regulation. The language of any regulation is not mere suggestion, it is a commandment.
Conclusion
Every law student spends part of their first year in law school learning how difficult it is to write a law that clearly describes the intent of the proposed rule, and examining all of the pitfalls, loopholes and exclusions that arise from something as simple as a missing punctuation mark. The language of guidance, standards, frameworks, and regulations is carefully crafted in a best effort to make its purpose clear. Let these key words serve as clues to help you navigate against any confusion.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
Mastering Security Configuration Management
Master Security Configuration Management with Tripwire's guide on best practices. This resource explores SCM's role in modern cybersecurity, reducing the attack surface, and achieving compliance with regulations. Gain practical insights for using SCM effectively in various environments.
