Security engineering is the discipline of building secure systems.
Its lessons are not just applicable to computer security. In fact, in this repo, I aim to document a process for securing anything, whether it's a medieval castle, an art museum, or a computer network.
This repo is not done. It is actively being worked on, however.
- What is security engineering?
- High level process
- Follow best practices
- Security policies
- Security models
- Understand your adversaries
- Improve defenses
- Find vulnerabilities
- Popular mechanisms
- Assurance
- Learn about how real world systems are secured
- Books
- In the future
Security engineering isn't about adding a bunch of controls to something.
It's about coming up with security properties you'd like a system to have, choosing mechanisms that enforce these properties, and assuring yourself that your security properties hold.
- "What is security engineering?" (from Anderson's book) - my notes
- What's the problem? (from Saydjari's book) - my notes
- Computer security in the real world
Here's the process I like for securing things:
- We follow as many known best practices as we can
- We write down our security policies, or high level security goals
- We develop a security model, or a spec we follow to satisfy our policies
- We reduce attack surface, follow security design principles, brainstorm ideas for and implement additonal security controls, and more -- to improve our security
- We test our design by assessing our controls, assessing protocols, looking for side channels, and more
- We write assurance cases to prove we satisfy our security policy.
Before anything else, I'd Google for the best practices for securing whatever you're trying to secure and implement all of them.
If you're in a corporate environment, set up SSO and 2FA. If you're securing a physical facility, see if there's a well-regarded physical security standard you can comply with.
Doing this will make you significantly more secure than the majority of people, who don't do this.
Policies are the high level properties we want our system to have. Policies are what we want to happen.
If we're designing a prison, one of our policies might be:
No prisoner may escape the prison.
We can then turn our policy into a more detailed model. A model is a set of rules, a specification, we can follow to achieve our policy.
Each individual in the prison facility must have a ID that identifies him/her as a "prisoner" or "not a prisoner"
A prisoner may have the written consent of the warden to leave.
A non-prisoner may leave at any time.
- Computer Security: Art and Science covers this topic very well
- Flask security architecture
Luckily, in information security, our policies often revolve around confidentiality, integrity, and availability and so there are popular existing security models for each of these policies.
For confidentiality, for example, you can choose between:
- multilevel security, for which Bell-Padula can be used
- multilateral security, for which compartmentation, BMA, Chinese wall can be used (according to Anderson's book)
There's no such thing as a system being secure, only being secure against a particular adversary.
This is why it's important to understand who your adversaries are, as well as the motivation behind and capabilities of each adversary.
Consider non-human threats, too. If you're asked to secure a painting in a museum, a fire may technically not be a security issue -- but it's something to guard against, regardless.
Here are some useful techniques I've found for improving the security of a system.
Also see if you any of the mechanisms in popular mechanisms would help.
See tptacek's HN comment on this:
For instance: you can set up fail2ban, sure. But what's it doing for you? If you have password SSH authentication enabled anywhere, you're already playing to lose, and logging and reactive blocking isn't really going to help you. Don't scan your logs for this problem; scan your configurations and make sure the brute-force attack simply can't work.
The same goes for most of the stuff shrink-wrap tools look for in web logs. OSSEC isn't bad, but the things you're going to light up on with OSSEC out of the box all mean something went so wrong that you got owned up.
Same with URL regexes. You can set up log detection for people hitting your admin interfaces. But then you have to ask: why is your admin interface available on routable IPs to begin with?
- OWASP Attack Surface Analysis Cheat Sheet
- See the papers in this folder
When evaluating a design, it's useful to see how much of the system must be trusted in order for a security goal to be achieved. The smaller this trusted computing base is, the better.
Also, once you identify the TCB for an existing system, you know that you only need to secure your TCB. You don't need to worry about securing components outside your TCB.
You want to make your TCB as small, simple, unbypassable, tamper-resistant, and verifiable as you can, as I write about here.
- OS Security Concepts (from CS 161 from UC Berkeley)
- Design patterns for building secure systems - my notes
- TSAFE: Building a Trusted Computing Base forAir Traffic Control Software
- Ten page intro to trusted computing
When designing a system, a great way to mitigate the impact of a successful attack is to break the system down into components based upon their privilege level.
Then, ask what's the least amount of privilege each component needs -- and then enforce the allowed privileges with a sandbox (if applicable).
Say one of our SRE SSH's into a production EC2 instance as root to check the instance's memory and CPU usage.
Instead, we can assign the SRE a non-root account. Even better, we can whitelist the commands this account can run.
Even better, we can even remove SSH access entirely and set up Prometheus for monitoring.
- Lecture 4: Privilege Separation (6.858 from MIT) - my notes
- OKWS paper
- SSH daemon (from Niels Provos)
- Security architecture of the Chromium browser
- Make least privilege a right (not a privilege)
The way I see it, every defense falls into one of these categories:
- Prevent: consists of deter, stop
- Detect
- Respond: consists of delay, contain, investigate, remediate
Take any attack. Then, for each of the seven categories, brainstorm defenses that fall into that category.
By mapping out an adversary's kill chain, we can then identify controls to counteract each step in the kill chain. Check out MITRE ATT&CK.
The techniques below help you find vulnerabilities in a proposed design for you to fix.
After building an attack tree, you can query it easily: "list all the attack paths costing less than $100k". (Remember: we don't seek absolute security, but rather security against a certain set of adversaries.)
Also, remember the weakest link principle. You can query your attack tree for the lowest cost attack path and ensure that the cost isn't too low.
Every security control must be on, impossible to bypass, tamperproof, and functionally correct. It must also fail closed.
If this is not the case, then an attacker can violate a system's security properties by subverting its controls.
- Can the attacker turn off the control?
- Can the attacker get you to turn off the control?
- Can the attacker get around your control?
- Does the control depend on something that the attacker can disable?
- Are there any cases where the control doesn't work?
Example: a burglar confronting a home security system which calls the police if someone crosses the lawn at night
- Can the attacker turn off the control? Probably not
- Can the attacker get you to turn off the control? Yes, he could set off the alarm everyday until you turn it off
- Can the attacker get around your control? Yes, he could land on the roof
- Does the control depend on something that the attacker can disable? Yes, the attacker can cut the electric wire or the fiber cable used to call the police
- Are there any cases where the control doesn't work? The attacker can buy the control and learn the alarm doesn't go off if he tip toes.
I like using a statement/conclusion format to draw out my assumptions.
Statement: I have a home security system which calls the police if someone crosses the lawn.
Conclusion: I won't get robbed.
Assumptions:
- For every single attacker that tries to cross my lawn, my home security system calls the police. (If the answer to any of the questions above is yes, this assumption is false.)
- The police will arrive before any attacker is able to steal anything and stop the theft. (What if the attacker impersonates the homeowner and tells the police that my home security system is faulty; don't come if it calls you? What if the attacker makes hundreds of 911 calls while he is robbing the house? What if the police is blocked by a "car accident"? What if the attacker has arranged for a getaway helicopter?)
Saydjari writes an entire chapter on this:
Protocols aren't a tool for securing something. But all communication between two components of a system is done through a protocol, so it's worth learning how to analyze protocols for vulnerabilities.
- "Protocols" (from Anderson's book)
- A logic of authentication
- Programming Satan's computer
- Prudent engineering practice for cryptographic protocols
- Robustness principles for public key protocols
- Using Encryption for Authentication in Large Networks of Computers
- Three systems for cryptographic protocol analysis
We want our security controls to fail closed, not open. There's two ways to analyze the ways something might fail: failure tree analysis (FTA), which is top down, and failure modes and effects analysis (FMEA), which is bottom up.
Even if something isn't vulnerable to attacks (on confidentiality, integrity, or availability), it may leak information which makes these attacks easier.
For example, take a login program that checks if the username is valid, returns a generic "login failed" error if it's not, then checks if the password is valid, and returns the same generic error if it's not.
At a first glance, determining if a particular username is valid may seem impossible. After all, the error message is the same regardless of whether the username is invalid or the username is valid and the password is invalid.
However, an attacker could examine the time it takes to get the error to determine if the username is valid or not.
In order to secure something, you need to know what tools are available to you. Here are some that which can be used in many different contexts.
A lot of tools are context-specific, however. Before I start trying to secure a building, for example, I'd spend the time to learn about all the tools I can use: walls, sensors, natural barriers, guards, CCTV cameras, etc
- "Cryptography Engineering" book
- "Cryptography" (from Ross Anderson's book)
- "Advanced Cryptographic Engineering" (from Ross Anderson's book)
To learn about later: secure enclaves
The idea here is to make it economically, not technically, infeasible for the attacker to attack us. He can still attack us, but his expected effort will exceed his expected gain.
Say a scammer manages to scam one of every hundred people out of $5. If we can add a $0.10 fee to every call, then he'd need to pay $10 in fees to earn $5.
Another example would be not storing credit card data ourselves, and instead outsourcing this to a payment processor, so the reward of attacking us is less.
If the attacker isn't motivated by money, this doesn't work.
Deterrence has three parts: certainty, severity, and swiftness. In other words, to deter attackers most effectively, someone should be able to catch most or all of them -- and do this quickly -- and then sufficiently punish them once you do catch them.
This someone could be the government, via laws and regulations against whatever you're trying to defend against. The government may not catch everyone, but these laws and regulations will deter most people. Copyright protection, anti-shoplifting, and anti-trespassing laws all are examples of this.
The government is not the only third party who can deter attacks on you. Organizations, like NATO, can as well.
Alternatively, you can try to retaliate against attacks yourself. Take, for example, media companies that sue people that pirate their movies.
- "Physical tamper resistance" (from Anderson's book)
- Cryptographic processors – a survey
- Smartcard Handbook
- Tamper Resistance - a Cautionary Note
- Low Cost Attacks on Tamper Resistant Devices
- Design Principles for Tamper-Resistant Smartcard Processors
If we can't prevent tampering, we can try to make it obvious when something has been tampered with.
This is one reason why bags of chips or gallons of milk, for example, are sealed.
The three ways to authenticate someone is based on you are (biometrics), what you know (password), what you have (Yubikey, phone).
Without authorization, anyone who authenticates to our system would have full access to everything. We'd like to make it more difficult than that for attackers, and likely don't trust all insiders that much, either.
Think about the intel classification hierarchy: some documents are top secret, others are secret, others are confidential, and so on. This is a multi-level scheme.
- "Multilevel Security" (from Anderson's book)
- An analysis of the systemic security weaknesses of the U.S. Navy fleet broadcasting system, 1967-1974, as exploited by CWO John Walker
Even if an analyst has a secret clearance, you may not want him to be able to any access documents from other departments. This is a multi-lateral scheme.
- "Boundaries" (from Anderson's book)
- Security in clinical information systems
- Implementing access control to protect the confidentiality of patient information in clinical information systems in the acute hospital
- Privacy in clinical information systems in secondary care
Sandboxes let us take a untrusted component of a system and apply a security policy to it.
Say you're a king, ruling over some citizens and criminals. You may want to sandbox the criminals to prevent them from harming your citizens, by, say, putting them in jail. While they can still harm each other, you've contained the damage.
- On Safes, Sandboxes, and Spies (CS 161 at UC Berkeley)
- A Theory and Tools for Applying Sandboxes Effectively
- Chrome Sandbox Design Doc
- Chrome Sandbox Design FAQ
- Sandboxing Applications
- A Security Study of Chrome’s Process-based Sandboxing
- SELinux, Seccomp, Sysdig Falco, and you: A technical discussion
- gvisor
- sandy
Obscurity, not its own, does not count as security. However, it can be added on top of real security measures, to make attacks on you require more time and a higher skill level.
- Obscurity is a valid security layer - see the HN comments as well
The goal of security engineering is to build a system that satisfies certain security properties -- not just to add a lot of controls. Assurance is how we prove that our system satisfies the properties we want it to.
- Public Pentesting Reports
- CH26 Managing the Development of Secure Systems (from Anderson's book)
- CH27 Assurance & Sustainability (from Anderson's book)
- The Orange Book
- See the papers in this folder
The chapters in Anderson's book fall into two categories, in my view: mechanisms for securing systems and examples of how some real world systems are secured.
We've already learned about the first category; this section is about the second category.
- Introduction to physical security
- "Physical protection" (from Anderson's book)
- Design and evaluation of physical protection systems
- Physical security: 150 things you should know
- The complete guide to physical security
- Physical security systems handbook
- "Nuclear command and control" (from Anderson's book)
- Nuclear Security Recommendations on Physical Protection of Nuclear Material and Nuclear Facilities
- Nuclear Security Series
- "Monitoring and metering" (from Anderson's book)
- Electronic Postage Systems: Technology, Security, Economics
- Reliability of Electronic Payment Systems
- On the Security of Digital Tachographs
- "Banking and bookkeeping" (from Anderson's book)
- The Bank Employee's Fraud and Security Handbook: Everything You Need to Know to Detect and Prevent Loss
- Security and Privacy Analysis of Automatic Meter Reading Systems
- How Coinbase Builds Secure Infrastructure To Store Bitcoin In The Cloud
- "Copyright and DRM" (from Anderson's book)
- The Protection of Computer Software: Its Technology and Application
- European Scrambling Systems, Circuits, Tactics and Techniques
- BeyondCorp I: A new approach to enterprise security
- BeyondCorp II: Design to deployment at Google
- BeyondCorp III: The access proxy
- Migrating to BeyondCorp
- BeyondCorp: The user experience
- Zero Trust Networks: Building Secure Systems in Untrusted Networks
- Jail Design Guide (National Institute of Corrections)
- Prison Architecture
- A Practical Guide to Understanding and Evaluating Prison Systems
- Technical Guidance for Prison Planning
- Handbook on Dynamic Security and Prison Intelligence
- Correctional Facility Design and Detailing
- Museum Property Security and Fire Protection (from Interior Dept. Museum Property Handbook)
- Suggested Practices For Museum Security
- Museum Collections Security
- Museum Security and Protection
- Casino Security and Gaming Surveillance
- Casino Surveillance and Security: 150 Things You Should Know
- Casino Surveillance: the Eye That Never Blinks
- 150 things You Should Know About Security - see the casino chapter
- Computer Security: Art and Science (by Bishop) - I'd read this first; it teaches security engineering in the right order: policies and models, then mechanisms, then assurance.
- Security Engineering (by Ross Anderson)
- Engineering Trustworthy Systems (by Sami Saydjari)
- "Security in Computing" (by Pfleeger) - I liked the chapter on trusted operating systems in particular.
- Building Secure and Reliable Systems
- Time Based Security - my notes. Wasn't information dense.
- "Engineering Information Security" (by Jacobs) - Mostly contains general security content, not content on security engineering. Only the systems engineering chapter felt new.
- "The Craft of System Security" (by Smith and Marchesini) - Also mostly general security content
- "Cyber Security Engineering" (by Woody and Mead) - Wasn't very information dense or well organized
- NIST 800-16 Vol I: System Security Engineering
- NIST 800-16 Vol II: Developing Cyber Resilient Systems
- Learning from the enemy: the GUNMAN project (NSA)
- The spy in Moscow station
- The Art of Systems Engineering
- Engineering Systems: Meeting Human Needs in a Complex Technological World
- The Engineering Design of Systems
- Applied Space Systems Engineering
- Systems Engineering Book of Knowledge (SeBOK) - here's the pdf
- Write up case studies on how I'd use my process to secure different things
- Create practical, step by step checklists for doing each of the parts of my process