S1L2 - Software Security (AAA) (AAA - Access Control, Authentication &…
S1L2 - Software Security (AAA)
AAA - Access Control, Authentication & Auditing
Group of processes with goal to provide CIA (Confidentiality, Integrity and Availability)
An auditing policy must be established to determine what resources or accesses need to be tracked.
Usually retained in LOG FILES, which may be used to TRACK PATHS AND VIOLATIONS
establishes who you are
using various methods to verify both parties to transaction
Use of Digital Certificates
Use of Diffie-HellMan key
Multi- Factor Authentication
Use of one or more type of authentication to strengthen process such as requiring card and PIN together
Additional check-points to service leads to greater security
Complexity of system increases which may cause inconvenience to users.
Hardware Software components used to GENERATE RANDOM PASSCODES to further secure authentication process
User enters password then gets random ID that can be used to log into network. Change every 5 minutes
require CA which are used to create DIGITAL CERTIFICATES used for digital SIGNATURES, MUTUAL IDENTIFICATION, and VERIFICATION
It is a Password protected and encrypted file that HOLDS an individual's IDENTIFICATION INFO, including a PUBLIC AND PRIVATE KEY.
Public key used to verify sender's digital signature
Private key allows individual to log onto third party authority who administers digital certificates
Client sends his username and password which are then compared through all record lists of username/password pairs in database.
CHAP (Challenge Hansdshake Authentication Protocol)
An AUTHENTICATION AGENT sends client program a RANDOM VALUE that is used ONCE and ID value.
Both share a PREDEFINED SECRET.
Peer CONCATENATES random value, ID and secret and calculates one way HASH using MD5.
HASH value sent to AUTHENTICATOR, which builds same string and performs hashing.
Values are compared. If match peer is authenticated.
By transmitting only Hash, the secret cannot be reverse-engineered. The ID value is increased with each CHAP dialogue to protect against replay attacks
Secure - Prevent eavesdropping, impersonation, replay
Reliable - AS built on robust hw/sw so AS does not fail
Transparent - User not aware of process taking place
KDC allows use of temporary short lived keys.
KDC does not automaticlly trust. Should prove id through third party
KDC becomes performance bottleneck
Need for Protocol
Principal wants to access service logs onto KDC through network
KDC confirms Principal in DB and AS issues TGT (contains TG key)
Principal issues TGT to TGS
TGS issues TICKET FOR SERVICE and SESSION KEY
An TIMESTAMP associated to request is created and encrypted onto the SESSION KEY. This is known as the AUTHENTICATOR
The Authenticator is then used to eastablish a session key for secure communication
connect a valid user with the service user wishes to access. In order to accomplish this, BOTH server and user must have KEYS REGISTERED with AS
KDC (Key Distribution Center)
server issuing keys during initial client setup
In order to authenticate, KDC runs an AS (Authentication Service). AS issues TGT (Ticket Granting Ticket)
temporary set of credentials that client uses as proof of identity validation
Kerberos client/user is known as PRINCIPAL
Access Model: Access Matrix (ACM)
Simplest way to represent an Access Control Policy
Rows (i) - domains/subject
Columns (j) - objects
An entry (i,j) represents set of operations a process in domain Di can invoke on the Object Oj
Capability list of domain D1 : Read F1 | Read F2
Access Control List of Object: Read D1 | Read,Write D2
Access Control Policy
precise set of rules for determining authorization to make access control decisions
RBAC (Role-Based Access Control)
Defined by job function and much more control in defining.
Allows admin to create "roles" users where each role has specific privileges.
Can be costly and prone to error (because admin has to configure ACL)
DAC (Discretionary Access Control)
Defined by the owner of an object.
DISCRETIONARY because protection of data object is set at the discretion of the owner.
A DAC mechanism allows users to grant or revoke access of an object under their control WITHOUT interaction of a system admin.
MAC (Mandatory Access Control)
Protection decisions are not decided by owner of objects.
Level of Access defined and is hard-coded in OS and cannot be easily changed
For example: Delete root files in Windows