**You Call That A Security Requirement?**

Proper Requirements Are The First Step To Verifiable Security

16 min readApr 11, 2020

All too often, organizations lack any appropriate definition of their security requirements. And, the alleged requirements documents that do exist are most likely design specifications, not requirements specifications. Serious security breaches are unavoidable without a proper understanding of what is to be secured and why. That is, serious security breaches are unavoidable without proper security requirements.

Context

When I go into an organization on a consulting job, among the first questions I ask is, “What are your security requirements?” Usually, the answer is, “Formal requirements? We don’t have any.”

That answer would not be surprising for the average small- to medium-sized business. But, it is all too often the answer I receive when talking to large international corporations who should know better. Usually, the excuse is, “We don’t have the time even to document our current security and its configuration, not less develop requirements or do any real design. We barely have the time to put out one fire before we have to go fight another one.”

In a nutshell, that’s the state of most organizations’ security. And, it goes a long way to explaining why we have so many breaches: If you don’t have formal security requirements, how can you possibly know what it is you have to secure and against what threats you have to defend? And, without requirements, how can you properly and adequately test that security?

Well, you can’t.

An even bigger nightmare is product security. There, the story I usually hear is, “Well, our objective was to get the product to market. We didn’t even think about security. All we were worried about was functionality.” Or, the similar argument, “These are all legacy products. Security wasn’t even a consideration when they were designed.” And, if you throw in industrial control systems, “The Internet didn’t even exist when we designed these controls, and no one had even heard of cybersecurity back then.”

Then, there’s my favorite excuse, “We’re an agile organization. With agile, you don’t do requirements, and you don’t write documentation.” When I hear that, I don’t know whether to laugh, cry, scream, or bang my head against the wall. Clearly, those organizations understand neither agile nor security. Trust me: There are a lot of organizations that follow that exact practice.

Now, I will admit that the arguments about legacy systems and products are legitimate. Twenty-five years ago, who had a clue that grandma’s pacemaker could be hacked? Yes, a few of us cybersecurity industry old-timers had a clue. But, until those vulnerabilities became publicly demonstrable, our concerns were not seriously considered.

Products (including IoT devices) and industrial controls security face their unique set of challenges. Quite often, existing “stuff” can’t be modified to add on security. For products where security can’t easily be “bolted on,” that quite often means product redesign (i.e., new hardware). For industrial controls and systems in regulated environments (e.g., medical, aerospace), it quite often means network redesigns to isolate sensitive insecurable systems.

But, regardless of whether it is IT systems, networks and network devices, IoT products, medical devices, autonomous vehicles, industrial controls, spacecraft, buildings and premises, or any other asset requiring security, you are never going to adequately secure it if you don’t know what the requirements to secure it are.

Then, there’s the problem of how to identify and specify requirements. That’s the focus of this blog post. It’s such a common problem, there even have been numerous Dilbert cartoons on the subject: This is my favorite.

Security Must Be A Well-Engineered Process!

Too many organizations approach security in a disorganized and haphazard manner. It usually starts with the discovery of a breach, a new regulatory requirement, or an executive decision to “do something about security,” and then proceeds to become an endless fire-fighting effort.

Needless to say, this approach leads to severe security gaps that result in breaches. And, when a breach occurs, everyone is shocked that, “we spent all this money on security and we still got hacked.” And then the cycle repeats, only in a more frenzied manner. Security quickly degrades into following shampoo instructions (Lather. Rinse. Repeat.).

Instead of treating security as a problem where there is never the time (nor money nor staff) to do things right, but there is plenty of it to continually fight fires, organizations need to take a “time out” and begin to address the underlying problems that keep them in fire-fighting mode. Yes, you have to continue to fight fires, but you also have to start removing the fuel feeding the flames. Otherwise, you are going to get badly burnt!

Once forced (usually by upper management) to end the “security fire drill” and make security a properly organized engineering effort, that effort invariable seems to begin in the middle instead of the beginning. It often starts by hiring security analysts to discover weaknesses in the organization’s security. The usual scenario is that an analyst exposes a security weakness, and a security engineer proposes a solution that she thinks will solve a given problem. The “let’s use this security appliance to solve that problem,” is the standard approach to security engineering in too many organizations. With an approach like that, no organization will ever reach a reasonable degree of security preparedness.

That type of “engineering” approach simply creates a new fire-drill sequence. Because, that’s not an engineering approach to anything, not less security.

When told that the organization must have a formal, documented, engineering approach to security — and it’s explained what that means and what’s involved — the standard reaction is, “We don’t have the time or money for that!” But, as stated previously, they always seem to find the time (and money) to continually “reinvent” security, fixing “new” problems never identified when applying the last bandaid (tourniquet?). And, they seem to have all the time and money in the world required to clean up after a breach, and its damage to the organization’s reputation.

I cannot overemphasize this: Security must adopt an engineering mindset if we are ever to secure an organization’s systems adequately (or, to develop and deploy secure products). That means that creating a formal engineering process to engineer and document security. And, that process needs to start at the beginning with determining what must be security and why. Note well that I didn’t say “how” it will be secured — how is design, not requirements!

Let me reemphasize that point: requirements answer the question “what,” and design answers the question “how.” And, I’ll warn you, I’m going to repeat that many times in this article, because incorrectly differentiating requirements (what) from design (how) is the number-one mistake made when developing requirements. It’s an easy mistake to make, and it takes careful thought and review to identify when design has slipped into requirements. But, confusing the two will result in design errors, leading to probable weakness in the implemented security.

So, let’s talk about the fundamentals that need to be addressed first.

Most organizations have exactly three security implementation problems:

They have no idea what everything is that needs securing;
They have no idea what are the requirements for securing those things they do know about; and
They have no budget for the staff and tools necessary to secure their known assets adequately.

The budget and staffing problem is real, serious, and often limits an organization’s ability to “do things right.” But, it is fundamentally a political problem, and I’m not going to dwell on it here. Well, other than to say that whoever is in charge of security needs to market security to the C-level executives and the Board of Directors. Those executives must be made aware of the risks to the organization should it experience a major breach, and the resultant damage to the organization’s reputation. (I will discuss how to present technical security information to executives in the upcoming blog post: Hacking The Boardroom: Presenting Technical Information To Non-Technical C-Level Executives.)

So, let’s talk about security engineering and security requirements.

We being our effort by going down two different paths simultaneously:

Identifying what we must secure, and
Identifying what our security mandates and constraints are.

That means we need an inventory of what must be secured, and we need to know what business, regulatory, and legal mandates and constraints are imposed upon our organization, product, or both.

Let’s begin with organizational security. And, we’ll first discuss inventory.

I’ll start with a simple question (to which I already know the answer): Do you really know everything on your network? If your answer isn’t “no,” then I know you’re either lying or naive to an extreme.

Obviously, you must consider all the organization’s computers and network infrastructure. But, how about everything else on your network? Do you know if your HVAC system is on your network? How about your employee badge readers? Or, security cameras? Or, fire alarm system? Do you absolutely know for sure whether they are or are not on your network?

And there’s the issue of BYOD devices… many (most?) of which are so insecure they shouldn’t be allowed anywhere near your corporate network, much less used to access some of its most sensitive resources.

Also, do you have a complete inventory of all of your software? Do you even have a good, solid, partial inventory of your software? How are you preventing users from installing unauthorized software?

Well, you get the idea: If you don’t know about it, you can’t secure it! Not knowing about it is what leads to surprise security breaches (think Target and its HVAC systems!).

While an inventory of what must be secured occurs, a separate effort of determining the mandates and constraints imposed upon your security should occur. For an organization, this effort should answer questions such as:

What are our industry’s security best practices? [See note 1.]
What are the regulatory mandates to which our security must conform?
What are our organization’s standards and practices?
What are our organization’s policies and procedures?
What are our organization’s GRC mandates and constraints?
What are our existing designs and implementations?
What are executive management’s objectives and constraints?
What are current security recommendations from threat intelligence feeds?

If it’s a product for which security requirements are to be determined:

What are our industry’s security best practices? [2]
What are our vendor’s recommended security best practices?
What are the regulatory mandates to which our security must conform?
What problem is the product trying to solve?
What is the product’s operational concept?
What are marketing’s security requirements?
What are product management’s security requirements?
What are the anticipated customer security requirements?
What are current security recommendations from threat intelligence feeds?
What security requirements must we impose upon our supply chain?
What are our anti-counterfeiting and anti-tampering requirements?

And, the above is only a sample of the types of mandates and constraints that must be considered when developing security requirements.

What Is A Requirement and What Is Not?

Although the requirements engineering process is fundamental, that’s not the point of this article. Rather, I will focus on what is a requirement and what is not a requirement, and why it is essential to have solid security requirements.

As I briefly discussed in the previous section, that prior to developing your requirements, you must know what it is that must be secured (your inventory) and to what mandates and constraints your security requirements must conform (why each security requirement is necessary).

Let’s begin by examining an example. These are typical examples of the types of requirements I often find in security requirements documents for both corporate business systems and product engineering. Here are three different types of requirements: network, hardware, and database:

The PAN firewall shall proxy all encrypted inbound and outbound traffic, including SSH, and inspect the traffic in clear text.
The security controller shall hold the CPU and GPU in reset until after it has verified the integrity of the BIOS.
GreenSQL shall filter all database traffic.

First, the most important question: Are these good requirements?

Go back and reread the above requirements and stop and think hard about the question: Are these good requirements? Think about it: Why or why not?

You should have gotten a clue from the title of this article… But, still surprising to most, these are not good requirements! In fact, they are not even requirements — instead, they are design statements. As I have said repeatedly now, requirements answer the question “What?” and designs answer the question “How?”. The above statements all address how something is supposed to be secured, not what security is necessary and why. [3]

For that matter, these aren’t even very good design statements, as they leave too many open issues. For example, two of the three statements require that something is to be “inspected” or “filtered” — inspected or filtered for what? They are simply incomplete and ambiguous, leaving too many things unspecified — just begging for security gaps to be created.

If you don’t know what security is necessary and why, how can you be sure you are doing it correctly? Requirements must come before design; else, we will have serious gaps! And, by now, I hope you know where security gaps lead.

So, how should the above statements have been written if they were proper requirements?

To prevent data exfiltration and detect security threats: When crossing a network trust boundary, all traffic, both encrypted and clear text, shall be inspected for policy compliance and security threats.
– Non-compliant traffic shall be handled as per policy, as follows (and either detail those policies in subparagraphs or reference policy mandates and constraints elsewhere).
– Traffic comprising security threats shall be logged, then discarded, as follows (and detail the actions for various protocols in subparagraphs or references).
To ensure the integrity of the boot process: The integrity of the first stage of any and all boot loaders shall be verified prior to execution.
To prevent unauthorized information disclosure and data tampering, and to defend against attacks against the database itself: All database transactions shall be filtered prior to transaction execution. The minimum filtering to occur shall include (and detail those filters in subparagraphs or references).

That is, we’re first stating why we need a requirement, and what security is required. Notice that nowhere did we state how something was to be done, only what was to be done. Again, you address the how, when you do your design.

Hopefully, the difference between design statements and requirement statements is now at least a little clearer.

The one thing missing from each of the above requirement statements was the justification for that requirement’s existence. There must be some base document that states a need for each requirement. Some organizations choose to reference the reason in the requirements itself (e.g., As per <document, page, paragraph>, to…). However, most organizations find that an easier solution is a Requirements Traceability Matrix (RTM), which matches every source document’s mandate or constraint with a requirement that satisfies it. The RTM also makes it easier to ensure that the full set of requirements have been identified and that every requirement has a supporting mandate or constraint.

What Constitutes A Good Security Requirement?

For every well-written requirement I see — be it for security, software, firmware, hardware, networks, processes, environment, or whatever — I probably see a few thousand poorly written requirements. Worse, many (most?) of these “requirements” aren’t even requirements, but — like in the earlier examples — are design statements. So, how do you know what constitutes a good requirement?

The IEEE has written an excellent guide to writing software requirements. With a small amount of obvious tweaking, this guideline can be used to develop any type of requirements specification document. [4]

Without question, the most valuable part of the IEEE guidelines is the list of characteristics of a good requirements specification. It covers both the characteristics of a good requirement statement and the characteristics of a good requirements specification. Those characteristics are as follows: [5]

Correct: It is a necessary and justifiable requirement, and it specifies “what” is to be done (that is, it is a requirement statement, not a design statement).
Unambiguous: The requirement is not subject to interpretation.
Verifiable: There is a clear means of verifying (e.g., testing) that the requirement is implemented correctly.
Consistent: The requirement is both consistent with all other requirements in the specification document, and is also consistent with the reference document(s) that justify the need for that requirement. It also means that wording throughout the document is consistent, such as the consistent use of verbs to specify the importance of the requirement: for example, use either “Shall” or “Must” but not a mixture of the two when specifying mandatory requirements.
Traceable: There is both a clear justification for the requirement which the requirement can reference, and the requirement is written such that the design statement that results from the requirement will be able to reference the requirement as justification for the design statement. It should also be noted that testing statements also need to reference back to requirements, as it is requirements that must be tested, not designs (but this does not preclude also testing the design and implementation).
Modifiable: The requirement is written in such a manner that the requirement can be easily changed, preferably with minimal impact on other requirements.
Ranked: What is the requirement’s relative importance?
Complete: A requirements specification is complete only when: each and every requirement is a complete statement of the “what” is required, and the requirements specification itself is the full set of necessary requirements.

The consistent and correct wording of requirements is critical. Besides meeting the preceding list of characteristics, well-written requirements also clearly indicate their level of importance (ranking) by the verb used in the statement. The generally recognized verbs to use are:

Shall: An absolutely mandatory requirement. (Must or Required are the same as Shall.)
Shall Not: An absolutely mandatory prohibition. (Must Not or Prohibited are the same as Shall Not.)
Should: A highly recommended requirement. (Recommended is the same as Should.)
Should Not: A highly recommended prohibition. (Not Recommended is the same as Should Not.)
May: An optional or preferred requirement.
May Not: An optional or preferred prohibition.

There are two parts to ranking requirements: the requirement’s importance (mandatory, recommended, optional) and the phasing of requirements implementation (one set of requirements are to be implemented before a different set).

In general, the ranking of a requirement’s importance should be consistent with the verb used to indicate its importance. That is, all mandatory requirements and mandatory prohibitions should be ranked higher than all recommended requirements and recommended prohibitions, which should be ranked higher than all optional requirements and optional prohibitions.

You should not try to meet all of your security requirements in one sprint. Instead, related requirements should be grouped, and the groups prioritized; then, implemented over time as resources become available. Thus, all requirements in each group should be ranked correspondingly. That is, all mandatory, recommended, and optional requirements in the first group that are ranked higher than the mandatory requirements in the second group, and so forth. This is acceptable and expected, and is one of the reasons for ranking — to specify the order and precedence for the implementation of requirements.

When ranking requirements, it is also necessary to consider dependencies, and to ensure that requirement dependencies are reflected in ranking, such that any requirements that are dependent upon another requirement are ranked lower (order-wise) than the requirement upon which they depend.

Finally, to meet the consistency requirement, for any given ranking, pick a verb and stick with it. For example, for “mandatory” items, use “shall” and “shall not,” and don’t ever use “must,” “must not,” “required,” or “prohibited” to indicate the requirement’s importance.

The real crux of the issue is that requirements must answer the question “what” is to be done and not the question “how” to do it! The lack of precise requirements leads to an incomplete understanding as to what must be secured and why. All too often, the “why” gets overlooked, and the requirement never gets implemented, because the “why” is both your business case and your technical case for the requirement’s existence. And, without the business case, you can’t justify your funding.

One significant mistake which too many organizations make is using GRC mandates and constraints as actual security requirements. GRC mandates and constraints are nearly always statements of what constitutes compliance and not the requirements to be met to become compliant; that is, they do not specify what must occur to become compliant, only the desired result. GRC documents should be among the sources for establishing your security requirements, but not the only sources.

To justify the requirement’s existence, it must always document its origin; that is, it must be traceable back to its origin. Providing backwards traceability provides both your business case for the necessity of the security requirement and a clear means to check that all security mandates and constraints are covered. That is, do we have one or more security requirements we can trace to every security mandate we must meet?

It is also worthwhile to note that traceability substantially increases maintainability. For example, if a regulation changes, then traceability will immediately identify all requirements which were based upon that regulation, which would also identify all design and test statements that were based upon those requirements. Thus, it becomes rather simple to determine the impact of the regulation change; it may not be simple to implement those changes, but at least identifying the changes required is simplified.

Once you have the full set of security requirements, and everyone has bought into them, you can now create your security design. Just make sure that you have every requirement covered by your design, and that a requirement justifies every design statement. That’s where traceability ensures that nobody drops the ball along the way.

Summary

The hardest part of determining your security requirements is discovering everything you must secure and all the security mandates and constraints with which you must comply. But, remember, it’s impossible to secure something you don’t know about.

Requirements are the basis of your security: they specify “what” is to be secured and provide the justification reference to “why” it must be secured.

Arguably, the most critical characteristics of requirements are that they must be unambiguous and verifiable. If a requirement is subject to interpretation (ambiguous), there is no way to assure that the requirement supports the necessary security. If a requirement is not verifiable, there is no way to ensure that it was implemented correctly.

Without well written and traceable security requirements, it is difficult to get the business case supporting the required security accepted, so that appropriate funding is approved.

Notes

Here, “industry” refers to the business’ types of products and services, such as: financial services, health care, automotive, consumer, aerospace and defense, communications, etc.
Here, “industry” refers to both the business’ types of products and services, the industry classification of the product itself, and the industry or industries which would use or deploy the product.
To differentiate between a statement specifying a requirement (or design) and the document containing those requirements (or designs), I use the term “statement” to mean the specification of a requirement, and I use the term “specification” to mean the document containing all the requirement statements. (This goes against the common practice of calling the statement of a requirement a “requirements specification.” But, when reading a discussion of both individual requirements and the document containing all the requirements, it can become confusing as to whether a reference is to a specific requirement, or it is to the requirements specification document. Thus, for clarity, the choice in this article is to use “statement” to refer to an individual requirement and “specification” to refer to the collection of all requirements.)
IEEE Std 830–1998: IEEE Recommended Practice for Software Requirements Specifications.
The order of these characteristics has been changed from IEEE Std 830–1998 and the definitions condensed. Please refer to the actual standard for full details.

Please check out my Blog Introduction and Index to find other postings about what we are doing wrong in security and how we need to fix it.

About The Blogger