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:
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)2 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 1st 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 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.
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)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?
Crackers
More correct term from (ISC)2?
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?
Printable version of this article