Identity & Access Management Flashcards
Identity & Access Management - Overview
IAM focuses on harmonizing the provisioning of users and managing their access across multiple systems with different native access control systems
Identity Management: controls the life cycle for all accounts in a system
- identity proofing
- account provisioning/deprovisioning
Access Management: controls the assignment of rights/privileges to those accounts
Authentication
- type 1, type 2, type 3
- Kerberos and Single Sign On
- Single Sign On: federated services
Authorization
- access control models
- enforcing access control
- access control management
Auditing/Accountability:
Data Emanation: attack on access control
Identity Management
Identity Proofing
- precedes the creation of a user account; not the same as authentication
- requires the prospective employee to prove their identity to the employer - SS cards, I9s before they are given a user account to identify with on the network
Account Provisioning
- traditionally, cloud vendors used non-standard provisioning APIs
- Enterprises to develop and maintain proprietary connectors to integrate with multiple SaaS providers
Easier provisioning:
SPML: service provisioning markup language:
- older, seldom implemented due to the inflexibility and lack of vendor support
SCIM (System for Cross-Domain Identity Management or Simple Cloud Identity Management):
- defines a schema and an API for managing identities
- SCIM is an open standard for automating the exchange of user identity information between identity domains, or IT systems
Authentication - Overview
Proving a claimed identity
- Type 1: something you know e.g. pin, password, code
- Type 2: something you have e.g. key, digital cert, passport
- Type 3: something you are e.g. biometrics
The strongest authentication is multi-factor - a combination of the above
Mutual Authentication
Type 1: Something You Know
Passwords, Passphrases, Cognitive Password
Traditional Best Practices - NIST disagrees (length over complexity)
- 8 characters
- change on a regular basis
- upper and lower
- include numbers and non-numbers
- enforce password history
- consider brute force and dictionary attacks
- ease of cracking cognitive passwords
- graphic image
- enable clipping levels and respond accordingly
Type 2: Something You Have
Type 2: Something You Have
Token Devices: password that is only used once and then is no longer valid. It reduces vulnerability associated with sniffing passwords. They are simple to implement, but can be costly. Users can lose or damage it. Two types = synchronous or asynchronous
smart card
- memory card
- hardware key
- cryptographic key
- certificate
- cookies
Token Devices
Password that is only used once and then is no longer valid. It reduces vulnerability associated with sniffing passwords. They are simple to implement, but can be costly. Users can lose or damage it.
Two types = synchronous or asynchronous
Synchronous Devices: RSA devices
- rely on synchronizing with authentication server. Frequently time based, but could be event based
- if damaged it must be re-synchronized
- authentication server knows what password to expect based on time or event
- asynchronous/challenge response
- user logs in
- authentication returns a challenge to the user
- user types challenge string into pocket device and presses enter
- token device returns a reply
- only that specific users token device could responds with the expected reply
Memory Cards
Magnetic stripe on the back
Attackers can put down shims into the credit card machine to siphon off the account numbers stored on a magnetic strip
Memory Cards hold information, does NOT process information
A memory card holds authentication info. Usually you’ll want to pair this with a PIN…WHY?
A credit card or ATM card is a type of memory card . So is a key/swipe card.
Smart Card
Chip & Pin system - better than the magnetic strips
- chip has a RF ID
- EMV Chip = Euro Pay, MasterCard & Visa
- Chip goes into the chip reader, and transmit a encrypted version of the account number
- if the chip card is not working, you go back to the magnetic strip
Some attackers create shims to zap the chip to make it not work.
Signing the card on the back adds MFA to the chip and pen
Type 3: Something You Are/Do
Biometrics:
- Physiological (Static): Should not significantly change over time. Bound to a user’s physiological traits
- fingerprint, hand geometry, iris, retina, etc.
Biometric Concerns
- User Acceptance: many users feels it’s too intrusive e.g. retina scans can reveal health information
- Time for enrollment and verification can make users resistant
- Cost/benefit analysis
- No way to revoke biometrics
Behavior-based (Dynamic): Based on behavioral traits
- voice, gait, signature, keyboard cadence, etc.
- even though these can be modified temporarily, they are very difficult to modify for any significant length of time
Crossover Error Rate
Type 1 Error: False Rejection - a legitimate user is barred from access. Is caused when a system identifies too much information. This causes excessive overhead.
Type 2 Error: False Acceptance - an imposter is allowed access. This is a security threat and comes when a system doesn’t evaluate enough information.
As FRR goes down, FAR does up and vice versa
There will always be a point where they meet - The level at which the two meet is called CER (Crossover Error Rate). The lower the number, the more accurate the system!!!
Iris Scans are the most accurate. Retina scans examines the vascular pattern behind the eyes, healthcare information can be found from that information - new can of worms when it comes to protecting that data
Which of the following is of LEAST concern when choosing biometrics?
a. technology type
b. accuracy
c. cost
d. user acceptance
Technology Type! technology type is driven by business needs which would need to be evaluated in the other answers
Single Sign On
Single Sign-On: allows a user to provide credentials to an authentication server and receive access to interconnected and disparate systems
Tools: kerberos/LDAP, Sesame, Krypto-Knight
Pros:
- ease of use for end users
- centralized control
- ease of administration
Cons:
- single point of failure
- standards necessary
- keys to the kingdom
Kerberos
Main Goal: User needs to authenticate themselves without sending passwords across the network needs to prove they know the password without sending it across the wire.
A network authentication protocol designed form MITs project Athena. Kerberos tries to ensure authentication security in an insecure environment
Used in Windows2000+ and some Unix
Allows for single sign-on
Never transfers passwords across the Network - this is called zero knowledge proof > the network is going to prove that the password was entered in correctly, but doesn’t need to transmit it
Uses symmetric encryption to verify identifications > this explains back-and-forth
Avoids replay attacks > very time sensitive so no one is resubmitting information
Essential Components:
- Authentication Server (AS): allows authentication of the user and issues a THT
- TGS: After receiving the TGT from the user, the TGS issues a ticket for a particular user to access a particular service
- Key Distribution Center (KDC): a system which runs the TGS (Ticket Granting Service) and the AS (Authentication Service)
- Kerberos Software is integrated into most OSs. MS Windows 2000 and up support Kerberos
Kerberos Concerns
- Computers must have clocks synchronized within 5 minutes of each other
- Tickets are stored on the workstation. If the workstation is compromised, your identity can be forged
- If your KDC is hacked, security is lost
- A single KDC is a single point of failure and performance bottleneck
- Still vulnerable to password guessing attacks
The Kerberos Carnival
REVIEW KELLY’S EXPLANATION + DIAGRAM
Federated Trusts
Provisioning > Authentication > Authorization
Provisioning Identities: Ensure org has a streamlined process for provisioning accounts
Authentication: span domains (SAML, OpenConnect)
Authorization: Authorize users and applications to do on my behalf (OAuth)
Federated Trusts: Provisioning
Our environment has an SSO directory like Active Directory where user accounts are stored
Create a connection between HR system and SSO directory
SPML: Service Provisioning Markup Language
SCIM: System Cross-Domain Identity Management
- two languages designed to allow two directories to communicate (HR software pulled into LDAP/AD environment)
- a user gets hired in HR would auto-provision the AD account
SaaS Usage: these apps don’t want to know the password, bc then they would have to store it. they just want assurance that the identity accessing it has paid for a license.
- AD > SCIM/SPML > IDP in a DMZ > SaaS
- IDP will hold all the accounts and creds and a federated trust would be created with the SaaS
SAML (Security Association Markup Language) and OpenID Connect are other languages to use
SAML
SAML (Security Association Markup Language): login to company portal > IDP dashboard will store all apps with federated trusts which means IDP login will allow login to all the apps in there that has determined that the login to the IDP was legit (digitally signed) SAML token is verified by the app
- instead of sharing creds across the internet, SAML tokens are being shared that don’t hold any sensitive information
OpenID Connect: alternative to SAML, but same concept
OAuth 2.0
OAuth (Open Standard for Authorization)
- has a different intention; not designed for SSO
- delegates certain rights to applications
- e.g. Spotify asks you to update your Facebook with your playlist
- in simplest terms, it means giving your access to someone you trust, so that they can perform the job on your behalf, e.g. updating status across Facebook, Twitter, IG, etc. with a single click
- could go to sites manually, but easier to delegate access to an app that connect the above platforms
Authorization
Rights, permissions associated with the account
Authorization Principals:
- by default you have NO access to anything (implicit deny) - unless a subject is explicitly given access to an object, they they are implicitly denied access
- principle of least privilege (action) e.g. do not allow end users to be giving admin access on their own computers
- need to know (data access) e.g. sales team only gets access to the sales folder
- content-based vs. context-based: giving access to the resource based on what is in the resource. E.g. I’ll give you access to the closet, depending what’s in the closet. Context - idc what you access, I just want to limit when you access it. Block John after 5 pm
Access Control Models
A framework that dictates how subjects access objects
- access control technologies and security mechanisms enforce the rules
- supported by Access Control technologies
- business goals and culture of the organization will prescribe which model is used
- Every OS has a security kernel/reference monitor that enforces the access control model
Models from TCSEC
- DAC: Discretionary Access Control
- MAC: Mandatory Access Control
Other Models
- RBAC: Role Based Access Control
- ABAC: Attribute Based Access Control
- RuBAC: Rule Based Access Control
DAC Model
Discretionary Access Control
- security of an object is at the owner’s discretion
- access is granted through an ACL (access control list)
- commonly implemented in commercial products and all clients are
- these environments are set up for ease of use and sharing; not designed for top security
MAC Model
MAC is used where classification and confidentiality are of the utmost importance e.g. military
- usually you will have to buy a specific MAC system (higher trust system) as DAC systems don’ t do MAC e.g. SELinux, Trusted Solaris (Now called Solaris with Trusted Extensions)
- All objects in a MAC system have a security label, and security labels can be defined by the organization
- they also have categories to support “need to know” at a certain level
- categories can be defined by the organization
- users can’t change their label, or the folder’s label - it’s up to the OS system
RBAC
Rule Based Access Control
- alternative to authorizing based on identity
- RBAC is a good solution to mitigate privilege creep and provides the strongest constraint on user access
- RBAC is well-suited for environments with high turnover rates
Attribute Based Access Control
Permissions or privilege granted based on attributes of the subject (end user or system account)
Attributes can be:
- Location
- Role
- Tenure
- Any other attribute of the subject or object
