Home

Awesome

How to Secure Anything

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.

Please contribute! Create a pull request or just create a issue for content you'd like to add: I'll add it for you!

Table of contents

What is security engineering?

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.

High level process

Here's the process I like for securing things:

Follow known best practices

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.

I'd study how people have defended what you're defending now in the past. Also, I'd talk to the people who are the very best at defending what I'm defending now, and learn what they do that most people don't do.

Doing this will make you significantly more secure than the majority of people, who don't do this.

Understand your adversaries

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.

Also, study the history of attacks. If I was designing a prison, I'd learn about all the past prison breakouts that I could.

Security policies

Policies are the high level properties we want our system to have. Policies are what we want to happen.

Let's say we're designing a prison.

I'd start with a strong policy:

No prisoner may escape the prison.

Of course, time, money, and manpower are all limited. The goal isn't to eliminate risk entirely, but bring it down to an acceptable level.

As I go through the next couple steps and learn what controls I need and how costly they'll be, I might refine my security policy to something like this:

No more than 10 out of 10,000 (0.1%) prisoners may escape our prison in any given time period.

Looking at benchmarks may help us come up with this number.

Any system has additional requirements in addition to its security requirements. These two sets of requirements may conflict, so you may need to relax your security requirements.

Going back to the example above, our policy is that only a tiny percentage of prisoners may leave the prison without permission. But what if there's a fire?

If you've achieved this low escape rate by building a fully autonomous fortress with no fire detection or human override, the results may be suboptimal.

Security models

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. Our policy is our "what", the model is our "how".

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.

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:

See also this Wikipedia article and this one on computer models.

Improve defenses

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.

Minimize attack surface

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?

Minimize and verify your trusted computing base (TCB)

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.

Separate privileges

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.

Minimize privileges

Secure by default

Secure by design

Prevent/detect/respond framework

The way I see it, every defense falls into one of these categories:

Take any attack. Then, for each of the seven categories, brainstorm defenses that fall into that category.

Kill chains

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.

Security design principles

I would go down this list and see if there's any principles which you can apply to your system.

Sources

Find vulnerabilities

The techniques below help you find vulnerabilities in a proposed design for you to fix.

Developing an attacker mindset

Theories of security derive from theories of insecurity. - Unknown

If you're a great attacker you can be "logically" a great defender. However, a great defender cannot be a great attacker, nor would I say they could be a "great" defender. - Caleb Sima, VP of Security at Databricks

Any person can invent a security system so clever that she or he can't think of how to break it - Schneier's Law

More important than the attacks in subsequent sections is being able to think creatively, like an attacker. I do believe this skill is essential if you want in order to assess the security of your designs effectively.

This section describes some techniques for developing this skill that I've gathered.

Think in graphs

Read this post by John Lambert first. It's about how attackers think in graphs, while defenders think in lists, so attackers win.

I've copied the list of links below from John's post above.

Attack trees

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.

On, un-bypassable, tamperproof, functionally correct, fail closed

If a security control does not have the qualities above, then an attacker can violate a system's security properties by subverting its controls.

Example: a burglar

Take a burglar confronting a home security system which calls the police if someone crosses the lawn at night

Assumptions analysis

I like using a statement/conclusion format to draw out my assumptions about my controls.

Statement: I have a home security system which calls the police if someone crosses the lawn.

Conclusion: I won't get robbed.

Assumptions:

Saydjari writes an entire chapter on this:

Failure 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.

Fault tree analysis

FMEA

Protocol analysis

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.

Side channel analysis

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.

Assurance

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.

Popular mechanisms

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

Economics

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 they'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.

Laws and regulations (deterrence by the government)

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.

Retaliation (deterrence by you or third parties)

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.

Tamper resistance

Tamper detection

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.

Access control

Authentication

The three ways to authenticate someone are:

While not a standalone factor, you can consider the environment, too, such as where the user is or what time it is.

Biometrics

Authorization

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.

Multilevel

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.

Multilateral

Even if an analyst has a secret clearance, you may not want him to be able to access any documents from other departments. This is a multi-lateral scheme.

Two-man rule

The idea is simple: to authorize certain actions, more than one person must consent. This helps protect against malicious insiders.

Inference control

While an individual, anonymized database may not be enough to de-anonymize people, a combination of anonymized databases may make this possible. Inference control aims to prevent this.

I haven't seen this concept outside of computer security, yet.

Sandboxing

Privilege separation is dividing a system into different components, based on what permission level each component should have.

Least privilege is then making the permission level for each component as small as possible.

The way you enforce this minimal permission level is via a sandbox.

I haven't seen this concept outside of computer security, yet.

Logging & auditing

To me, logging is the act of collecting event data, and auditing is looking for malicious activity in those events. The terms are used interchangeably, however.

Logging is useful for deterrence (insiders especially are less likely to do bad things if they're being recorded), detection, and investigation. It can provide non-repudiation, or the inability of an attacker to deny their malicious activity.

It's practiced in many fields from information security (think SIEMs) to healthcare (tracking who accesses someone's medical records).

Air-gapping

Attacking

Obscurity

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.

Learn about how real world systems are secured

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.

Physical facilities

Defending

Attacking

Nuclear command and control

Monitoring and metering

Banking and bookkeeping

Defending

Attacking

Distributed systems

Copyright and DRM

Web browsers

Web applications

Android

BeyondCorp & zero trust

Most companies need to be able to answer the question, "is this client one of ours," when protecting sensitive resources.

Most companies will instead answer the question, "is the client on our network," and pretend that it was the same question. The fact that it clearly is not has some very obvious security implications and attack vectors that we've been living with for decades.

Beyondcorp tries to more directly answer the original question about device identity rather than subbing in the network question in its place.

The fact that this approach is novel says a lot about the maturity of our industry.

-- tyler_larson, a Hacker News comment, 01/22/2018

Architecture

Summary

Google's BeyondCorp removes the concept of firewalls and VPNs altogether.

Instead, every request to access internal services must be authenticated, authorized, and encrypted, and that's all -- regardless from what network the request originates from.

Authentication

For a request to be authenticated, it must be from:

Key components

End to end flow

Quoting from the paper linked above:

  1. The request is directed to the access proxy. The laptop provides its device certificate.
  2. The access proxy does not recognize the user and redirects to the SSO system.
  3. The engineer provides his or her primary and second-factor authentication credentials, is authenticated by the SSO system, is issued a token, and is redirected back to the access proxy.
  4. The access proxy now has the device certificate, which identifies the device, and the SSO token, which identifies the user.
  5. The Access Control Engine performs the specific authorization check configured for codereview.corp.google.com. This authorization check is made on every request: a. The user is confirmed to be in the engineering group.
    b. The user is confirmed to possess a sufficient trust level.
    c. The device is confirmed to be a managed device in good standing.
    d. The device is confirmed to possess a sufficient trust level.
    e. If all these checks pass, the request is passed to an appropriate back end to be serviced.
    f. If any of the above checks fails, the request is denied.

Prereqs for compromising a service

For an attacker to gain access to a service under BeyondCorp, they'd need to:

  1. choose an employee who can access this service
  2. obtain that employee's SSO credentials
  3. obtain an employee's hardware security key
  4. obtain an employee's (any employee's?) managed device which can access this service
  5. obtain the password to this managed device
  6. bypass any location based access control
  7. do all of this before either the user's or device's access is cut off (as every request is checked)

Before/after

Before: the attacker has to execute one digital attack (gain VPN access) to gain access to services.

Even if VPN requires 2FA, but it's not done with a hardware security key, the attacker can phish the employee into giving up his 2FA code or accepting the Duo push.

After: the attacker has to execute two digital attacks (obtain SSO password, obtain device password) and two physical attacks, which might be done at once (device, hardware security key).

Learning lesson: shift digital attacks to physical attacks wherever possible (and safe). Google does this using hardware security keys and only letting managed laptops access services.

Further reading

Apple

Cloud providers

Computer networks

Operating systems

Time protection

sel4

SELinux

AppArmor

Chromebook

Prisons

Voting

Museums

Defending

Attacking

Counterintelligence

Casinos

Defending

Attacking

Military Architecture

Also known as: fortifications

Defending

Attacking

Both

Books

Recommended

"Recommended" is subjective...YMMV!

More

Haven't read yet

Papers

This list is from Science of Cybersecurity.

Content wanted

If you know of any good books, talks, papers, or other resources on the topics below, please submit a pull request, or even easier, just create an issue and I'll add the resources to the repo for you.

In the future