NQSFW Free CISSP Study Guide (Hacking Illustrated Series InfoSec Tutorial Videos) NQSFW Free CISSP Study Guide

Not sure if I will continue these videos, its a lot of work and many of the subjects are kind of boring. Figured as I studied, I might as well take notes and regurgitate them in video form.
Domain 1: Access Control

Text notes:

NQSFW CISSP Study Guide
Domain 1:
Access Control

Adrian Crenshaw

Style?

I don�t have a CISSP as I record this

These are sort of my study notes

Teach as I learn

Takes a noob to teach a noob

Even if not a noob, understanding it the (ISC)² way may be needed

Not Quite Safe For Work (NQSFW)

PG13/R

Access Control

Who has access to what?

How is this controlled (duh!)

This domain covers technologies and practices to control levels and types of access a subject has to an object.

More than just logical things like file permissions, but also physical access.

CIA of CYA

The triad of core security goals:

Confidentiality = Can only those that need to see it, or we want to see it, access it?

Integrity = Can it be changed by the wrong parties?

Availability = Is it available for use by those that are supposed to use it?

Acronym sometimes different to avoid confusion with another TLA

DAD

Disclosure

Alteration

Destruction

CIA Examples

Confidentiality
Encrypt that files so those without the key can�t see it. Network share permissions.

Integrity
What�s this file changed? What does the HASH say? Is the data correct or has someone changed it?

Availability
Can customers access the website? (Nope, someone is DDoSing it.) Did a backup restore fail?

Subject/Object

In terminology:

Subject: the one doing the act

Object: The on acted upon

Rolls can be reverse, or different, depending on context:

If I try to run an EXE, I am the Subject (the doer) and the EXE is the Object (doee)

When the EXE is running as a process, it may be the Subject when it opens/edits a data file, and the data file is the Object.

These principals are sometimes at odds

A legitimate users needs the contents of an encrypted file, but no one has the key! CA

Often things take a back seat to Availability:
Hey, let�s just share these files to the Everyone group!

Wide open file share for everybody!

AAA, as oppose to AA

Security Prayer:

Root, grant the Subject the security to Authenticate as who they claim to be, The Authorization to access only the Objects they must, And the Accountability so I know who to blame when something fucks up!

Authentication

Authorization

Accountability

AAA Spelled out a bit better

(Identification)
Not always mentioned, but this is generally the 1^st step

Authentication
Preceded my identification, how do the users prove who they are?

Authorization
How are thing checked to make sure they can only get to what they need?

Accountability
How do we know who did what, when where and to whom?

Related AAA concepts:
Non-repudiation

Non-repudiation
How do you prove someone did something if they might later claim they did not?

Hand written signature is a classic example, but kid of silly

Digital signature

Notary

Logs can be questioned

Related AAA concepts:
Least privilege � Do you really
need to know that info?

Least privilege

Best practice of only letting Subject/Users have rights to do what they have to do for their jobs, and to access only what the need to access!

Example: I am the admin for the engineering department, do I really need admin/root access to the computers in accounting?

Political issues? Does your boss really need that access?

Defense in depth
Extra lines of defense

One layer may fail, but others can back it up. No single point of failure.

Firewall from the Maginot Line Firewall company

Best firewall on the market, no �bad� packets get through!

Home Wireless Router from Belgium-sys

Someone sets up shop near the facility with a high gain antenna, connects to the internal network anyway.

More Terms

Control or Measure: Something set up to mitigate potential losses

Exposure: The possibilities to compromise, as in threat surface

Vulnerability: A weakness that can be used to compromise Confidentiality, Integrity or Availability

Threat: Possible danger of a vulnerability being exploited intentionally or accidentally

Risk: The chance of a feared security threat will be exploited by a given vulnerability

Possible layers that would have helped?

Security awareness training for users not to hook up unauthorized access point

NAC: Network Access Control

Network Inventory/Change Tools

Disabled network ports

Machines hardened on the inside of the network

Copper walls? :)

Access Control
This gets fuzzy

Discretionary Access Control (DAC)

Pretty much the way standard *nix and Windows systems work. A Subject (user) that owns data can assign others rights to access it.

Mandatory Access Control (MAC)

System enforces the permissions, users can�t decide to share data they �own� with others unless labels permit it. This is seen to by the Reference Monitor. Works more like the Government security clearance system.

Non-Discretionary Access Control

Example might be RBAC (Role Based Access Control) where the user�s/subject�s role (CEO, tech, janitor) determines access level.

Content/Context Depended Access Controls

Are you allowed to log in anytime, or only certain times of the day?

Can the admin account only login to certain stations?

You can connect to the database, but can you see all records?

Centralized vs. Decentralized Access Control

Centralized Access Control

Think things like domain accounts

Easier to manage in some ways

Centralization of the Authentication, Authorization & Accountability

Decentralized Access Control

Put the control in the hands of the people near the gear.

Can�t always rely on the central point.

Distributed

Many site, but with more communication than Decentralized

Identity and Access Provisioning Lifecycle

Provisioning

New user comes on board, what rights do they need?

Review

They change job functions, do they need new rights? Do the still need the old ones?

Revocation

Remove what is not needed

Over time folks may end up getting more and more authorizations. Watch out for �Permissions Creep�!

Models: More on these in later videos

Clark-Wilson (Integrity)

Bell-LaPadula (Confidentiality)

No Read Up (simple security rule)

No Write Down (*-property rule)

If subject has both read and write, can only do it at their level (not up or down) (Strong star property rule)

BIBA (Integrity)

No Write Up

No Read Down

Lattice

Brewer and Nash (Chinese Wall Model)

State Machine

Labels and Clearances

Subjects have clearances, Objects have labels (or classifications)

If a Subject has clearances equal or better than an Objects labels, they can access it (assuming a confidentiality model and other caveats)

Could be a scheme like:

Top Secret > Secret > Confidential > Unclassified

Could also have Sensitive compartmented information (SCI) based on need to know

In the USA, this could be compartments like:
COMINT (SI), GAMMA (G), HCS, TALENT KEYHOLE (TK)

Access control schemes & protocols

PAP

CHAP

RADIUS

Diameter

TACACS/TACACS+

PAP

Password Authentication Protocol (PAP)

Defined in RFC 1334

Sends passwords in the clear (bad), allowing it to be sniffed

Later versions encrypted the password, but you could still use replay attacks

CHAP

Challenge Handshake Authentication Protocol

Defined by RFC 1994

Protects against reply attacks

Authenticator tells Authentication server that it wants to connect.

Authentication server sends a challenge.

Authenticator takes the challenge given by the server, instead of sending its password (secret) in the clear like PAP, it does a mathematical transformation on it and the challenge, and sends the results back to the server.

Server also has the secret, does the same transformation and compares if to what the client sent.

If they match, the subject is authenticated.

Can be used for mutual authentication if challenges are issued both ways (server > client and client > server).

Nonce size maters J

Chap

RADIUS

Remote Authentication Dial-In User Service

Defined in RFCs 2865 & 2866

Uses port 1812/UDP for authentication and 1813/UDP for accounting (used to use 1645/UDP 1646/UDP, but not official assigned)

Messages carried in Attribute-Value Pairs (AVPs)

Has the following codes:

Diameter

Successor to RADIUS, meant to overcome some if its shortcoming

Currently a draft RFC 3588

Instead of RADIUS� 8bit Attribute-Value Pairs (AVPs), it uses Diameter uses 32 bits (256 vs 4294967296 possible values)

Diameter uses one server, RADIUS uses many

Diameter uses port 3868/TCP

TACACS/TACACS+

Terminal Access Controller Access Control System (TACACS)

Requires users to send ID and static password for authentication

TACACS uses ports 49/UDP and TCP, TACACS+ just 49/TCP

TACACS+ allows for two factor authentication

While RADIUS only encrypts the password on the wire, TACACS+ encrypts all data beneath the TACACS+ header

TACACS+ not backwards compatible with TACACS

Procedures and Practices

Least privilege & Need-To-Know
(examples given earlier)

Separation of duties

Avoid conflicts of interest and allows for checks & balances. If I am the one that handles the money draw, and am also the person who counts it, could I not easily steal?

Rotation of duties

Even if one person handles the money, and another counts it, what if they are buddies and start to collude?

Rules-based Access Control

If/then type controls that define what can be accessed.

Firewalls or File permissions are common examples

Access Control Lists (ACLs) a list that control what Subjects can do things to what Objects

Access Control Type & Categories

Three Categories:

Administrative (AKA: Directive)

Technical

Physical

Six Types:

Preventive

Detective

Corrective

Recovery

Deterrent

Compensating

Administrative (AKA: Directive)

Policy

Generally what to do

Procedures

How to do it

Regulations

User Training

Technical

Software or Hardware

Firewalls

Anti-malware

Operating System Settings

Encryption

Physical

Guys with guns (guards)

Barbwire Fences

Gates

Mantraps

Lock & Doors

Automated sentry guns

Preventive

Keep it from happening

Firewall is a prime example

Background checks

Locks

Access Control Lists

Detective

Do we know when something happens?

Alarms

CCTV (Closed Circuit Television)

Intrusion Detection Systems

Logs (If monitored)

Corrective

Fixes problems by correcting them

Anti-virus quarantine

Guards kicking someone out

Recovery

Recover from the problem

Restore from backup

Re-Imaging a system

Nuke it and rebuild it from orbit, it�s the only way to be sure.

Deterrent

Make people (or things) not want to happen

Policies if they have teeth

Warning signs

Low fences

Compensating

Makes up for the failing of the other controls.

Supplements and existing control

Increased monitoring/supervision

Example:

Un-patchable web app?

Crappy programmers you can�t fire?

Web Application Firewall could help

Multiple type examples

Firewall

Technical, Preventative, Compensating?

Guard

Physical, Preventative, Detective, Deterrent

Anti-malware

Technical, Detective, Corrective

Barb wire

Physical, Preventative, Detective (if you see the blood trails)

Policy

Administrative, Deterrent, Compensating

Authentication Methods

Four types:

Something you know

Something you have

Something you are

Someplace you are

Something you know

As long as people can�t read your mind

Passwords

Static passwords

Crackable

Complexity rules make people either forget (helpdesk costs) or write them down

One Time Password

Hard to manage

Dynamic Passwords

Generated by a token or the like, falls more into �Something you have�

Passphrases

Easy to remember, hard to crack

Security questions

Easy to guess?

Password/Passphrase Attacks

Online attack, or offline via Hashes?

Dictionary

Throw ever word/phrase in a list at the problem

Brute Force

Try every possible combination of characters in a set

Slooooow

Hybrid

Take a word list, but mutilate to words in certain ways:
Tack on numbers, change Os to 0s, Ls to 1s, etc.

Counters to password attacks

Online

Account lockout

Offline

Physical/Software Quality

Salts

Tacked on to make stored hashes harder to crack

Most modern *nix systems salt their password hashes, Window does not

Most modern *nix systems use salts

Windows does not

Something you have

A physical thing

Keys

Cards

Tokens

Synchronous dynamic token

Time Based: Every so many minutes the devices shows a different password

Counter Based: Password changes for each button press/logon

Asynchronous dynamic token

Challenge response where the services gives you a number and you type it into a card (or something) to get a pin

Something you are

Biometrics

From the Greek bios=life & metric=measurement

Authenticate using something about the body

All kinds

Physiological

Eyes (Iris or Retina)

Fingers prints (Thumbs common)

Hands geometry

http://www.analbiometrics.com/

Behavioral

Typing style

Gate

Issues with Biometrics

Price (biggest consideration probably)

Accuracy

Speed of enrollment and use

Privacy

Comfort

Safety/Disease

Do gooey parts have to touch the device?

Biometric Accuracy

False reject rate (FRR) (AKA Type 1 Error)

How often a valid user is rejected, one that should have been accepted and allowed in

Causes usability issues

False accept rate (FAR) (AKA Type 2 Error)

How often a invalid user is accepted, one that should have NOT have been accepted and allowed in

Generally considered worse than a Type 1 error
(Think 2>1 when it comes to bad)

Crossover error rate (CER)

CER is the point where FRR=FAR. As a device is set to be more sensitive, FRR goes up and FAR goes down. Setting the device to be less sensitive cause FAR to go up and FRR to go down.

Fingerprints

Uses minutiae of the fingerprint for authentication

Cuts could cause FRR

No glove, get love

Some germ concerns

Retina Scan

Laser/light used to scan the pattern of capillaries going to the retina of the eye

Intrusive in that you have to press your eye to a cup

Disease spreading issue

Health privacy issues

Pregnancy can cause FRRs errors

Iris Scan

Compares to stored image of the colored part of the eye (Iris)

Can be done from a distance

Scans could be passive and at a distance

Because of distance, does not have the germ issues of a Retina scan

Hand Geometry

Shape and size of the hand

Fast

Small amount of data needed (9 bytes or so)

Someplace you are

GPS aware application

Physical access to where the system

Seen location based on IP, but may not count

Multifactor Authentication

AKA: Strong Authentication
(2 or more)

2 Factor

More than one of the:

What you know

What you have

What you are

Where you are

Commonly password + physical item

Biometric + password

Single Sign On (SSO)

SSO: Use one set of credentials to log into everything

Benefits

Easier for users since they have to remember one username/password set

Easier for admins and developers too

Drawbacks

Single point of attack, so �keys to the kingdom� problems

Better lock your screen J

May be hard to implement on all systems

Federated identity management (FIdM)

SSO, but used for multiple organizations

May use OpenID or Security Association Markup Language (SAML)

Kerberos

Developed as part of project Athena at MIT

Kerberos is a type of authentication system that uses a trusted third party and a system of Tickets to grant access to resources

The core goals of Kerberos are to avoid sending the password across the network to avoid sniffing, mitigate replay attacks, and do mutual authentication between the client and the service server (to avoid evil twin attacks and the like)

All this is done with old school symmetric key crypto (shared secrets), no public key crypto

Stateless, so if KDC goes down, you can keep on trucking

There are multiple versions of Kerberos, and differences in vendor implementation, but what follows are the basics

Kerberos: Terms to remember

Principal or Client: This could be a user or a service requesting other services

KDC (Key Distribution Center) The part that does the authentication of principals

TGS (Ticket Granting Service): The name explains most of it, maybe running on the same box as the KDC but not necessarily

Realm: The Kerberos network things belong to

Ticket: Clients/Principal use this to prove who they are later to make more requests

TGT�Ticket granting ticket.

Kerberos: The Entities

To make things simpler later, here are our players:

Client (aka Principal): This is the requester of access and services. It has its own symmetric key for authentication/encryption that is also know by the Key Distribution Center.

Key Distribution Center (KDC): This part also contains the secret keys for all users/entities. The KDC is possibly one unit, but is made up of two logical parts:

Authentication Server (AS): This handless checking to see if the user is valid, and used the right password (in the form of the user�s secret key). It also sets up session keys to the Ticket Granting Server, and gives out the Ticket-Granting-Ticket (TGT).

Ticket Granting Server (TGS): Then presented with a proper Ticket-Granting-Ticket (TGT), the TGS should hand out Tickets for Services if the user has the right permissions.

Service Servers: These receive the service Tickets, and of course provide services.

Kerberos: Basic Steps
Getting a Ticket-Granting-Ticket (TGT)

The Client makes a plain-text request for a service to the AS. No password is in the message, just Client identifying information so the AS can find the right key in its own database of credentials.

If the user is valid, the AS sends two messages back to the Client:

The Client/TGS session key for later encrypted communications, encrypted using the client�s shared key (the AS already know this key).

The-Ticket-Granting-Ticket(TGT) , with details like the user, their network connection, tickets valid period, Client/TGS Session Key, etc. This 2^nd message is encrypted using the secret key of the TGS.

The first message (a) can be decrypted by the client since it is encrypted with a key they know. This session key will be used for later communications. The second message (the TGT) cannot be decrypted by the client since it is encrypted with the secret key of the TGS. This TGT will be presented the TGS later. Notice that at no point did a password need to be sent across the network as both the KDC and the client had pre-shared them.

Kerberos: Basic Steps
Getting a service Ticket

To access a service, a client must now get a Ticket.

The client sends two (three?) messages to the TGS:

A message with the TGT and the ID of the service being requested.

A message encrypted with the Client/TGS session key, with a timestamp and client ID. This is known as an Authenticator, but to be specific let�s call it the �Client/TGS Authenticator�.

Then the TGS receives these messages, it decrypts the TGT with the TGS� key. It now has the Client/TGS Session Key for communication back to the Client. The TGS now sends back two messages to the client:

The Client-To-Server ticket encrypted with the service's secret key, with details like the user, their network connection, ticket�s valid period, Client/TGS Session Key, etc.

The Client/Server session key encrypted with the Client/TGS Session Key.

Kerberos: Basic Steps
Getting the Service

Once the client has the Ticket from the messages sent in step 2 above, it can request a service. The client sends the following two messages to the server the service is running on:

The Client-To-Server ticket encrypted with the service's secret key that was obtained earlier.

A message encrypted with the Client/Server session key, with a timestamp and client ID. This is known as an Authenticator, but to be specific let�s call it the �Client/Server Authenticator�.

The service server can decrypt the ticket using its secret key, and gets the Client/Server Session Key. Using the Client/Server Session Key it can decrypt the �Client/Server Authenticator�, and checks it. The service server can then send back:

A message encrypted with the Client/Server Session Key that contains the timestamp found in the �Client/Server Authenticator�, incremented by one.

The client decrypts the message using the Client/Server Session Key and makes sure the timestamp is valid and incremented. If it�s valid the client will trust the server and start using the servicez. (Mutual authentication)

The server will service the client�s requests if all check are passed.

Kerberos

For more info on Kerberos v5 see RFC 4120

Strengths:

Mutual authentication of client/server

Timestamps mitigate replay attacks

Stateless, KDC or TGS can go down and authentication can still work for a time

Weaknesses:

Keys stored on the KDC make it a tempting target

KDC or TGS are a single point of failure (though currently valid tickets will continue to function)

Replay attacks possible for the life time of the authenticator

Offline brute force of the key?

May be possible to get a principals key off of a client

Open SESAME?

SESAME (Secure European System for Applications in a Multivendor Environment)

Single Sign On

Kind of a successor to Kerberos

Uses Public Key Crypto, so no plain-text client private keys need stored on the authentication server

Uses Privilege Attribute Certificates (PACs) instead of Tickets

KryptoKnight

Developed by IBM

Another ticket based system like SESAME and Kerberos

Uses nonces/challenge response so time sync is not required

Logs: Just do it

Collect logs

Read logs

Retain logs

Love it

Security Information and Event Management
(SIEM)

Attackers

Hackers

From one (ISC)²book: �A person who attempts to break into computers that he or she is not authorized to use.�

Ethical/White hat, Black hat, Grey hat, Chartreuse hat?

Crackers

More correct term from (ISC)²?

Confusion with software crackers and white people from the south

Hacktivists

Political motivation

Script Kiddies

Less skilled, used canned exploits

Outsiders

Insiders

Could be malicious

Could be someone being a dumb ass

Bots and Botnets

Internet background radiation

Phishers

Spear phishing

Testing

Terminology is fucked, ask what exactly the test will be doing. Not sure what ISC2 considers the exact meaning:

Security Assessments

More �holistic�? Could include Security audits/Pen-tests?

Security Audits

More of a checklist?

Scanning

Port scanning

Vulnerability scanning

Application scanning

Pen-testing

Black-box, white-box, gray-box

(Kerckhoffs's principle)

Questions?

42 Twitter: @Irongeek_ADC

If you would like to republish one of the articles from this site on your webpage or print journal please contact IronGeek.

NQSFW CISSP Study Guide Domain 1: Access Control