Domain 3 - Models, Secure Design Principles & Frameworks MindMap

Introduction

Hey, I’m Rob Witcher from Destination Certification, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major topics related to Models and Frameworks in Domain 3, to understand how they interrelate, and to guide your studies.

This is the first of 9 videos for domain 3. I have included links to the other MindMap videos in the description below. These MindMaps are one part of our complete CISSP MasterClass.

As security professionals we need to protect the assets of the organization. Everything from the people, the data, systems, processes, the network, the entire enterprise. This is not an easy thing to do. It’s difficult to conceptualize and think through all the components of these complex systems and processes, of an entire organization.

Security needs to be involved and embedded throughout an entire organization.

In security, we often just speak of data classification. We should be talking about asset classification which encompasses data classification and clearly implies that we should be classifying all the assets of the organization and protecting them appropriately.

Models

We can have models of cars, and models of planes, and models of entire security architectures. Models help us to break down complex systems into their components.

Once we understand the components that combine to create a complex system, we can protect each of the components and thus tackle the problem of baking security into every aspect of even highly complex systems.

We are going to talk through how we have models that focus just on confidentiality, or integrity, or preventing conflicts of interest.

Enterprise Security Architecture

And we’re going to start with models that cover the entire Enterprise Security Architecture.

Let’s begin with some definitions. An architecture is simply a bunch of components that work together

A security architecture is how we protect, how we secure, each of the components in the architecture

And an enterprise security architecture is how we protect all the components of the enterprise, the people, processes, systems, networks, etc.

There are three major enterprise security architectures that you should know about.

Zachman

The first is the Zachman framework. It defines a 2-dimensional table which provides a structured way of defining an enterprise, and therefore breaking it down into components. The Zachman framework defines how, where, who, when and why as the columns of the table, and then some other stuff as the rows of the table.

Honestly, you don’t need to memorize this table. Just know that Zachman is an Enterprise Security Architecture.

SABSA

SABSA, the Sherwood Applied Business Security Architecture, was developed independently of Zachman, but has a very similar structure. The primary characteristic of the SABSA is that it defines a risk-driven enterprise security architecture model that is derived from an analysis of the business requirements for security. But again, you don’t need to memorize the specifics of SABSA.

TOGAF

TOGAF, The Open Group Architecture Framework, is the third major Enterprise Security Architecture framework. And just like Zachman and SABSA, TOGAF helps you break an organization down into components so you can build security into each component.

Security Models

Now let’s look at security models of which there are two major groupings: lattice based, and rule based.

Lattice Based

We’ll start with lattice based. Lattice based essentially means layers. We define different layers of confidentiality or integrity and then define rules about what can be read or written between the layers to maintain confidentiality or integrity.

Bell-LaPadula

Bell-LaPadula or Bell-LaPadula depending on how you want to pronounce it; is a confidentiality only model.

Confidentiality

Simple Security Property

The first rule is the Simple Security Property and it states that to maintain confidentiality, you can only read at your own level and below. You can only read down.

Star Property

The second rule is the Start Property, and it states that to maintain confidentiality, you can only write data at your own level and above. You can only write up.

Strong Star Property

Biba

The second lattice or layer-based model is Biba.

Integrity

Biba is all about integrity. Just remember the I in Biba stands for integrity.

And again, because it is a layer-based model, you define layers. But with Biba they are layers of integrity. Low, medium, and high integrity. And as you have probably guessed the model defines rules controlling what a subject can do between layers to maintain integrity.

Simple Integrity Property

The first rule is the Simple Integrity property, and it states that to maintain integrity you can only read up. If you were to read down, you would be reading less meaningful or accurate data. So, you can only read at your own layer or above. You can only read up.

Star Integrity Property

The second rule is the Star Integrity Property which states that to maintain integrity you can only write down. If you wrote up, you would be corrupting more accurate data. So, you can only write down. Just remember it is the inverse of Be-LaPadula.

There is a third rule, the Invocation Property, but you don’t need to know about it.

Here is a simple diagram that might help you memorize these two important models. Biba is essentially a mirror or the inverse of Bell, and the I in Biba stands for Integrity.

Lipner Implementation

The final piece we will talk about related to lattice-based models is not actually a model at all. It is an implementation. The Bell-LaPadula and Biba models are essentially inverse to each other, so if you want to maintain both confidentiality and integrity, how do you combine these models? Lipner figured it out, and thus it is known as the Lipner Implementation, combining both confidentiality and integrity.

Rule Based

Clark-Wilson

3 goals of integrity

It defines 3 goals of integrity:

1. Preventing unauthorized subjects from making any changes
2. Preventing authorized subjects from making bad changes
3. Maintaining the Consistency of the System

3 Clark-Wilson rules

To achieve these 3 goals, it defines 3 rules:

1. You must have well-formed transactions
2. You must have Separation of duties
3. You must have the access triple – subject & program & Object

Brewer-Nash

Prevent conflicts of interest

has one goal: preventing conflicts of interest.

Graham–Denning

There are a couple of other models that you should simply recognize as being rule-based models.
Graham-Denning specifies rules allowing subjects to access objects.

Harrison–Ruzzo–Ullman

And, Harrison–Ruzzo–Ullman is an enhancement of the Graham-Denning model. It adds Generic Rights. But again, just know it as a rules-based model.

Secure Design Principles

Now let’s move on and talk about various secure design principles, the principles we can use to help securely design, implement, and operate systems. The first 6 principles that we’ll go through here are discussed in more detail in other MindMap videos, so I’ll provide brief explanations. The last five I’ll spend a little more time on.

Threat Modeling

Least Privilege

Least privilege is the principle of Restricting a users ACTIONS to only those actions required for them to perform their role.

Defense in Depth

Defense in Depth is about having multiple layers of security controls, so that if one of the layers fails, if an attacker gets through one of the layers of defense, there are additional layers to protect the asset. Ideally you want a complete control at each layer, a combination of preventive, detective and corrective controls.

Secure Defaults

Secure Defaults is the principle that the default configuration settings for a system should be the most secure settings possible. For example, if you were to buy a new firewall, its default configuration should be to block all traffic. That’s the most secure default.

Fail Securely

Fail Securely is the principle that when a system fails it fails to a higher security state. To use a firewall as an example again, failing securely would mean that if the firewall fails it blocks all traffic. The opposite is failing open. A firewall failing open would let all traffic through if it failed.

Separation of Duties (SoD)

Separation of Duties, Also Known as Segregation of Duties is the principle of having more than one person required to complete a task to prevent errors and fraud. If SoD is implemented, then collusion is required to perpetrate fraud.

Keep it Simple

The KISS principle. Keep it simple stupid, is the universal truth that vulnerabilities inevitably increase as complexity increases. So, keep it simple. Smaller and simpler systems will have less vulnerabilities and they will be easier to test. Economy of Mechanism.

Zero Trust is the principle that organizations should not automatically trust anything inside or outside its perimeters. Instead verify anything and everything trying to connect to, to access organizational assets. Trust nothing – verify everything.

Trust But Verify

Trust but Verify is a very similar sounding principle with a different focus. The idea with Trust But Verify is that organizations cannot just focus on just prevention. You cannot prevent all attacks. And so, the Trust but Verify principle is that organizations should focus on complete controls. A complete control is a combination of prevention, detection and correction. In other words, put preventative controls in place, but assume they will fail so make sure you have good detection and response controls as well.

Privacy by Design

You’ve no doubt heard the expression: bake security in. It is always easier, cheaper, and more effective to build security controls into a system from the very start vs. trying to add security later.

Privacy by Design is that exact concept, except for Privacy. Bake privacy in. Privacy by Design is in fact a whole framework of 7 foundational principles:

• Proactive not reactive – don’t wait for a privacy breach to happen before you think about privacy controls
•  Privacy as the default setting
• Etc.

Shared Responsibility

And the final Secure Design Principle we’ll cover: Share Responsibility – recognizing that pretty much every organization nowadays relies to a great extent on various service providers – such as cloud service providers. Most organizations have a massive reliance on their service providers having good security controls. An organization cannot be secure if their service providers do not have good security controls. So organizations must have clearly defined accountabilities and responsibilities and ensure their service providers clearly understand their responsibilities.

Frameworks

Now let’s talk about the major security frameworks that you need to know about for the exam.

ISO 27001

The major framework that you need to know a fair bit about is ISO 27001. It is the most widely used security framework in the world. ISO 27001 provides best practice recommendations for an ISMS, an Information Security Management System. 27001 defines 114 controls across 14 categories in what’s called Annex A of the standard. These controls define all the best practices you should have in place for a well-run security program starting from the top with security governance, security policies, through onboarding, asset management, access control, cryptography, physical security, network security, and all the way to having a compliance function. It is important to remember, that ISO 27001 defines the controls, and you can therefore be ISO 27001 certified

ISO 27002

ISO 27002, on the other hand, provides the Code of practice for information security controls. In other words, the implementation guidance for the controls in 27001. So, can you be certified against ISO 27002? No, it’s just a guidance document.

NIST 800-53

Now the next few security control frameworks that I am going to talk about – you do not need to be an expert on any of them, simply know what they are primarily focused on and used for.
NIST 800-53, for instance, provides a set of security and privacy controls for US federal agencies

COBIT

COBIT, the Control Objectives for Information and Related Technologies, was created by the IT Auditors at ISACA, and because it was created by IT auditors, it is particularly useful for audit and assurance work.

ITIL

ITIL, the Information Technology Infrastructure Library, defines a framework of best practices for delivering IT services that are aligned with business goals and objectives. So ITIL is particularly useful for looking at IT processes like change management, configuration management, access management, event management, availability management, and so forth.

HIPAA

HIPAA, the Health Insurance Portability and Accountability Act, predictably is a framework focused on safeguarding medical information.

SOX

SOX, the Sarbanes–Oxley Act. We can thank Enron and WorldCom for this US federal law. SOX requires top management to individually certify the accuracy of financial information, and if fraudulent activity is found, the penalties are much more severe. The security aspect of SOX is that the financial records must have integrity and be available.

FedRAMP

FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. Any US Federal Gov entity that wants to use Cloud services - those cloud services must be FedRAMP approved.

FISMA

FISMA defines security requirements for US Federal Gov. agencies and contractors. FISMA requires each US Federal Gov. agency to develop, document, and implement an agency-wide program to provide information security.

Cyber Kill Chain

The last framework I’ll talk about here is the Cyber Kill Chain - sometimes referred to as the Cyber Attack Chain. The basic idea of the Cyber Kill Chain is that it defines 7 stages of common cyberattacks and, therefore, the stages / the links in the chain at which the security team can prevent, detect or intercept attackers. Break a link in the chain = no cyberattack. The earlier you can break the chain, the less chance an attack is going to harm the organization.

The 7 stages of the Cyber Kill Chain are: 1. Reconnaissance, 2. Weaponization, 3. Delivery, 4. Exploit, 5. Installation, 6. Command & Control and 7. Actions. Make sure you know the order of the 7 stages and high-level what is happening at each stage.

And that is an overview of Models and Frameworks in Domain 3, covering the most critical concepts you need to know for the exam.

As you are likely gathering from these MindMaps videos, there is a ton of terminology that you need to learn. And learning nice concise definitions for these terms will make it much easier to pass the exam. You will be able to better understand what a question is asking you and it will be much easier to pick out the best answer to a question if you know the terminology.

This is why we have written well over 1100 flashcards and built our own custom app to make it as easy as possible for you to learn the terminology you need to know for the exam.

Our awesome app is currently completely free.

Links to download our free app are in the description below.

If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.

I will provide links to the other MindMap videos in the description below.

Thanks very much for watching! And all the best in your studies!