A Logo

Feel free to include my content in your page via my
RSS feed

Help Irongeek.com pay for
bandwidth and research equipment:

Subscribestar or Patreon

Search Irongeek.com:

Irongeek Button
Social-engineer-training Button

Help Irongeek.com pay for bandwidth and research equipment:


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:

Domain 1:
Access Control

Adrian Crenshaw



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)2 way may be needed

Not Quite Safe For Work (NQSFW)


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.


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






CIA Examples

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

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

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


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!




AAA Spelled out a bit better

Not always mentioned, but this is generally the 1st step

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

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

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


Related AAA concepts:

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


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.


Many site, but with more communication than Decentralized

Identity and Access Provisioning Lifecycle


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


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


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


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:

Access control schemes & protocols









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


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



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:


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


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)



Six Types:







Administrative (AKA: Directive)


Generally what to do


How to do it


User Training


Software or Hardware



Operating System Settings



Guys with guns (guards)

Barbwire Fences



Lock & Doors

Automated sentry guns


Keep it from happening

Firewall is a prime example

Background checks


Access Control Lists


Do we know when something happens?


CCTV (Closed Circuit Television)

Intrusion Detection Systems

Logs (If monitored)


Fixes problems by correcting them

Anti-virus quarantine

Guards kicking someone out


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.


Make people (or things) not want to happen

Policies if they have teeth

Warning signs

Low fences


Makes up for the failing of the other controls.

Supplements and existing control

Increased monitoring/supervision


Un-patchable web app?

Crappy programmers you can’t fire?

Web Application Firewall could help

Multiple type examples


Technical, Preventative, Compensating?


Physical, Preventative, Detective, Deterrent


Technical, Detective, Corrective

Barb wire

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


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


Static passwords

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”


Easy to remember, hard to crack

Security questions

Easy to guess?

Password/Passphrase Attacks

Online attack, or offline via Hashes?


Throw ever word/phrase in a list at the problem

Brute Force

Try every possible combination of characters in a set



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


Account lockout


Physical/Software Quality


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




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


From the Greek bios=life & metric=measurement

Authenticate using something about the body

All kinds


Eyes (Iris or Retina)

Fingers prints (Thumbs common)

Hands geometry



Typing style


Issues with Biometrics

Price (biggest consideration probably)


Speed of enrollment and use




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.


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


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


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

Easier for admins and developers too


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)


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 2nd 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.


For more info on Kerberos v5 see RFC 4120


Mutual authentication of client/server

Timestamps mitigate replay attacks

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


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


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


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



From one (ISC)2 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?


More correct term from (ISC)2?

Confusion with software crackers and white people from the south


Political motivation

Script Kiddies

Less skilled, used canned exploits



Could be malicious

Could be someone being a dumb ass

Bots and Botnets

Internet background radiation


Spear phishing


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?


Port scanning

Vulnerability scanning

Application scanning


Black-box, white-box, gray-box

(Kerckhoffs's principle)




Twitter: @Irongeek_ADC

15 most recent posts on Irongeek.com:

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

Copyright 2020, IronGeek
Louisville / Kentuckiana Information Security Enthusiast