Help Irongeek.com pay for bandwidth and research equipment:
NQSFW Free CISSP Study Guide (Hacking Illustrated Series InfoSec Tutorial
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
Domain 1: Access Control
NQSFW CISSP Study Guide
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
Quite Safe For Work (NQSFW)
has access to what?
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
triad of core security goals:
Confidentiality = Can only those that need to see it, or we want to see 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
Encrypt that files so those without the key can’t see it. Network share
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
Subject: the one doing the act
Object: The on acted upon
Rolls can be reverse, or different, depending on context:
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
legitimate users needs the contents of an encrypted file, but no one has the
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
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
Logs can be questioned
Related AAA concepts:
Least privilege – Do you really
need to know that info?
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
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.
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
Risk: The chance of a feared security threat will be exploited by a given
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? :)
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
you allowed to log in anytime, or only certain times of the day?
the admin account only login to certain stations?
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
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
user comes on board, what rights do they need?
They change job functions, do they need new rights? Do the still need the old
Remove what is not needed
Over time folks may end up getting more and more authorizations. Watch out for
Models: More on these in later videos
Read Up (simple security rule)
Write Down (*-property rule)
subject has both read and write, can only do it at their level (not up or down)
(Strong star property rule)
Brewer and Nash (Chinese Wall Model)
Labels and Clearances
Subjects have clearances, Objects have labels (or classifications)
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:
Secret > Secret > Confidential > Unclassified
Could also have Sensitive compartmented information (SCI) based on need to know
the USA, this could be compartments like:
COMINT (SI), GAMMA (G), HCS, TALENT KEYHOLE (TK)
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.
they match, the subject is authenticated.
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)
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
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
Access Control Type & Categories
Administrative (AKA: Directive)
Administrative (AKA: Directive)
Generally what to do
to do it
Software or Hardware
Operating System Settings
Guys with guns (guards)
Lock & Doors
Automated sentry guns
Keep it from happening
Firewall is a prime example
Access Control Lists
we know when something happens?
CCTV (Closed Circuit Television)
Intrusion Detection Systems
Logs (If monitored)
Fixes problems by correcting them
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
Makes up for the failing of the other controls.
Supplements and existing control
Un-patchable web app?
Crappy programmers you can’t fire?
Application Firewall could help
Multiple type examples
Technical, Preventative, Compensating?
Physical, Preventative, Detective, Deterrent
Technical, Detective, Corrective
Physical, Preventative, Detective (if you see the blood trails)
Administrative, Deterrent, Compensating
Something you know
Something you have
Something you are
Someplace you are
Something you know
long as people can’t read your mind
Complexity rules make people either forget (helpdesk costs) or write them down
Hard to manage
Generated by a token or the like, falls more into “Something you have”
Easy to remember, hard to crack
Easy to guess?
Online attack, or offline via Hashes?
Throw ever word/phrase in a list at the problem
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
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
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
Eyes (Iris or Retina)
Fingers prints (Thumbs common)
Issues with Biometrics
Price (biggest consideration probably)
Speed of enrollment and use
gooey parts have to touch the device?
False reject rate (FRR) (AKA Type 1 Error)
often a valid user is rejected, one that should have been accepted and allowed
Causes usability issues
False accept rate (FAR) (AKA Type 2 Error)
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)
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
glove, get love
Some germ concerns
Laser/light used to scan the pattern of capillaries going to the retina of the
Intrusive in that you have to press your eye to a cup
Disease spreading issue
Health privacy issues
Pregnancy can cause FRRs errors
Compares to stored image of the colored part of the eye (Iris)
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
Shape and size of the hand
Small amount of data needed (9 bytes or so)
Someplace you are
Physical access to where the system
Seen location based on IP, but may not count
AKA: Strong Authentication
(2 or more)
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
be hard to implement on all systems
Federated identity management (FIdM)
SSO, but used for multiple organizations
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
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)
this is done with old school symmetric key crypto (shared secrets), no public
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
(Key Distribution Center) The part that does the authentication of principals
(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
Kerberos: The Entities
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 (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
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 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
Kerberos: Basic Steps
Getting a Ticket-Granting-Ticket (TGT)
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.
the user is valid, the AS sends two messages back to the Client:
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.
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
access a service, a client must now get a Ticket.
client sends two (three?) messages to the TGS:
message with the TGT and the ID of the service being requested.
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
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:
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.
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:
Client-To-Server ticket encrypted with the service's secret key that was
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”.
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
message encrypted with the Client/Server Session Key that contains the timestamp
found in the “Client/Server Authenticator”, incremented by one.
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)
server will service the client’s requests if all check are passed.
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
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?
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
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
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
Less skilled, used canned exploits
Could be malicious
Could be someone being a dumb ass
Bots and Botnets
Internet background radiation
Terminology is fucked, ask what exactly the test will be doing. Not sure what
ISC2 considers the exact meaning:
More “holistic”? Could include Security audits/Pen-tests?