Information Security Frameworks
We will begin our discussion of information security building blocks with an examination of security frameworks. These are an essential foundation for any security program. There are several questions that we will specifically attempt to answer.
- What is an information security framework?
- What frameworks are available for us to work with?
- What is the appropriate framework for our organization?
- What should we expect to find in the various frameworks?
Information security frameworks will guide the development of the strategy that will guide our information security efforts. Properly implemented, they can assist us with understanding the strengths and weaknesses of our current program. We will use this information to develop guidance on needed changes.
Let’s first define a framework in the context of information security. It is a structure that is comparable to a “frame” in the construction industry. A building frame usually consists of two-by-fours and gives shape to the design shown on a blueprint. An advantage of using existing frameworks is that they are proven designs that are proven to work. Numerous organizations have usually tested a framework like the CIS Controls.
Auditors will question organizations that attempt to create their frameworks from the ground up. Organizations like CIS and NIST provide proven tested roadmaps used in several industry verticals. We will increase our credibility by using one of these proven frameworks.
It is common to see one of three types of frameworks applied in information security programs. These are risk frameworks, control frameworks, and program frameworks. A risk framework will be concerned with measurable uncertainty. The goal is enablement to identify methods to protect our organizations. Control frameworks are like parts catalogs. CIS Controls and NIST 800-53 are two examples. These both contain vast collections of controls covering just about every aspect of any information security program. Finally, we can compare program frameworks to an instruction manual. These show us how to fit the “parts” together into a cohesive whole.
We should always start with the identification of risks to provide a gauge of our threat environment. In a sense, identifying risk enables us to understand more clearly the threats we are facing. It will not do us any good to implement programs that do not address the dangers faced by our organizations. Many such programs have led to wasted investments of technologies unable to address the most prevalent risks.
We will begin to consider security controls once we have identified the risks our organizations face. The CIS Controls Framework is an example. These are vital controls that focus on asset management, identity management, and other high-level parts foundational to any successful security program. The level of controls available will vary the framework used. The CIS Control list has eighteen, and NIST 800-53 has more than a hundred.
Many organizations use the CIS Controls, which provide a “prioritized” categorization of controls. The authors attempted to create a list that begins with foundational controls. We implement these first. We will examine each control in the CIS list at a later point in our study. There are a few I will mention at this point for illustration.
The CIS Control list begins with an inventory and associated security controls involving our physical assets. It is closely associated with the second control that focuses on security controls involving software and applications. If we do not know what systems are active on our networks or what software is running on them, we cannot secure them. I’ve observed that many companies have systems to manage the distribution of patches without an associated inventory of assets. How do they know that every active system has received them?
Continuous vulnerability management is the seventh CIS Control. Implementation of this control requires deploying a tool such as Nessus or Qualys that can scan our entire physical network. These scans will identify unpatched and misconfigured systems. We will use this information to drive change control and remediation processes. Success in this area requires us to have a solid inventory of our physical assets.
The fifth and sixth CIS controls focus on user account control and access management. Attackers will need access to succeed in compromising our systems. They need “admin” level access, and therefore privilege escalation attacks are usually precursors for any attempt to compromise our networks.
Utilizing a security control framework such as CIS provides means to focus implementation and remediation efforts. For example, if we identify issues in the identification phase, we will have a much better chance for successful remediation than if we address them in the protection phase. We will discuss the stages in more detail. I mention them now to show that the earlier we can increase the effectiveness of our security processes, the more likely we will be to succeed in our efforts.
Invariably security professionals will ask about penetration testing. CIS has historically included this at the bottom of its lists. Penetration testing is a vital part of any security program. It is usually included at the bottom of security control frameworks to ensure we correctly implemented previous controls. In an ideal world, penetration testers will not find any vulnerabilities and fail in their efforts as a result. The ideal does not exist, and the testers will find a way to compromise our network in most cases!
We have discussed risk and control frameworks and will now look at program frameworks. A question commonly asked is why these are needed if our organization has already implemented the CIS Controls?
I said earlier that a control framework such as the CIS or NIST frameworks is comparable to a parts catalog. They do not necessarily guide how we assemble the parts that are listed. Program frameworks tell us how to put the pieces together into a cohesive whole. The NIST Cybersecurity Framework is an example. It consists of five functions:
These represent a business process by which we can implement the “parts” listed in our control frameworks. They are the highest level of abstraction and act as the backbone on which the “parts” will be organized around.