Please enable JavaScript.
Coggle requires JavaScript to display documents.
ICT 379 MAP: ACCESS CONTROL UP. FUNDAMENTALS LEFT BRANCH CRYPTOGRAPHY DOWN…
ICT 379 MAP: ACCESS CONTROL UP. FUNDAMENTALS LEFT BRANCH CRYPTOGRAPHY DOWN LOW LEVEL PROTECTIONS RIGHT.
ACCESS
Identification and Authentication. IBAC Identity based Access Control
Password, MulitFactorial Authentication -> something you know(pin), are( biometrics), have(iphone/swipe card), do(keyboard pattern), located(GPS)
Access Controls
Basic Access operations UNIX =read write execute.WINDOWS = full,modify,read+execute, read, write, create/delete.. Bell La padula= read write append(used in logs) execute.
#
Access Control Structure: Capabilities and Access Control Lists, Locks and Keys
Access control List attaches authority to object. Can be messy, but controls access to data and metadata
Capability attaches authority to subject (Party Invite) Problem with copying invite or revoking invite.
Access Control Matrix is table of all subjects and objects
Lock and Key - hybrid of above. Objects have locks and subjects have keys (Cryptographic)
Access Operations
Windows -> Domain -> Domain Controller(Server)
Access Decisions
Discretionary Access Control List DACL =restricting access to objects based on the identity of subjects and/or groups to which they belong
System Access Control LIst SACL (mandatory)
Policy
Inheritance
Access Control
Objects
2 more items...
Subjects
2 more items...
Principals
1 more item...
Permissions
1 more item...
Task Rights
Unix
Subject
Subjects are PROCESSES and have ProcessID (PID). Also have REAL UID/GID (inherited from parent => UID/GID of user) and EFFECTIVE UID/GID inherited from parent process or file being executed. Usually the same.
Passwords
Hash stored in shadow /etc/password. Use [crypt3] algorithm and salted.
SuperUser
Privileged user UID 0 - root- all security checks turned off. Cannot write to read only file, nor decrypt passwords ( but can reset and remount)
Objects
'Everything a file' incl. I/O, memory devices, directorie. These resources are the OBJECTS of ACCESS control. Organised in tree called INODE. The fields in the inode are relevant for the access control
Directory listing example [ drwx --- --- 2 dieter staff 521 Oct 25 17:44.ads/ ] => File type, File permissions,Link counter,UserName,Group,File size, Modification time, file name.
Principals
UID: userID and GroupID are 16bit stored in the. /etc/pwd file
1 more item...
Permissions
First 9 bits indicate permissions r = 4,w = 2, execute = 1. Default to 666 when creating file, 777 when creating a directory. UMASK used to specify rights to be withheld. Eg 666-> 022 = 644 (all permissions for owner, but only read and write for remainder)
Directories; Read => allows read of index to find files in directory. Write => add and remove files from directory. Execute => to make the directory the 'current directory' => open files inside that directory
Change access with chmod, change ownership with chown.
If SuperUser privilege required: SetUID, SetGID programs run with EFFECTIVE ID of owner which gives access to normally inaccessible files. [owner bit changes from x to s = controlled innovocation]
SUDO changes UID of program-> if owned by root ->controlled innovocation implication/security problem-> confused deputy. Only use SUID if absolutely neccessary.
Order and Access control on UID/GID. If subjectsUID owns files then owner decided access. If subject UID NOT owner of file, but GID does, then group decideds access. If subjects UID and GID not the owners of file then Other decides access. [Permissions can be changed by owner to allow access if required]
Security Principles involved; Controlled Innvocation and the Confused Deputy . User Programmable sharing - access control via change password prog. Least Privilege. Security boundaries/attack surface. REWATCH RELEVANT LECTURE
WINDOWS
Registry: Central configuration database - entries called keys. Groups of keys and values is a Hive.
Two modes
Kernel mode- security component is Security Reference Monitor. Problem: device drivers from 3rd party products run in kernel mode.
User Mode - Security Components; Logon(winlogon), LSA(local security authority), SAM(security accounts manager).
Single machine administered locally vs Domains required for commercial use
Domains
4 more items...
Access Control Terminology
Logon rights - determine means of accessing a computer
Privileges - non logon related rights. eg loading device driver
User right - authority to perform operation that affects system as a whole. Part of system's Security Policy
Security context - Principals Identity and authorities on a system
Permission - authority to access specific object
Security Identifier SID unique value tat identifies; User, Group, or Service with an enterprise
Security descriptor - stores the access control info for an object: Owner.Primary group.DiscetionaryACL and SystemACL
#
Securable object- has a Security Descriptor attached
Access token - protected object that contains info about identity and privileges associated with User account.
5 more items...
Access Control List contained in DACL in Security Descriptor. Is a List of Access Control Entities
ACE
#
Type x 3: +Access allowed, - acess denied, audit for object type
Inherited Object Type
Flags- audit and child inheritence rights
Object type for Directory services objects
Access Mask - determine access rights
Trustee - Principal SID the ACE applies to is trustee
Access Control Decisions: The Security Reference Monitor
Checks an object's DACL for ACE in systematic fashion, that apply to User/groupSID from threads access token
Order of ACE in DACL important: First one that matches is applied. Generally put Deny ACE before allow ACE
If no DACL everyone has access. If NULL DACL, all access is denied.
Owners
#
Objects get Owners when created
Owner is the principal
Stored as Security Descriptor of Object
Usually as Read_Control, Write DAC
Ownership can be obtained via the Privilege
Permissions
Access rights/what can be donewith an object
5 more items...
Inheritance
Control by Flags: Inherit_only, No_propagate, Object_inherit, Container_inherit. Inheritance can be blocked by SE_DACL_PROTECTED
Control by Object Type: specifies the Object TYPE that inherits the ACE
Is a systematic automatic procedure for assigning ACE. When an object is created it inherits its ACE from the container(directory) in which it is placed. Active Directory may contain objects of different types and requires a selective inheritance strategy. Can be Static, whereby ACE inherited from container, but changes to container have no immediate effect, versus Propagating where changes to container propagate to the contents.
Control of Ordering in DACL: Locally added ACE in front of inherited ACE. Principal is specific policy overrules general policy
User Account Control;Design Principle Less is More
When user logs on two tokens created:User and Admin
1 more item...
Single user may have administrator rights giving processes have unneccessary rights. UAC puts constraints on this.
Ownership Mandatory system wide policy decision.eg includes BLP and BIBA. Takes precedence over IBAC. Objects are assigned sensitivity labels (classification+category) Objects inherit labels.
Intermediate Layer between User and Object
#
Groups
Permissions
Role based Access Control; The user is the focus with the goal to separate/confine users. Often assumes that the process 'is' the user.
[General Principle to consider. May ignore the separation of user and (the abstraction of) principal, and subject (who is the agent of the principal). May then allow process to do things that user doesn't want.]
Hierachal design defined as role to role relationship. Privileges defined once then inherited. (not neccesarily correlate to organisational structure eg CEO is not given admin access to Cf.
A Session is the mapping between the User and subset of roles assigned to them. The users session is the subject(process), and user can de/activate roles. Role constraints used to restrict mutually exclusive roles, allowing for separation of duty. eg user who writes the cheque can't sign the cheque.Static separation prevents user from ever holding conflicting roles. Dynamic Separation prevents concurrent role activation.
Reduces complexity of management by using abstraction 'Roles' to assign and manage privileges. Specifies the MINIMUM set of privileges to perform a task.
Core RBAC(NIST Standard) : Users assigned to roles, permissions assigned to roles, user get permissions via role membership.
Cardinality specifies Maximums in relation to role. Max number of users assigned to role, max number of roles user can be assigned to, max number of simultaneous sessions.
Pre requisite role require user to hold a specific role before being assigned another.
Code based control seeks to confine code rather than RBAC's approach of confining user
Confinement: Sandboxing/Virtual Machines, but have limited mechanisms for data exchange. How do you get data in/out of VM and was it changed?
Flexible Rules: Sandbox approach but not All or Nothing, diificult to implement. Coarse grained=Android. Fine grained SElinux. User friendly AppArmour.
Code authentication - not so much confine code, but identify if can be trusted. Requires user to make decision=weakness. Mechanisms: origin, digital signature (java,.NET, Windows), proof carrying code.
Functionality trade off with security: Who provides the policy? vendor vs community vs user vs sys admin etc.
Confinement Examples:
File based
: chroot, jail, Linux container, OSX sandbox.
Interpreter based
Java virtual machine, Silverlight, Flash.
Native code sandbox
Functionality-Based Application Confinement: Role based Principles to Code access control => abstraction of hierachical policy='Functionalities'. The user generates policy by selecting the functionality the application should have. Reduces trade off between security and function, and superior to Flexible rules approach.
Databases SQL
Differs from OS security - Database security controls access to info more than access to data.
Goals - Exact Data, Bounds Upper and Lower, Negative results ,Existence, Probable values
Discretionary access to SQL; User - authenticated at log in, Action - Select,Update, etc Objects - columns, rows, table and Views. DBMS decides on whether to permit access. Owner has access but other users must be granted privilege.
Views are derived relations and can offer improved security as can implement controlled innovocation - that is view does not allow access to data directly. Also flexible,can replace security labels, can enforce context dependent and data dependant policy
Disadvantage of views: access checking slow, definitions maybe incorrect, may mis required sections of the database, the security relevant part of the DBMS (TCB) beomes large, maybe difficult to determine who has access to individual items. Views less suitable data needs protection rather than contolling users actions
Statistical Database using aggregate functions (Sum,Count,Avg etc) Only returns aggregate query, but inference extrapolated from results.
Aggregation Attack - sensitivity of aggregated value less than individual data. In ference Problems : Direct Attack on small sample. Indirect attack - combined info from aggregates. Tracker Attack.. Linear Systems Vulnerabilty - allows for algebraic reformulation of data.
Countermeasures; Suppress sensitive data. Disguise data with random values ( will reduce table precision). Database schema design improvement. Log user activity analyse for suss query sequence.
Discretionary Access Control (Identity based Access Control =IBAC) Creator of object is the Owner. Owner decides policy. Does not scale well, define a Group and place that into ACL. eg Unix has Owner, Group, Other.
Levels - Unprotected vs All OR None(Twitter) vs Shared (FaceBk) vs User Programmable. (some Databases) tighter controls but increased potential for failure. PRECEED release of data to subject.
Internal labeling consider datas AFTER release to process, but in the same system. BLP star property (*)
External labelling - data after release from system. Uses physical measure, legals, cryptography and /or trusted code.
All these branches link to CIAOO services
Definitions
Objects - resource requested by suject. Ususally a file.
Subject - active identity on a system. Is the agent of a principal. Usually a process and is a manifestation of the user exercising privilege on a system
Principal - abstract notion of identity to whom specified rights are accorded
User Person real world and responsible for authentication request.NOT EQUAL User Identity (principal) a name in the system which is probably associated with User person. If authentication OK, then authorised to exercise privileges as security policy
Process ( subject) presumed to operate on behalf of principal. [Not always.eg malware or successful login to account by unauthorised persom]
Permission is access right to perform operation on system.
Privilege is the set of permissions given..
Cryptography - maths is immutable and independant => cryptography can provide security without reference monitors. Provides: Confidentiality, Integrity checking, Authentication of origin
Public (Asymmetric)
Digital signatures
One way hash
Properties
Examples
HMAC
Cryptographic signatures
Symmetric - Single key encrypt and decrypt. Fast, but key exchange is the problematic. Strength not so much key length but other factors such as entropy.
Algorithms
Block Cipher
Stream Cipher
Quantum computing
Elements: Sender-> Receiver ( Alice -> Bob). Message Plaintext -> Ciphertext. Algorithm/cipher to encrypt - Not secret. Key to decrypt. Key size is in bits. Key space is the number of keys possible in the key space.
Models: Traditional vs Trusted Third Party ( e-commerce)
Assurance levels -Empirical(time tested) Provable, Unconditional
Reference Monitor is abstract machine that mediates all access to objects by subjects
Security Kernel is the implementation of the Reference Monitor - Users must not be able to MODIFY OS. Can invoke OS , but not misuse => Confused Deputy
Trusted Computing Base is the totality of all protection mechanisms responsible for enforcing security policy. Trusted Path is secure mechanism to obtain authenticated access to TCB
Mode of Operation - OS Protection requires distinguish between computations on behalf of User vs those on behalf of OS. Intel X86 4 modes, but only need Not Privileged OR Privileged
Controlled invocation - system performs predetemined a set operations in supervisor mode( eg memory write as supervisor then returns to user mode level
Traps to deal with interuptions - CPU saves state on stack executes handler->clears supervisor state-> return to user
Privilege level in X86 only changed by POPFlag-
Protection rings
Is this the Security Kernel as a whole, divided into 4 rings??
0-3 Ring level: OS kernel in 0, OS in 1, Utilities in 2, User in 3. Processes only access objects in their ring or higher(outer). Must use GATES to access lower rings
GATE exists in ring and points to lower levels - grants increased privilege to inner ring for execute only access and then returns back to user privilege level.
CONFUSED DEPUTY ATTACK a low privilege entity can invokes a high privilege entity to violate security. Eg copy inner ring data to outer ring
ARPL - adjusts privilege level of calling process; Requested level changed to Current Privilege level. Pub Bouncer analogy?
DPL descriptor Privilege Level- stores privilege level of an object.
CPL current privilege level. Access control via comparison with DPL
Memory Protection MUST separate user space from OS space, AND logically separate users, AND restrict the memory objects a process can access
#
Segmentation and Paging : Segementation of memory into logical units, better for security, harder for memory management as lengths vary
Paging divides memory into pages of equal length, good for management, bad as not logical units => Covert channel on page fault
General Strategies: Sandboxing, Realtive)offset) addressing, OS address bounds checking
Trusted Computing Module -> TPM chips
Remote Attestation
Encryption plus binding and sealing to a machine and its state
Authenticated boot
Protected storage -> keys storage.TPM verifies current machine state /cf before releasing decryption key. Application becomes trusted after key release and verification
I/O - all commands through this component plus cryptographic operations
Machine language level
Advantages
Complete Mediation
Separation
Unity of functions(single piece of code)
Centralised
Compactness - focused on core security
Verifiability
Layer Below Access
Security mechanisms in a given layer compromised by layer below ( eg. Buffer overflow). Basic Principle -> Must ensure mechanisms: cannot be bypassed, they are easily modelled/analysed, and not misused( eg confused deputy)
Layer above access
BASIC OS Security
Separation between Users
Controlled sharing
Fair resource allocation
Authentication and management
Self protection
Reference Monitor Properties
Tamperproof, easily analysed and unable to be bypassed
Reference Monitors exist at multiple layers
Hardware - Access control mechanisms in microprocessors
Operating system - Access control in Windows/ Unix
Services Layer access control in Databases, Java Virtual Machine
Application - security checks in app code to address specific app requirements
Operating system kernel eg hypervisor -> virtual machines
Architectures
In line - limited application
Interpreter - program within the RM eg Virtual Machine, Java Virtual Machine
Layer below - RM acts as gatekeeper between program and OS kernel. Most common approach.
Assignment thoughts -Q= Different ways credentials are used between single user versus enterprise network. AND low level system components verifying user ID and then ensuring user processes have correct ID if granted access.
Chapt8 of text =Windows.
centralised versus decentralised control
Network User
SSO
Autonomous user
Threats (STRIDE) Vulnerabilities and Attacks(DREAD)
Vulnerabilities - CVSS and impact on CIA
DREAD = Damage Potential, Reproducibility, Exploitability, Affected Users, Discoverability
STRIDE= Spoof, TamperWith Data, Repudiation, InformationdDisclosure, DenialofService, Elevation of privilege
Strategy
Prevention
Detection
Reaction
Goals CIA.AAO
Integrity
Confidentiality
Availabilty
Authenticity
Accountability/Non repudiation
Others: Policy, Mechanism, Access control, Confinement
Design Decisions
Focus: Data vs Operations vs Users
Where to place on human machine scale / architectural layers
Complexity vs assurance
Centralised vs Decentralised
Blocking access to layer below eg back ups, buffer overflow, hypervisor malware, Unix I/O device=file.
Is the onion ring structure the Security Architecture Framework or the Mechanisms providing these services OR both together?Same as Defence in depth?
Single user versus network.THREAT, Vulnerability, DREAD -> Strategy model changes