Curated by Dash (da5ch0)
This repository contains a curated selection of the DoD Rainbow Series — the foundational computer security standards and guidelines published by the U.S. Department of Defense Computer Security Center and the National Computer Security Center between 1985 and 1995.
These documents defined the vocabulary, the evaluation criteria, and the conceptual architecture that the entire field of information security was built on. They have been formally superseded by the Common Criteria (ISO/IEC 15408), but superseded is not the same as irrelevant. The Common Criteria tells you what to evaluate. The Rainbow Series tells you why those evaluation categories exist, what threat models produced them, and what the people who built the first trusted systems were actually thinking about. If you've ever wondered why your security architecture looks the way it does — why access control is structured the way it is, why audit exists in the form it exists, why formal verification is considered important — the answers are in these documents.
They are also, candidly, difficult to find in clean digital form. They're scattered across aging government servers, broken links, and PDF graveyards. This repo puts them in one place, because RTFM presumes you can find the FM.
This is an act of love for the discipline. Read them.
DoD 5200.28-STD — Trusted Computer System Evaluation Criteria (TCSEC) December 1985
The genesis document. Everything else in this series is a commentary on, extension of, or companion to the Orange Book. It defines the evaluation classes — D (minimal protection) through A1 (verified design) — that formalized what "trusted" means in a computing context. It introduced the concept of the Trusted Computing Base (TCB), mandatory access control (MAC), discretionary access control (DAC), and the security kernel architecture. The Bell-LaPadula confidentiality model lives here. If you read one document in this entire series, it's this one.
When to read it: First. Before anything else in the series. Before your first security architecture review. Before you use the phrase "trusted system" in a sentence. If you are in cybersecurity and you have not read the Orange Book, you have not read the primary source of your own field.
What it teaches you: What "trust" actually means in a formal security context, and why the answer is more uncomfortable than you expect.
CSC-STD-002-85 — DoD Password Management Guideline April 1985
The first formal attempt to codify password policy at an institutional level. Covers password generation, distribution, storage, and lifecycle management. Much of it reads as quaint now — password length recommendations have evolved, and the field has moved toward multi-factor authentication — but the reasoning is foundational. This document is where the discipline first formally wrestled with the tension between password strength (entropy) and password usability (human memory limitations). That tension has not been resolved. It has merely been renamed.
When to read it: Early in your career, when you're first responsible for authentication policy. Read it not for the specific recommendations (which are dated) but for the analytical framework: how to think about the tradeoffs in credential management.
What it teaches you: The password problem is an information-theoretic problem, not a policy problem, and no policy can overcome the entropy constraints that the Green Book identifies.
NCSC-TG-006 — A Guide to Understanding Configuration Management in Trusted Systems March 1988
Configuration management as a security discipline, not an operational convenience. This document makes the case that if you cannot prove your system is in a known, authorized state, you cannot make any security claims about it at all. Every modern concept in configuration drift detection, infrastructure-as-code validation, and baseline compliance traces back to the principles articulated here.
When to read it: When you transition from "building secure things" to "maintaining secure things over time." Configuration management is where the theoretical rubber meets the operational road — where your beautiful security architecture meets the reality that someone will change something at 3 AM and not document it.
What it teaches you: Security is not a state. It is a maintained invariant. The Amber Book is the first formal articulation of this principle.
NCSC-TG-007 — A Guide to Understanding Design Documentation in Trusted Systems October 1988
How to document the security architecture of a trusted system such that the documentation itself can be evaluated. This is not about writing good docs for developers — it is about producing evidence that a system's design meets its security claims. The connection between documentation rigor and evaluation assurance level is made explicit here: you cannot achieve a high trust rating if you cannot demonstrate, through documentation, that you understand your own design.
When to read it: When you're responsible for producing security documentation for formal evaluation, compliance audits, or certification processes. Also useful whenever you suspect that your team's security architecture exists primarily in one person's head — the Burgundy Book will convince you that this is an evaluated vulnerability, not just a bus-factor risk.
What it teaches you: If you can't document it, you can't evaluate it. If you can't evaluate it, you can't trust it. Documentation is a security control.
NCSC-TG-015 — A Guide to Understanding Identification and Authentication in Trusted Systems September 1991
The formal treatment of I&A — how a system establishes who a subject is (identification) and whether to believe them (authentication). Covers the full taxonomy: something you know, something you have, something you are. Extends into the relationship between I&A and the TCB, accountability mechanisms, and the dependency of all other access control decisions on the integrity of the I&A subsystem. Every IAM architecture you've ever worked with is a descendant of the framework described here.
When to read it: When you're designing or evaluating authentication systems. When you need to understand why identity is foundational — why a flaw in I&A undermines every other security mechanism in the stack, regardless of how well those mechanisms are implemented.
What it teaches you: Authentication is the root of the trust tree. Everything downstream inherits its assurance level — and its weaknesses.
NCSC-TG-003 — A Guide to Understanding Discretionary Access Control in Trusted Systems September 1987
The companion to the Orange Book's DAC requirements, unpacking what discretionary access control actually means in implementation. Covers access control lists, capabilities, owner-controlled permissions, and the fundamental tension in DAC: the user's discretion is simultaneously the mechanism and the vulnerability. A user empowered to set permissions is a user empowered to set them wrong. If this sounds like a certain identity involving capability and vulnerability, it should.
When to read it: When you're designing permission models, evaluating access control architectures, or trying to understand why DAC alone is insufficient for high-assurance environments. The Neon Orange Book explains what the Orange Book requires and, more importantly, why the requirement exists in the form it does.
What it teaches you: Discretion is a feature and a threat surface. The user's authority to control access is inseparable from the user's ability to compromise it.
NCSC-TG-001 — A Guide to Understanding Audit in Trusted Systems June 1988 (Version 2)
Why audit exists, what it must capture, and how it relates to accountability, intrusion detection, and after-the-fact analysis. The Tan Book makes the case that audit is not logging — audit is the mechanism by which a trusted system maintains accountability for security-relevant events. It covers audit trail protection (the audit system itself must be tamper-resistant), audit reduction (the raw data is useless without analysis tools), and the relationship between audit granularity and system performance.
When to read it: When you're building or evaluating SIEM architectures, designing logging pipelines, or arguing with management about why "we have logs" is not the same as "we have audit." The distinction matters and the Tan Book is where it was first formally drawn.
What it teaches you: Audit is not a record of what happened. Audit is the mechanism by which you can prove what happened, to an evaluator, after the fact. The difference is accountability.
NCSC-TG-010 — A Guide to Understanding Security Modeling in Trusted Systems October 1992
Formal security models — Bell-LaPadula, Biba, Clark-Wilson, and others — explained in terms of what they prove, what they assume, and where they fail. This document bridges the gap between the abstract mathematics of formal models and the practical question of what those models actually guarantee about a running system. If you've ever wondered what it means to say a system "implements Bell-LaPadula," the Teal Green Book explains the distance between the model and the implementation and why that distance matters.
When to read it: When you're working with formal security models, evaluating systems that claim to implement them, or studying for certifications that expect you to understand the model hierarchy. Also invaluable when you need to explain to someone why a formal model is not a security guarantee — it is a framework for reasoning about security guarantees.
What it teaches you: Models are tools for reasoning, not proofs of security. The map is not the territory, and the Teal Green Book is the document that teaches you to read maps without confusing them for terrain.
NCSC-TG-004 — Glossary of Computer Security Terms
The controlled vocabulary. Every field needs a shared lexicon, and this is the one the DoD established for computer security. If you've ever been in a meeting where "authentication" and "authorization" were used interchangeably, or where "trust" meant something different to everyone at the table, the Aqua Book is the cure. It defines terms with the precision necessary for formal evaluation — which is a higher standard than conversational usage.
When to read it: As a reference throughout your career. Keep it accessible. When you encounter a term whose meaning you think you know, check it against the Aqua Book's definition. You will be surprised how often the formal definition is narrower, or more specific, or more load-bearing than the colloquial one.
What it teaches you: Words matter. In security, ambiguous vocabulary is a vulnerability.
NCSC-TG-014 — Guidelines for Formal Verification Systems April 1989
Formal verification — the use of mathematical proof to demonstrate that a system's implementation conforms to its specification. This document covers what formal verification can and cannot do, what tools and methods exist for it, and what level of assurance it provides when done correctly. It is the companion to the A1 evaluation class in the Orange Book, which requires formal verification as a condition of the highest trust rating.
When to read it: When you're working on high-assurance systems, evaluating formal methods tools, or trying to understand what it actually takes to achieve A1 (or its Common Criteria equivalents). Also useful as a reality check: the Purple Book is honest about the limitations of formal verification, which is more than can be said for some modern formal methods advocates.
What it teaches you: Formal verification is the gold standard of assurance and also the most expensive. The Purple Book helps you understand when the cost is justified and when it isn't.
NCSC-TG-027 — A Guide to Understanding Information System Security Officer Responsibilities for Automated Information Systems or maybe this is the other turquoise book, i forget what all i hoard sometimes
The ISSO's mandate, formalized. This document defines the role, responsibilities, and authority of the person charged with maintaining the security posture of an automated information system. It covers the ISSO's relationship to the system owner, the certifying authority, and the user community. It is, in effect, the job description for the security function — and reading it will clarify whether your organization's security role is properly scoped or whether your "security team" is actually an audit team, a compliance team, or a help desk wearing a security badge.
When to read it: When you become an ISSO, when you hire one, or when you need to argue about the scope and authority of the security function in your organization. The Turquoise Book provides the doctrinal basis for "the security person needs the authority to say no, and the organizational position to survive saying it."
What it teaches you: Security is an organizational function, not a technical feature. The ISSO role exists because systems do not secure themselves and users do not secure them either.
NCSC-TG-028 — Assessing Controlled Access Protection
A practical guide to evaluating whether a system meets the C2 (Controlled Access Protection) level of the Orange Book's evaluation criteria. C2 is the level most commercial systems aspire to — individual accountability, audit, and DAC — and the Violet Book provides the evaluation methodology. It is, in effect, a field manual for assessors: what to test, what to examine, what to ask, and what constitutes evidence of compliance.
When to read it: When you're performing or preparing for a security evaluation at the C2 level or equivalent. When you need to understand what "controlled access" actually requires in practice, as opposed to what it sounds like in a sales brochure.
What it teaches you: The gap between "we implement access control" and "we meet C2 requirements" is larger than most vendors would like you to believe.
NCSC-TG-016 — Guidelines for Writing Trusted Facility Manuals October 1992
How to write the administrator's manual for a trusted system — the documentation that the privileged user (system administrator, security officer) needs to configure, maintain, and operate the system's security features correctly. The Yellow-Green Book recognizes that a trusted system operated incorrectly is an untrusted system with a good pedigree, and that the quality of the administrator documentation is therefore a security property of the system itself.
When to read it: When you're writing operational security documentation, building runbooks, or designing administrative interfaces. The principle that operational documentation is a security control — not a convenience — originates here.
What it teaches you: The most formally verified system in the world is insecure if its administrator doesn't know how to operate it. Operational documentation is load-bearing.
C1 Technical Report 001 — Computer Viruses: Prevention, Detection, and Treatment March 1990
The DoD's first formal treatment of computer viruses as a security threat class. Written when the Morris Worm (1988) was still a fresh memory and the concept of self-replicating malicious code was transitioning from theoretical curiosity to operational threat. Covers virus taxonomy, propagation mechanisms, detection strategies, and the relationship between virus protection and the TCB — specifically, how a system's trusted computing base can be leveraged (or undermined) by viral code.
When to read it: Early in your career, as a historical document. The specific viruses discussed are ancient, but the analytical framework — how to classify self-replicating threats, how to reason about propagation, how to think about the relationship between system integrity and malware resistance — is foundational. Modern malware analysis still uses the conceptual categories established here.
What it teaches you: The virus problem is not a signature problem. It is an integrity problem. The Tinto report understood this in 1990; much of the industry took another two decades to catch up.
If you are new to the field:
- Orange Book — The foundation. Everything references this.
- Green Book — Authentication basics and the password problem.
- Aqua Book — Learn the vocabulary before proceeding.
- Tan Book — Understand audit as a security discipline.
- Neon Orange Book — Access control in depth.
- Tinto on Viruses — The threat landscape, vintage 1990.
If you are a practicing security engineer:
- Orange Book (if you haven't already — be honest with yourself).
- Light Blue Book — I&A is the root of your trust tree; understand it formally.
- Amber Book — Configuration management as security, not ops.
- Teal Green Book — Formal models: what they prove and what they don't.
- Burgundy Book — Design documentation as evaluated evidence.
If you are in security leadership or governance:
- Turquoise Book — The ISSO role, formally defined. Scope your function correctly.
- Violet Book — What evaluation actually requires. Calibrate your expectations.
- Yellow-Green Book — Operational documentation is a security control.
- Purple Book — Formal verification: when to demand it and when the cost exceeds the value.
If you are a red teamer: Read all of them. The defensive architecture you are attacking was designed by people who read these documents. Understanding the design intent of the system you're testing gives you structural insight into where the design assumptions fail — and they always fail at the boundaries the designers couldn't see, not the ones they hardened. Know what they were trying to build, and the gaps reveal themselves.
The Rainbow Series is formally obsolete. The Common Criteria superseded the TCSEC. Modern security frameworks (NIST SP 800-53, ISO 27001, the CSF) have evolved far beyond what the Rainbow Series envisioned.
But superseded does not mean irrelevant. The Common Criteria is the child of the Orange Book. NIST's access control guidelines descend from the Neon Orange Book's DAC analysis. Every modern IAM architecture carries DNA from the Light Blue Book. The audit requirements in every compliance framework trace back to the Tan Book.
These documents are the primary sources of the discipline. They contain the original reasoning, the original threat models, the original design decisions. The modern frameworks give you the what. The Rainbow Series gives you the why.
Read the primary sources. The field has a history. Know it.
Curated and hosted by da5ch0. These documents are public domain, published by the United States Government. This repository exists because foundational knowledge should be findable, not buried. RTFM — but first, here's the FM.