Cybersecurity is a vast and complex field, and it’s made more complicated as technology – both infrastructure and in terms of cyberattacks – grows more and more sophisticated. Any large and complex industry grows terminology and jargon like leaves on a tree, and cybersecurity is no different. There are dozens, if not hundreds, of specialized terms that are used in narrow and specific ways throughout the industry. Making assumptions, using common language definitions, or just not knowing what they mean is a recipe for disaster.
Four interrelated terms used in cybersecurity are Policies, Procedures, Standards, Guidelines, and Controls. They have specific meanings, but what are they, and how do they relate to one another? Let’s discuss.
A pyramid or hierarchical organizational structure is common in cases where decisions come from the top, and repercussions trickle down through various levels. This is also how it works with cybersecurity. The five terms above are organized broadly in exactly this kind of hierarchy. Policies are at the top, Standards and Guidelines add detail to policies, Controls are the measured outcome of standards in use, and Procedures are how those controls are implemented.
With the hierarchical structure, you might assume that the element at the top is the most important. But, the truth is, the bottom – the foundation – is the most important part. A policy is a simple overarching statement of what must be done whereas procedures are the exact mechanisms of how those ideals are implemented at that organization and in greater detail, such as who or when details about the tasks.
Let’s talk more about what each specific level means in business and cybersecurity and how it can tie into other elements of standardization and certification in the broader industry.
As we’ve mentioned, policies are at the top of the pecking order. They are the broadest, least “useful,” and least tangible of the elements on this list. Policies answer the question, “What do we need to do, and why?”
A policy is a high-level management decision. It is a goal for your cybersecurity and IT teams to implement. Policies may be things like:
These are good ideals to strive for in terms of cybersecurity protections. But they’re like aphorisms; they are not tangibly useful. They are goals set in place by upper management or, in many cases, third-party organizations. For example, in order to work with the federal government as a contractor, you need to adhere to the policies set forth by the Department of Defense and the government as outlined in documentation from the National Institute of Standards and Technology.
Imagine, for a moment, that you’re the CEO of a cloud services provider. In discussion with your board of directors, you’ve decided to issue a security policy: all employee accounts will use strong passwords to help ensure the security of employee accounts. You go to your head of IT, and you tell them to make sure all employees have strong passwords. That’s a new cybersecurity policy.
Your IT director, meanwhile, has a lot of questions.
None of this is covered in the policy. That’s where standards, processes, and procedures come into play.
As you can see, policies are simultaneously very important and nearly worthless. They’re critical as management decisions and ideals to uphold, but when it comes to the actual process of implementing the policy, it’s not helpful. It’s a destination, not a map.
If policies answer the question of what you need to do and why, standards, processes, procedures, and guidelines answer the question, “What do we need to do to achieve this policy?” A control is a broad set of definitions of the standards, guides processes, controls, rules, and procedures that are required to implement the policy.
To continue the password example, your IT director will outline the standards when they answer the questions. For example, what constitutes a strong password? A strong password has specific attributes:
There’s actually a lot of debate and competing definitions of what a strong password is. Guidance from Google is somewhat different from guidance from Microsoft, for example, and there are good reasons for the differences on both sides. There can also be significant differences in the quality of a password when you’re manually keeping it in mind and typing it in versus using a password manager.
A process covers the end-to-end major tasks with completing an activity, and the procedures are developed as step-by-step instructions on how to accomplish the major and minor activities. Procedures are likely to include screenshots of the application, or a training video on how to use software to complete tasks.
Some organizations may have more discrete and application specific instructions, or work-instructions, but the concept is the same.
To bring things back around – standards in cybersecurity are the sets of tangible milestones or system configuration settings, time windowsand goals to implement to achieve a given policy. Standards can be developed internally, or they can be taken from third-party agencies whose entire purpose is to define standards.
In terms of cybersecurity, standards are often defined by two agencies. The first is NIST, the National Institute of Standards and Technology. Specifically, NIST maintains the CSF, or Cybersecurity Framework, which defines five core functions of cybersecurity policies (identify, protect, detect, respond, recover) and everything that is needed to achieve and maintain a secure operation.
The second most common set of cybersecurity standards is defined by ISO, the International Organization for Standardization. Specifically, ISO 27001 is the broad international set of information security standards and is composed of 114 specific security controls. Other ISO standards, including 27032 and 22301, can play a part as well. Most American businesses, and especially those working with the federal government, are usually going to pay more attention to the NIST standards than the ISO standards, though.
There are also other groups of standards. For example, the Cloud Controls Matrix, from the Cloud Security Alliance, is a set of standards and controls aimed directly at cloud technologies and developed by a third-party organization. There’s also PAS-555, a Publicly Available Specification developed by UK and international groups like BSI and IEC. Again, this isn’t typically relevant to American businesses but can be important for European and international businesses.
If policies are the commands from on high, the directives handed down by management as ideals to achieve, and standards are the set of goals and frameworks necessary to achieve those policies, what then are controls?
Controls are the answer to the question, “How do we manage data loss???”
Controls are, in effect, specific cases and directives that can be defined and implemented to achieve a standard. A control can be technical, physical or administrative in nature. As stated earlier, a policy is developed to reduce risk to the organization as an administrative control. The process of training users to change their password, is another administrative control. The employee can reference the procedure if they forget how to change their password. The administrators set up rules on the computer to lock an account as a technical control if an employee forgets their password and enters the wrong password too many times. If you had to be in the office to change passwords, and the office requires a badge to enter the building to gain access to the computer, that’s a physical control.
The most common controls framework most of our readers will experience comes from NIST. There are two different groups you may encounter. NIST SP 800-53 is the general list of security and privacy controls for organizations. This set includes 20 different control families, including things like access control, configuration management, incident response, personnel security, risk assessment, and supply chain risk management.
The other set of standards is NIST SP 800-171. This is the set of cybersecurity controls for protecting CUI, or Controlled Unclassified Information. This includes a set of controls that overlap somewhat, with categories like access control and configuration management, but also has unique controls such as physical and environmental protection. Some controls are the same or overlap; others are unique.
There are many different controls, and the list is changed frequently in response to changes in standards, technology, society, sophistication of threats, and more. It’s all an evolving system meant to help make sure the best possible security is maintained amongst organizations that adhere to these policies and frameworks.
There are also additional NIST publications for specific sections that may require more attention. For example, NIST SP 800-63B is a special publication with standards and controls for passwords and authentication best practices.
Specific controls related to passwords may be things like:
Controls can also be broader or more narrow depending on their station in the set of control families. For example, here is the list of everything that goes into the Account Management section of the Access Control family in NIST SP 800-53.
Controls can be complex and form a specific set of guidelines to be implemented, which leaves us with just one more term to discuss.
Policies are directives from on high, outlining goals for the organization to meet. Standards are the definitions of what it takes to meet those policies effectively. Controls are specific technical specifications and processes that must be implemented in order to adhere to standards. So what, then, are procedures?
Procedures answer the question, “How do we do what we must to implement a control?”
A control outlines what you need to achieve, and a procedure is the specific set of steps necessary to adhere to that control. If a policy is a destination, a standard is a route to reach that destination; a control is the turn-by-turn directions, and a procedure is how to drive that route.
A procedure is basically a step-by-step set of instructions necessary to achieve compliance with a control. It may be a list of specific steps and objectives, such as:
Procedure: How To build a server on a virtual server:
This is just a taste of what an in-general procedure might be, and further, each one can be broken down into more specific procedures, work instructions, standard operating procedures, desktop guides, or Owners manuals, How-to-Guides, Knowledge Base Articles, deployment guides, etc, etc.. It’s procedures all the way down.
Critically, procedures are the actual actions upon which your cybersecurity processes are built. Procedures are how a policy is brought to fruition by personnel in your organization.
Procedures are also frequently documented. For NIST CSF compliance and for achieving certification with frameworks like CMMC or FedRAMP, documentation is critical. You have to document which controls and which standards apply to you, which parts of your organization they apply to, which individuals in your organization are the people responsible for ensuring implementation, and what procedures are used to perform that implementation.
These frameworks also typically include requirements to document auditing and verification of adherence to these controls and standards via procedures. Auditing is a huge part of compliance and certification, after all.
While all of this is vastly complex, a pyramid made up of hundreds of specific controls and the thousands of procedures that implement them, there are many ways you can make things easier for your organization. Some (like what you can do with STIGs for DISA compliance) can be automated and validated automatically. Others, like DFARS compliance, need to be more wholly documented and manually implemented.
In these cases, you need a dedicated platform on your side to accumulate, aggregate, and monitor all of your standards, their associated controls, and the procedures you’ve put in place.
That’s where we come in. At Ignite, we’ve developed a platform specifically for monitoring and helping to document and enforce compliance for certification across a variety of frameworks. Our platform was built to work with frameworks including FedRAMP, CMMC, those outlined in NIST SP 800-171, and other frameworks like HITRUST and HIPAA. Whatever frameworks govern the security and operations policies for your organization, chances are we can help you document, monitor, and implement those policies.
If you’re interested to see what our platform can do for you, you can click here to book a demo and see the platform in action. We’re also standing by to answer any questions you may have, discuss concerns you have with the platform, and help you determine what level of compliance with what frameworks you need. It’s a complex world out there; we’re here to help make it easier for you to navigate.
*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/security/cybersecurity-procedures-controls-policies/