CS 3710: Intro to Cybersecurity (slides): Identity and access management

# Identity and access management
## CS 3710

===

## Access control

---

## Why care about access control?

A major theme of the first half of the semester was _**access**_, and different
means that attackers use to obtain it.

</div>
<div class="fragment fade-in-then-out" data-fragment-index=0>

Abstractly, successful attackers typically start by obtaining some level of
access to a system. They maintain and leverage that access to obtain higher
privileges and eventually achieve their objective.

</div>

---

## Why care about access control?

<figure>
  <img src="../../img/malware/offensive_operational_lifecycle.webp">
  <figcaption>
  
*The "ideal" offensive operational lifecycle*

*(Source: Matt Monte, "Network Attacks and Exploitation: A Framework")*

</figcaption>
</figure>

</div>
  <div class="fragment fade-in-then-out" data-fragment-index=0>

*Source: Federal Trade Commission*

</figcaption>
</figure>

</div>
  <div class="fragment fade-in" data-fragment-index=1>

</figcaption>
</figure>

</div>
</div>

---

## Access control

_**Access control**_ is about restricting the permissions that people and
programs have to various resources. It can work at many different levels:

- _**OS-level:**_ access to files, regions of memory and disk, devices, etc.

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

- _**Network-level:**_ access to a particular network, hosts you can reach over
  a given network, traffic you can send in or out of the network.

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=1>

- _**Physical:**_ access to buildings and vehicles

</div>

---

## The principle of least privilege

One of our goals will be to implement the _**principle of least privilege**_.

PoLP states that users should have _enough_ privileges to perform the actions
they need to, and _nothing more_.

*Source:
[Cloudflare](https://www.cloudflare.com/learning/access-management/principle-of-least-privilege/)*

</figcaption>
</figure>

===

## Authentication vs Authorization

---

## Authentication vs Authorization

*Authentication* and *authorization* play two interrelated roles in access
control:

_**Authentication**_ defines *who you are*

</div>
<div class="fragment fade-in" data-fragment-index=1>

_**Authorization**_ defines *what you can do*

</div>

---

## Authentication

There are many different ways to verify a person's identity:

_**Something they know:**_ e.g. a password, a security question

</figcaption>
</figure>

</div>
<div class="fragment fade-in-then-out" data-fragment-index=0>

_**Something they have:**_ a phone, an email address, a hardware security token,
etc.

</figcaption>
</figure>

</div>
  <div class="col">

</figcaption>
</figure>

</div>
</div>

</div>
<div class="fragment" data-fragment-index=1>

_**Something they are:**_ biometrics, such as a fingerprint or facial
recognition

</figcaption>
</figure>

</div>

---

## Authorization

Authorization defines what permissions a user or application has.

</figcaption>
</figure>

---

## Authorization

Linux's discretionary access control (DAC) model determines what actions users
can take with files and directories. You can run `ls -l` or `getfacl` to see
file/directory permissions:

</figcaption>
</figure>

---

## Authorization

_**Owner permissions:**_ `rwx` (can read, write, and execute the file)

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

_**Group permissions:**_ `r-x` (can read and execute the file)

</div>
<div class="fragment fade-in" data-fragment-index=1>

_**Permissions for other users:**_ cannot read, write, or execute the file

</div>

</figcaption>
</figure>

---

## A brief aside on empathy

One thing to keep in mind is that as a defender, you're rarely (if ever) the
star of the show.

</div>
<div class="fragment" data-fragment-index=0>

The defender's job to _**support**_ the people and systems that they're
defending, and _**enable**_ them to do their job in a way that's safe and
secure.

</div>

---

## A brief aside on empathy

</figcaption>
</figure>

</div>
  <div class="col">

</figcaption>
</figure>

</div>
</div>

</figcaption>
</figure>

</div>
</div>

notes:

https://twitter.com/TinkerSec/status/1535215021260685315
https://twitter.com/ki_bydesign/status/1534597290828398592
https://twitter.com/QuinnyPig/status/1532724283079700480

---

## Recovery and support

To that end, it's important that you balance access control decisions carefully
against whatever obstacles they might create in allowing users to perform their
jobs.

</div>

_**Example:**_ as an exercise, think about what you might do if you lost access
to the following. How severe would the ramifications be? How would you recover
access to them (and what would happen if you couldn't)?

- your student ID;

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=1>

- your email address;

</div>
<div class="fragment" data-fragment-index=2>

- your driver's license/passport.

</div>
</div>

---

## Recovery and support

It's important to give users a path to recovering lost accounts and privileges
so that account loss is not catastrophic.

This may also involve user training and additional time spent providing support.

*Source: [UVA Academic ID Card
Office](https://idoffice.virginia.edu/academic-id-card-replacement)*

</figcaption>
</figure>

</div>
  <div class="col">

*Source: [Google Account
Help](https://support.google.com/accounts/answer/7682439?hl=en)*

</figcaption>
</figure>

</div>
</div>

===

## Access control models

---

## Discretionary access control (DAC)

_**Discretionary access control**_ is a fairly simple access control model.
Resources are owned by a user and/or group, who is in charge of deciding what
permissions other users have for that resource.

*Examples:* file permissions on UNIX-based OSes and on Windows

</figcaption>
</figure>

---

## DAC: Access control lists (ACLs)

_**Access control lists**_ are commonly discussed alongside DAC. An ACL is just
a list of different users and groups, and what permissions they have over a
resource.

_**Example:**_ in Linux, you can use the `getfacl` command to get the ACL for a
particular file or directory:

```bash
$ getfacl /etc/shadow
# file: etc/shadow
# owner: root
# group: shadow
user::rw-
group::r--
other::---
```

---

## Mandatory access control (MAC)

Under _**mandatory access control (MAC)**_, access to a resource is controlled
by a policy administrator.

Users are not allowed to change permissions or escalate beyond their current
privilege set, except as explicitly defined by the MAC policy.

*Example:* Linux security modules (e.g. SELinux, AppArmor)

</figcaption>
</figure>

</div>

</figcaption>
</figure>

</div>

---

## Role-based access control (RBAC)

In a _**role-based access control (RBAC)**_ system, users are authorized to
perform different *roles* corresponding to their job requirements.

For instance, a database administrator might be granted a role that allows them
to insert and read data from a table, but not to execute other applications.

_**Examples:**_ SELinux, Kubernetes RBAC

</figcaption>
</figure>

notes:

RBAC in Kubernetes:
- https://kubernetes.io/docs/concepts/security/rbac-good-practices/

---

## Role-based access control (RBAC)

_**Kubernetes**_ is a *container orchestrator* that is extremely popular in
deploying *microservice-oriented architecture*.

K8S uses RBAC to control access to many different kinds of resources.

</div>
  <div class="col">

*Source: [Kubernetes
Blog](https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/)*

</figcaption>
</figure>

</div>
</div>

---

## Attribute-based access control (ABAC)

_**Attributed-based access control (ABAC):**_ controls based on what
_**attributes**_ the subject and resource have.

Access controls are formulated on the basis of what combination of attributes
the subject (who's requesting permission) and the resource have.

*Source: [Amazon Web
Services](https://aws.amazon.com/identity/attribute-based-access-control/)*

</figcaption>
</figure>