NIST is Foundational

In last months article, we talked about spec’ing your cybersecurity tools to fit your organization just right. When you choose too much tool, you pay for functionality you don’t use. Conversely, if you under-tool the organization, you can be missing out on crucial functionality. We pick up this week assuming the correct sizing has been made, and the tools are ready to be used. Cybersecurity policy is where the rubber really meets the road. Can you name the policies that you employ to enforce your cybersecurity stance? From terms of use policies to the information security policy as a whole, what really ends up giving your security program teeth is the policy that backs it up. In this article, we introduce the concept of NIST cybersecurity policy frameworks and why you should seriously consider building a cybersecurity policy program around it.

‍

‍

“But Policy Will Make My Organization Bureaucratic and Slow”

Before talking about building a cybersecurity policy program, we should address the elephant in the room about the perceived usefulness of policy in the first place. Having interacted with a lot of folks who run successful businesses, their focus is usually much more on creating value for the business, and time spent doing work such as writing a terms of use or an information security policy isn’t exactly viewed as a value-add. It’s understandable; how can writing about the cadence you check logs and who checks the logs be useful? Words on paper don’t achieve goals, nor do they make the company any better off. On top of that, how often do we hear about a policy being written and then never followed, never reviewed, and left for dead? Too often. Policies become long and daunting, never accomplishing their goal.

With all that out of our system, here’s the good news. The truth is, policy was never meant to be written and left on the shelf to collect dust. It was also never meant to be suffocatingly long. Simply the definition of the word policy should set our sights straight again, “a definite course or method”. Considering all of this, a correctly written cybersecurity policy’s main goal should be eliminating uncertainty and creating repeatability. The correct implementation of policy should never result in a decrease inefficiency, but instead an increase. From catching problems before they cause issues to easing training of new employees, defining how the machine should run will make it easier to run. Be the judge of it yourself with the examples below.

Situation: An employee managing your security tool is onboarded and needs to know what their job entails.

• ‍No Policy: The previous operator trains the employee over a period of weeks to transfer knowledge. At the end, some steps get lost in translation and the responsibility for duties may be confused. Who will run the email filter? Will the employees reach out to one another to ensure it's being covered?‍
• Policy: The areas which are being monitored are defined and have a set cadence for review set. There is no confusion about who runs the tool, as we have it defined in writing who is responsible. The transfer is smooth, and uncertainty is reduced.

Situation: A data breach happens due to a user utilizing a company laptop as a personal device in the evenings after work.

• ‍No Policy: There was no terms of use to define the usage of the device, and the user was never aware that wasn’t allowed. As a result, the company is legally responsible for the impact as no policy was defined.‍
• Policy: The terms of use made it clear the corporate device should not be used for personal reasons. Even if the breach still occurred, any impending legal case is swayed much more towards employee’s responsibility for not following the agreement with the company. The cybersecurity insurance policy will be much more likely to help cover damages from negligent use rather than negligent precautions.

Situation: We have an email filter that we want to use to protect us from email bound threats.  

• ‍No Policy: The monitoring is a judgement call made daily by the operator. Some days they may check the filter, while others they get too busy to check. On days they feel alert, they may check all of the alerting locations for threats. On tired days, though, sometimes they forget to check a queue or two.  
• Policy: The monitoring policy stipulates the queue is checked every day by the responsible IT provider or personnel. All the monitoring locations are defined, and a checklist is provided to take the burden off the analyst for having to remember each step, every day. If the process was not followed, this is a case of employee negligence rather than negligence on the part of the company.

The examples above simply highlight the reality of human nature. We will want to take the easiest path, and if the easiest path is checking those queues whenever we feel like it, that’s what we will do. If the easiest path is not switching to our personal laptop after hours, we will stay on the corporate device. As the champion of security, it is our goal to be the shepherd to employees and help make it easy to make the right choice. Nothing will encourage a hastily made bad decision more than not having a path forward to begin with. In relation to organizations that entrust MSP’s or MSSP’s to keep their organizations secure, establishing your policy is even more important to keep them accountable for keeping the company secure.

A Framework is Just a Blueprint

At first glance, using a framework to develop a policy structure can be an afterthought because we intuitively think “I know we need to define these items and we will be fine.” However, let’s think back to the last time we tried to build something on our own with no knowledge on how to build it, or how it is supposed to look. We have all likely tried to build a birdhouse in our lifetime. When you dream up that MTV Cribs bird house your head, it seems so simple to implement! You simply make a cut here, a bend there and……. Before you know it, you’ve overcut your roof piece, undercut the walls, and your shot at a “circular” entry hole resembles that of a preschooler learning to write the letter “O”. Let’s not forget the overachievers among us, though, who spent hours painstakingly designing and perfectly cutting their birdhouse to be exactly like the mental image. What inefficiency do both tactics share, though? Both took much longer than was likely anticipated. The hasty builder realized their design needed to be redone slower to work correctly, and the perfectionist realized they took too much time at the drawing board compared to building. How much faster would both parties have been if they had a framework to work from, a blueprint of sorts?

‍

‍

Don’t Reinvent the Wheel

Luckily, we aren’t the only ones in the world that have ever wanted to build a birdhouse, or as we are more concerned about, a cybersecurity policy program. Thanks to the National Institute of Standards and Technology (NIST), we have tried and true frameworks ready to help us jump off of and get building with. Compared to doing all of the research and development ourselves, this organization equipped with dollars from the U.S. Department of Commerce has done the hardest part for us. As someone who has tried to architect a program like such on their own, here is a short list of problems you will likely run into when you try to reinvent the wheel:

• You missed a vital control domain; you completely forgot about making policy to define your devices’ allowed encryption protocols, for example.
• The matrix to tie policies together turns into an unmanageable mess of lines and conditions.
• The addition of a new policy changes references in 5 documents; a multiplier in effort is applied to shortcomings identified later in the programs development.

After a whole year of work, all of these realizations will converge one sobering thought: The program you “built” is eerily similar to the current standard, except yours is missing seemingly obvious things you never thought of. You could have had a more complete program done quicker if you just followed a blueprint!

Standardization Makes Sense

In addition to the savings in time that can be gleamed from building off of such a blueprint, there is an added benefit to everyone working from the same baseline: standardization. While standardization isn’t exactly a glamorous reason, it becomes incredibly useful when we want to show people how competent our program is. Think of the MPG of your car; it’s incredibly easy to see one car gets better mileage than another, simply because all the manufactures agreed that the metric would be one gallon burned to achieve a set number of miles. Imagine all of the extra work would be needed if instead a car gets 357 miles a tank and a big truck gets 734 miles a tank. We would have todo our own math and work backwards to really figure out the mileage. When we use a standardized framework, it becomes easy to show apples-to-apples that our program has excellent device security because we can compare the same grading criteria to other organizations to see if they are up to snuff. On top of this, if everyone got to decide their own idea of “perfect” security, one persons idea may be completely off base compared to another person’s. We need standards to objectively assess where organizations are in their cybersecurity journey.

‍

‍

Cutting the Confusion

One of the reasons people shy away from these standardized frameworks is the fact that initially coming to understand them can be difficult. There are dozens of applicable frameworks that you could follow! We’ve outlined the critical ones that you need to be aware of below, and the different levels of competency that people generally possess when picking one. There is one crucial note to be made here: Within NIST 171r2, the government defines that NIST 800-53 NFO controls need to be present in all non-federal organizations. This means, you! What an excellent starting line they have provided us. The excerpt from page 84 of NIST 800-171r2is as follows, “The control or control enhancement is expected to be routinely satisfied by nonfederal organizations without specification.”

‍

‍