The Tyranny of the Cybersecurity Lexicon

Recently I embarked on a journey to transform my rather ad-hoc computer network used for my home and my consulting practice to something that would reasonably represent the current and upcoming requirements by federal agencies for cybersecurity. It has been daunting challenge - this from someone who was as 'cutting edge' computer literate as one could be in the late 1980's and early 1990's.

I was an electronics technician during y enlisted days in the Air Force and did nitty-gritty level ones and zeros type of troubleshooting and flicked DIP switches to configure hardware in my sleep. I was pretty good from the command line on VMS, Unix, DOS, RSX-11, and CPM. I was a geek!

Today I struggle with with cybersecurity - not because I don't understand computers and operating systems - but because simple concepts we once understood have been transformed into mystical towers of Babble by practitioners of the trade. Cybersecurity is not alone in this realm ... they share their tecno-gibberish propensities with the Risk Managers and the Project Managers and - to be perfectly honest - almost every "professional" occupation that exists.

The term ‘Profession’ stands for an occupation which requires some specialized study and training, and the purpose of which is generally to provide skilled services and guidance in exchange for a definite fee or remuneration (see: https://www.preservearticles.com/education/what-are-the-important-characteristics-of-a-profession/18305). The "specialized knowledge" often includes a lexicon of terms that are uniquely defined or used by the profession - often outside of their normal meaning or definitions - and herein lies the problem with cybersecurity compliance.

Reading the principle Cybersecurity guidance for federal government contractors leads one to NIST SP 800-171 Rev. 2 PROTECTING CONTROLLED UNCLASSIFIED INFORMATION which, in turn, is heavily dependent upon the Framework for Improving Critical Infrastructure Cybersecurity (see https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf). The "Framework" described in this document is the first of a dizzying array of constructs developed to describe the cybersecurity bureaucracy created by the government and willingly endorsed by the "professional community".

Rather than simply and clearly stating that cyber threats to ones information system are a risk and should be treated as such we are treated to concepts such as the Framework Core, Implementation tiers, and Framework Profiles. Had they simply limited their document to Paragraph 1.2 "Risk management is the ongoing process of identifying, assessing, and responding to risk. To manage risk, organizations should understand the likelihood that an event will occur and the potential resulting impacts. With this information, organizations can determine the acceptable level of risk for achieving their organizational objectives and can express this as their risk tolerance." we all would have been better served.

Instead we are treated to a regurgitation of risk management 101 tied into various categories and subcategories - all tied to specific standards, guidelines, or common practices. While I'll gladly acknowledge being a bit of a Risk Management geek and actually enjoying a dip into the quantitive side of the process I doth protest the need for a Cybersecurity Manual to take an existing process (RM) and change the terms and the process such that it is now rebranded as a Cybersecurity process that we will be judged upon come certification time.

Thus my major complaint .. while the language of NIST 800-171 - which is expanded (thank you very much) in NIST.HB.162 which is a self assessment tool - it is still unclear and needs further refinement and definition before business people like myself will be able to understand or make sense of it. Here is a simple example:

"3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, or devices (including other systems)". To the average business person we would interpret this as:

1. Do you have a process by where employees are given an account on your business systems with a unique user name and password?
2. Do employees have to get approval from HR or a manager proving their employment and need to access the systems before such credentials are issued?
3. Are employees who leave the company for whatever reason removed from the user database or their credentials invalidated?
4. Does your system (e.g., domain server or similar) verify the user's credentials before allowing them to access the system?

But what is not said or clear from the verbiage in 3.11 is the business about "processes acting on behalf of authorized users, or devices (including other systems)". What does this mean? This innocuous language turned a 15 minute verification into a literal Easter egg hunt. How so? Because what is not defined here is the concept that "processes" includes action taken by software on the user's computer whereby clicking on Help in a program may access a software vendor's website ... how many applications on your systems do that?

The underlying point is the document was written for "professionals" or "Practitioners" and not the actual audience that will be using the handbook "This Handbook provides a step-by-step guide to assessing a small manufacturer’s information systems against the security requirements in NIST SP 800-171 rev 1,"

And thus we have the tyranny of the "Cybersecurity" lexicon which is being foisted upon us by well intentioned government personnel who forget several basic precepts of writing:

1. Don't try to reinvent the wheel. If there is a well recognized process or method for doing something use it instead of trying to reinvent the process. using your own conceptual language.
2. Consider your audience. Leave the jargon at the door - or at least define it in context.
3. Don't assume your audience has the same knowledge of the subject matter that you do. These manuals and texts are usually written by well-informed experts for those who yet to master the subject ... give them a break and use clear descriptions and common language and help by pointing out pitfalls along the way.

I will eventually achieve some level of cybersecurity that will be acceptable to the government - be it via a self certification such as is required by the Federal Acquisition Regulation or a more robust level such as Cybersecurity Maturity Model (CMM) certification. It will be a journey of discovery I'm sure. But the keepers of the knowledge don't need to set the bar higher than need be by making the guidance more confusing than need be.