Security Principles

Dr. Greg Bernstein

April 11th, 2021

Security Principles


Saltzer and Schroeder Principles


The earliest collected design principles for engineering security controls were enumerated by Saltzer and Schroeder in 1975. These were proposed in the context of engineering secure multi-user operating systems supporting confidentiality properties for use in government and military organizations.


From Wikipedia: Security Controls

Security controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets. In the field of information security, such controls protect the confidentiality, integrity and availability of information.

Economy of Mechanism

The design of security controls should remain as simple as possible, to ensure high assurance. Simpler designs are easier to reason about formally or informally, to argue correctness. Further, simpler designs have simpler implementations that are easier to manually audit or verify for high assurance.

Example: Economy of Mechanism

This principle underlies the notion of Trusted Computing Base (TCB) — namely the collection of all software and hardware components on which a security mechanism or policy relies. It implies that the TCB of a system should remain small to ensure that it maintain the security properties expected.

Question: Simpler is Better?

Given two “mechanisms” that can perform the same “security job” why would you prefer the simpler of the two?

Example: Trusted Platform Modules (TPM)

From Wikipedia: TPM

TPM diagram

Example: TPM Windows

TPM Info in Windows

Fail-safe Defaults

Security controls need to define and enable operations that can positively be identified as being in accordance with a security policy, and reject all others. In particular, Saltzer and Schroeder warn against mechanisms that determine access by attempting to identify and reject malicious behavior.

Fail-Safe Defaults: Discussion

Malicious behavior, as it is under the control of the adversary and will therefore adapt, is difficult to enumerate and identify exhaustively. As a result basing controls on exclusion of detected violation, rather than inclusion of known good behavior, is error prone. It is notable that some modern security controls violate this principle including signature based anti-virus software and intrusion detection.

What’s Wrong with AV and IDS

  • Does this principle say what it “sounds like”?

  • Why do the authors claim that AV and IDS systems don’t follow this principle?

Complete Mediation

All operations on all objects in a system should be checked to ensure that they are in accordance with the security policy. Such checks would usually involve ensuring that the subject that initiated the operation is authorized to perform it, presuming a robust mechanism for authentication. However, modern security controls may not base checks on the identity of such a subject but other considerations, such as holding a ‘capability’.

Complete Mediation Questions

In the context of an operating system

  • What are the objects they may be concerned with?
  • What are the operations they may be concerned with?
  • What are the “security policies” that would be enforced?

Open Design

The security of the control must not rely on the secrecy of how it operates, but only on well specified secrets or passwords. This principle underpins cyber security as a field of open study: it allows scholars, engineers, auditors, and regulators to examine how security controls operate to ensure their correctness, or identify flaws, without undermining their security. The opposite approach, often called ‘security by obscurity’, is fragile as it restricts who may audit a security control, and is ineffective against insider threats or controls that can be reverse engineered.

Open Design: Question

Does the “open design” principle say we should reveal all the details about our system?

Separation of Privilege 1

Security controls that rely on multiple subjects to authorize an operation, provide higher assurance than those relying on a single subject. This principle is embodied in traditional banking systems, and carries forward to cyber security controls.

Separation of Privilege 2

However, while it is usually the case that increasing the number of authorities involved in authorizing an operation increases assurance around integrity properties, it usually also decreases assurance around availability properties. The principle also has limits, relating to over diluting responsibility leading to a ‘tragedy of the security commons’ in which no authority has incentives to invest in security assuming the others will.

Banking Example 1

From Safe Deposit Box

Image Safe Deposit Box

Banking Example 2

From Safe Deposit Box

Safe deposit boxes are kept in a secure vault at a bank or credit union branch. Typically, it takes two keys to open a safe deposit box: your key, plus a key that your bank or credit union retains. To access what’s in your safe deposit box, you’ll need to go to the branch, show proof of identity and provide your key. As the owner of its contents, only you, and not the bank, know what’s held inside it. (The bank or credit union does not hold a copy of your personal key; only you do.)

Separation of Privilege Discussion

  • Separation of privilege in financial transactions

  • Separation of privilege in legal processes

  • Separation of privilege and system administration

  • Separation of privilege in national security

Least privilege 1

Subjects and the operations they perform in a system should be performed using the fewest possible privileges. For example, if an operation needs to only read some information, it should not also be granted the privileges to write or delete this information.

Least privilege 2

Granting the minimum set of privileges ensures that, if the subject is corrupt or software incorrect, the damage they may do to the security properties of the system is diminished. Defining security architectures heavily relies on this principle, and consists of separating large systems into components, each with the least privileges possible — to ensure that partial compromises cannot affect, or have a minimal effect on, the overall security properties of a whole system.

Least Privilege: Root versus Sudo 1

From Help Ubuntu

In Linux (and Unix in general), there is a SuperUser named root. The Windows equivalent of root is the Administrators group. The SuperUser can do anything and everything, and thus doing daily work as the SuperUser can be dangerous. You could type a command incorrectly and destroy the system. Ideally, you run as a user that has only the privileges needed for the task at hand. In some cases, this is necessarily root, but most of the time it is a regular user.

Least Privilege: Root versus Sudo 2

From Ask Ubuntu

sudo lets you run with root privileges and times out, root stays on as long as root is logged in. For security purposes, sudo is better.

Least Common Mechanism 1

It is preferable to minimize sharing of resources and system mechanisms between different parties. This principle is heavily influenced by the context of engineering secure multi-user systems. In such systems common mechanisms (such as shared memory, disk, CPU, etc.) are vectors for potential leaks of confidential information from one user to the other, as well as potential interference from one user into the operations of another.

Least common mechanism 2

Its extreme realization sees systems that must not interfere with each other being ‘air-gapped’. Yet, the principle has limits when it comes to using shared infrastructures (such as the Internet), or shared computing resources (such as multi-user operating systems, that naturally share CPUs and other resources).

Data Center Example 1

Data center server example SuperMicro

Server Spec

Data Center Example 2

This server has:

  • Two 25 Gbps optical (Ethernet) LAN interfaces
  • One RJ45 electrical LAN interface (1Gbps or less) for IPMI
  • Why bother with the low speed interface?

Data Center IPMI

From Wikipedia: IPMI

The Intelligent Platform Management Interface (IPMI) is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system’s CPU, firmware (BIOS or UEFI) and operating system. IPMI defines a set of interfaces used by system administrators for out-of-band management of computer systems and monitoring of their operation. For example, IPMI provides a way to manage a computer that may be powered off or otherwise unresponsive by using a network connection to the hardware rather than to an operating system or login shell.

Data Center Example 3

Least common mechanism the management of the servers in large data centers takes place over a separate network from the high speed user traffic network! These use separate physical interfaces on the servers.

Psychological acceptability

The security control should be naturally usable so that users ‘routinely and automatically’ apply the protection. Saltzer and Schroeder, specifically state that ‘to the extent that the user’s mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized’.

What is Acceptable to You?

  • Frequently require password changes
  • Passwords requiring weird characters
  • Multi-factor authentication
  • Separate passwords per account

Work factor

Good security controls require more resources to circumvent than those available to the adversary. In some cases, such as the cost of brute forcing a key, the work factor may be computed and designers can be assured that adversaries cannot be sufficiently endowed to try them all. For other controls, however, this work factor is harder to compute accurately. For example, it is hard to estimate the cost of a corrupt insider, or the cost of finding a bug in software.

Work Factor Example

  • Dictionary attacks to “crack” passwords are very common, the main way to counter this is to increase the “work”
  • First passwords need to be “salted”
  • Then appropriate algorithms with scalable work factors need to be used.
  • See Password Hashing Competition and Wikipedia: Argon2

Compromise Recording

It is sometimes suggested that reliable records or logs, that allow detection of a compromise, may be used instead of controls that prevent a compromise. Most systems do log security events, and security operations heavily rely on such reliable logs to detect intrusions. The relative merits — and costs — of the two approaches are highly context-dependent.

NIST Principles


From NIST SP800-160v1 Appendix F

Security design principles and concepts serve as the foundation for engineering trustworthy secure systems, including their constituent subsystems and components. These principles and concepts represent research, development, and application experience starting with the early incorporation of security mechanisms for trusted operating systems, to today’s wide variety of fully networked, distributed, mobile, and virtual computing components, environments, and systems.

Security Architecture and Design


Security Capability and Intrinsic Behaviors


Life Cycle Security


NIST Approaches

Reference Monitor Concept NIST 1

The reference monitor concept provides an abstract security model of the properties that must be achieved by any system mechanism claiming to securely enforce access controls.

Reference Monitor Concept NIST 2

The abstract instantiation of the reference monitor concept is an “ideal mechanism” characterized by three properties:

  1. the mechanism is tamper-proof (i.e., it is protected from modification so that it always is capable of enforcing the intended access control policy);

  2. the mechanism is always invoked (i.e., it cannot be bypassed so that every access to the resources it protects is mediated);

Reference Monitor Concept NIST 3

  1. and the mechanism can be subjected to analysis and testing to assure that it is correct (i.e., it is possible to validate that the mechanism faithfully enforces the intended security policy and that it is correctly implemented).

Reference Monitor Example OS 1

From Wikipedia: Reference Monitor Concept

In operating systems architecture a reference monitor concept defines a set of design requirements on a reference validation mechanism, which enforces an access control policy over subjects’ (e.g., processes and users) ability to perform operations (e.g., read and write) on objects (e.g., files and sockets) on a system. The properties of a reference monitor are captured by the acronym NEAT, which means:

Reference Monitor Example OS 2

From Wikipedia: Reference Monitor Concept

  • The reference validation mechanism must be Non-bypassable, so that an attacker cannot bypass the mechanism and violate the security policy.

  • The reference validation mechanism must be Evaluable, i.e., amenable to analysis and tests, the completeness of which can be assured (verifiable). Without this property, the mechanism might be flawed in such a way that the security policy is not enforced.

Reference Monitor Example OS 3

From Wikipedia: Reference Monitor Concept

  • The reference validation mechanism must be Always invoked. Without this property, it is possible for the mechanism to not perform when intended, allowing an attacker to violate the security policy.

  • The reference validation mechanism must be Tamper-proof. Without this property, an attacker can undermine the mechanism itself and hence violate the security policy.

Applying the Reference Monitor Concept

What does this mean in general?

  • Reference: noun “The act of referring to something.” Interpret this as getting access to some object or resource.

  • Monitor: intransitive verb “To keep close watch over; supervise.” Interpret this as controlling access to some object

  • Reference Monitor: Something to supervise references (accesses) to objects/resources.

Common Programming Situation: Web APIs

  • Every access to a web API should be checked
  • Is the user authenticated?
  • Is the user allowed to use the API?
  • Good Web server frameworks make this relatively straight forward

Defense in Depth NIST

Defense in depth describes security architectures constructed through the application of multiple mechanisms to create a series of barriers to prevent, delay, or deter an attack by an adversary. The application of some security components in a defense in depth strategy may increase assurance, but there is no theoretical basis to assume that defense in depth alone could achieve a level of trustworthiness greater than that of the individual security components used. That is, a defense in depth strategy is not a substitute for or equivalent to a sound security architecture and design that leverages a balanced application of security concepts and design principles.

Defense in Depth Wikipedia


Defense in depth is a concept used in Information security in which multiple layers of security controls (defense) are placed throughout an information technology (IT) system. Its intent is to provide redundancy in the event a security control fails or a vulnerability is exploited that can cover aspects of personnel, procedural, technical and physical security for the duration of the system’s life cycle.

Defense in Depth: Home Network

  • House with doors and locks (Physical security)
  • Router with Firewall
  • Computer with internal Firewall
  • Computer/Cell Phone/Tablet with login (password and/or biometric)
  • Applications with additional


From NIST SP800-160 Appendix F

Two forms of isolation are available to system security engineers: logical isolation and physical isolation. The former requires the use of underlying trustworthy mechanisms to create isolated processing environments. These can be constructed so that resource sharing among environments is minimized. Their utility can be realized in situations in which virtualized environments are sufficient to satisfy computing requirements. In other situations, the isolation mechanism can be constructed to permit sharing of resources, but under the control and mediation of the underlying security mechanisms, thus avoiding blatant violations of security policy.

Logical Compute Isolation Examples

  • Separate compute processes
  • Separate compute containers
  • Separate virtual machines

Logical Network Isolation Examples

  • Virtual LANs
  • MPLS label switched paths (LSPs)
  • Separate Autonomous Systems (AS) – IP inter-domain routing

Physical Isolation Examples

  • Separate compute cores on a processor chip
  • Separate processor chips on a server motherboard
  • Out of band management networks
  • Separate fiber optic wavelengths, separate fiber optic cables

Security Controls

Security Controls Definition

Security controls are the safeguards or countermeasures employed within a system or an organization to protect the confidentiality, integrity, and availability of the system and its information and to manage information security risk.

General Types

  • Physical: doors with locks, barbed wire fences, moats with alligators, draw bridges, etc…
  • Technical: network firewalls, passwords, ACLs, cryptography, etc…
  • Administrative: policies (more later)

NIST Catalog of Controls (SP800-53) 1

Security and Privacy Controls for Information Systems and Organizations, NIST Special Publication 800-53 Revision 5 September 2020.

Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and reflecting the protection needs of organizational stakeholders. Controls are selected and implemented by the organization in order to satisfy the system requirements. Controls can include administrative, technical, and physical aspects.

NIST Catalog of Controls (SP800-53) 2

Security and privacy controls described in this publication have a well-defined organization and structure. For ease of use in the security and privacy control selection and specification process, controls are organized into 20 families.26 Each family contains controls that are related to the specific topic of the family.

NIST Control Families (SP800-53) 1

Family Family
Access Control Physical and Environmental Protection
Awareness and Training Planning
Audit and Accountability Program Management

NIST Control Families (SP800-53) 2

Family Family
Assessment, Authorization, and Monitoring Personnel Security
Configuration Management PII Processing and Transparency
Contingency Planning Risk Assessment

NIST Control Families (SP800-53) 3

Family Family
Identification and Authentication System and Services Acquisition
Incident Response System and Communications Protection
Maintenance System and Information Integrity
Media Protection Supply Chain Risk Management

Center for Internet Security Controls

Why CIS Control List

  • NIST SP 800-53r5: “provides a catalog of security and privacy controls for information systems and organizations”. Very well defined and comprehensive, but long 483 pages and not prioritized.

  • “The CIS Controls™ are a prioritized set of actions that collectively form a defense-in-depth set of best practices that mitigate the most common attacks against systems and networks.”

Basic CIS Controls A

  1. Inventory and Control of Hardware Assets

  2. Inventory and Control of Software Assets

  3. Continuous Vulnerability Management More

Basic CIS Controls B

  1. Controlled Use of Administrative Privileges

  2. Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers More

  3. Maintenance, Monitoring and Analysis of Audit Logs More

Foundational CIS Controls A

  1. Email and Web Browser Protections

  2. Malware Defenses

  3. Limitation and Control of Network Ports, Protocols and Services

Foundational CIS Controls B

  1. Data Recovery Capabilities

  2. Secure Configuration for Network Devices, such as Firewalls, Routers and Switches

  3. Boundary Defense

Foundational CIS Controls C

  1. Data Protection

  2. Controlled Access Based on the Need to Know

  3. Wireless Access Control

  4. Account Monitoring and Control

Organizational CIS Controls

  1. Implement a Security Awareness and Training Program

  2. Application Software Security

  3. Incident Response and Management

  4. Penetration Tests and Red Team Exercises

Continuous Vulnerability Management: What

From CIS Vulnerability Management

Continuously acquire, assess, and take action on new information in order to identify vulnerabilities, remediate, and minimize the window of opportunity for attackers.

Continuous Vulnerability Management: Why

From CIS Vulnerability Management

Cyber defenders must operate in a constant stream of new information: software updates, patches, security advisories, threat bulletins, etc. Understanding and managing vulnerabilities has become a continuous activity, requiring significant time, attention, and resources.

Attackers have access to the same information and can take advantage of gaps between the appearance of new knowledge and remediation.

Continuous Vulnerability Management: How

From CIS Vulnerability Management

Utilize an up-to-date SCAP-compliant vulnerability scanning tool to automatically scan all systems on the network on a weekly or more frequent basis to identify all potential vulnerabilities on the organization’s systems.

Deploy automated software update tools in order to ensure that the operating systems are running the most recent security updates provided by the software vendor.

Security Content Automation Protocol (SCAP)

From Wikipedia: SCAP

The Security Content Automation Protocol (SCAP) is a method for using specific standards to enable automated vulnerability management, measurement, and policy compliance evaluation of systems deployed in an organization, including e.g., FISMA (Federal Information Security Management Act, 2002) compliance. The National Vulnerability Database (NVD) is the U.S. government content repository for SCAP. An example of an implementation of SCAP is OpenSCAP.

SCAP Components

From Wikipedia: SCAP, SCAP is built on previous standards

  • Common Vulnerabilities and Exposures (CVE)
  • Common Platform Enumeration (CPE)
  • Common Vulnerability Scoring System (CVSS)
  • Extensible Configuration Checklist Description Format (XCCDF)
  • And more

SCAP Compliant Scanners

  • Commercial from: Joval, Rapid7, ThreatGuard, IBM, MicroSoft, Tenable (Nessus)
  • Open Source: OpenSCAP (mostly Linux)

Secure Configuration: What

From [CIS Secure Configuration]

Establish, implement, and actively manage (track, report on, correct) the security configuration of mobile devices, laptops, servers, and workstations using a rigorous configuration management and change control process in order to prevent attackers from exploiting vulnerable services and settings.

Secure Configuration: Why 1

From [CIS Secure Configuration]

As delivered by manufacturers and resellers, the default configurations for operating systems and applications are normally geared towards ease-of-deployment and ease-of-use – not security. Basic controls, open services and ports, default accounts or passwords, older (vulnerable) protocols, preinstallation of unneeded software; all can be exploitable in their default state.

Secure Configuration: Why 2

From CIS Secure Configuration

Developing configuration settings with good security properties is a complex task beyond the ability of individual users, requiring analysis of potentially hundreds or thousands of options in order to make good choices. Even if a strong initial configuration is developed and installed, it must be continually managed to avoid security “decay” as software is updated or patched, new security vulnerabilities are reported, and configurations are “tweaked” to allow the installation of new software or support new operational requirements. If not, attackers will find opportunities to exploit both network accessible services and client software.

Secure Configuration: How

From CIS Secure Configuration

  • Maintain documented, standard security configuration standards for all authorized operating systems and software.

  • Utilize a Security Content Automation Protocol (SCAP) compliant configuration monitoring system to verify all security configuration elements, catalog approved exceptions, and alert when unauthorized changes occur.

Secure Configurations: Where

National Checklist Program

The National Checklist Program (NCP), defined by the NIST SP 800-70, is the U.S. government repository of publicly available security checklists (or benchmarks) that provide detailed low level guidance on setting the security configuration of operating systems and applications.

Secure Configurations: Formats

  • Prose – instructions on how to configure securely
  • The Extensible Configuration Checklist Description Format (XCCDF) is an XML format specifying security checklists, benchmarks and configuration documentation. XCCDF development is being pursued by NIST, the NSA, The MITRE Corporation, and the US Department of Homeland Security. XCCDF is intended to serve as a replacement for the security hardening and analysis documentation written in prose. XCCDF is used by the Security Content Automation Protocol.

Checklist Example FireFox

Firefox rules in STIG (Security Technical Implementation Guide) viewer, XCCDF format

Firefox STIG rules

Checklist Example NGINX

Portion of a CIS Benchmark for the NGINX webserver (132 pages total)

NGINX checklist

Audit Logs: What

From CIS Audi Logs

Collect, manage, and analyze audit logs of events that could help detect, understand, or recover from an attack.

Audit Logs: Why 1

From CIS Audi Logs

Deficiencies in security logging and analysis allow attackers to hide their location, malicious software, and activities on victim machines. Even if the victims know that their systems have been compromised, without protected and complete logging records they are blind to the details of the attack and to subsequent actions taken by the attackers. Without solid audit logs, an attack may go unnoticed indefinitely and the particular damages done may be irreversible.

Audit Logs: Why 2

From CIS Audi Logs

Sometimes logging records are the only evidence of a successful attack. Many organizations keep audit records for compliance purposes, but attackers rely on the fact that such organizations rarely look at the audit logs, and they do not know that their systems have been compromised. Because of poor or nonexistent log analysis processes, attackers sometimes control victim machines for months or years without anyone in the target organization knowing, even though the evidence of the attack has been recorded in unexamined log files.

Web Site Log Example 1

Weekly visit counts success and failures

Grotto Visits 12/2020-4/2021

Web Site Log Example 2

From where? “Good” document requests only

United States     51927  Germany           10452  France             7296 
Netherlands        5191  Singapore          5172  India              3747
China              3744  Russia             1992  Canada             1928
Luxembourg          741  Pakistan            671  United Kingdom      495
Taiwan              462  Turkey              442  Czechia             381
Ireland             311  Israel              301  Finland             271
South Korea         231  Ukraine             229  Vietnam             224
Japan               211  Romania             204  Hong Kong           203
Spain               199  Norway              188  Poland              182
Thailand            170  Sweden              138  Philippines         129
Iran                128  Italy               118  Belgium             113
Australia           108  Brazil               98  Bangladesh           96
Malaysia             95  Greece               92  Egypt                88
Indonesia            86

Web Site Log Example 3

Raw log examination

Raw web log
// reveal.js plugins