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.
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
Blocking access to layer below eg back ups, buffer overflow, hypervisor malware, Unix I/O device=file.
Centralised vs Decentralised
Complexity vs assurance
Where to place on human machine scale / architectural layers
Focus: Data vs Operations vs Users
Others: Policy, Mechanism, Access control, Confinement
Threats (STRIDE) Vulnerabilities and Attacks(DREAD)
STRIDE= Spoof, TamperWith Data, Repudiation, InformationdDisclosure, DenialofService, Elevation of privilege
DREAD = Damage Potential, Reproducibility, Exploitability, Affected Users, Discoverability
Vulnerabilities - CVSS and impact on CIA
Reference Monitor is abstract machine that mediates all access to objects by subjects
Reference Monitor Properties
Layer below - RM acts as gatekeeper between program and OS kernel. Most common approach.
Interpreter - program within the RM eg Virtual Machine, Java Virtual Machine
In line - limited application
Reference Monitors exist at multiple layers
Operating system kernel eg hypervisor -> virtual machines
Application - security checks in app code to address specific app requirements
Services Layer access control in Databases, Java Virtual Machine
Operating system - Access control in Windows/ Unix
Hardware - Access control mechanisms in microprocessors
Tamperproof, easily analysed and unable to be bypassed
BASIC OS Security
Authentication and management
Fair resource allocation
Separation between Users
Layer above access
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
Compactness - focused on core security
Unity of functions(single piece of code)
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
Machine language level
Trusted Computing Module -> TPM chips
I/O - all commands through this component plus cryptographic operations
Protected storage -> keys storage.TPM verifies current machine state /cf before releasing decryption key. Application becomes trusted after key release and verification
Encryption plus binding and sealing to a machine and its state
Privilege level in X86 only changed by POPFlag-
CPL current privilege level. Access control via comparison with DPL
DPL descriptor Privilege Level- stores privilege level of an object.
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?
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
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
Memory Protection MUST separate user space from OS space, AND logically separate users, AND restrict the memory objects a process can access
General Strategies: Sandboxing, Realtive)offset) addressing, OS address bounds checking
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
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)
Cryptography - maths is immutable and independant => cryptography can provide security without reference monitors. Provides: Confidentiality, Integrity checking, Authentication of origin
Assurance levels -Empirical(time tested) Provable, Unconditional
Models: Traditional vs Trusted Third Party ( e-commerce)
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.
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.
One way hash
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)
Privilege is the set of permissions given..
Permission is access right to perform operation on system.
Process ( subject) presumed to operate on behalf of principal. [Not always.eg malware or successful login to account by unauthorised persom]
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
Principal - abstract notion of identity to whom specified rights are accorded
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
Objects - resource requested by suject. Ususally a file.
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.
All these branches link to CIAOO services
External labelling - data after release from system. Uses physical measure, legals, cryptography and /or trusted code.
Internal labeling consider datas AFTER release to process, but in the same system. BLP star property (*)
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.
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.
Statistical Database using aggregate functions (Sum,Count,Avg etc) Only returns aggregate query, but inference extrapolated from results.
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.
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.
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
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.
Goals - Exact Data, Bounds Upper and Lower, Negative results ,Existence, Probable values
Differs from OS security - Database security controls access to info more than access to data.
Intermediate Layer between User and Object
Code based control seeks to confine code rather than RBAC's approach of confining user
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.
: chroot, jail, Linux container, OSX sandbox.
Java virtual machine, Silverlight, Flash.
Native code sandbox
Functionality trade off with security: Who provides the policy? vendor vs community vs user vs sys admin etc.
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.
Flexible Rules: Sandbox approach but not All or Nothing, diificult to implement. Coarse grained=Android. Fine grained SElinux. User friendly AppArmour.
Confinement: Sandboxing/Virtual Machines, but have limited mechanisms for data exchange. How do you get data in/out of VM and was it changed?
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.]
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.
Core RBAC(NIST Standard) : Users assigned to roles, permissions assigned to roles, user get permissions via role membership.
Reduces complexity of management by using abstraction 'Roles' to assign and manage privileges. Specifies the MINIMUM set of privileges to perform a task.
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.
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.
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.
User Account Control;Design Principle Less is More
Single user may have administrator rights giving processes have unneccessary rights. UAC puts constraints on this.
When user logs on two tokens created:User and Admin
1 more item...
Access Control List contained in DACL in Security Descriptor. Is a List of Access Control Entities
Trustee - Principal SID the ACE applies to is trustee
Access Mask - determine access rights
Object type for Directory services objects
Flags- audit and child inheritence rights
Inherited Object Type
Type x 3: +Access allowed, - acess denied, audit for object type
Control of Ordering in DACL: Locally added ACE in front of inherited ACE. Principal is specific policy overrules general policy
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 by Object Type: specifies the Object TYPE that inherits the ACE
Control by Flags: Inherit_only, No_propagate, Object_inherit, Container_inherit. Inheritance can be blocked by SE_DACL_PROTECTED
Access rights/what can be donewith an object
5 more items...
Ownership can be obtained via the Privilege
Usually as Read_Control, Write DAC
Stored as Security Descriptor of Object
Owner is the principal
Objects get Owners when created
Access Control Decisions: The Security Reference Monitor
If no DACL everyone has access. If NULL DACL, all access is denied.
Order of ACE in DACL important: First one that matches is applied. Generally put Deny ACE before allow ACE
Checks an object's DACL for ACE in systematic fashion, that apply to User/groupSID from threads access token
Access Control Terminology
Access token - protected object that contains info about identity and privileges associated with User account.
5 more items...
Securable object- has a Security Descriptor attached
Security descriptor - stores the access control info for an object: Owner.Primary group.DiscetionaryACL and SystemACL
Security Identifier SID unique value tat identifies; User, Group, or Service with an enterprise
Permission - authority to access specific object
Security context - Principals Identity and authorities on a system
User right - authority to perform operation that affects system as a whole. Part of system's Security Policy
Privileges - non logon related rights. eg loading device driver
Logon rights - determine means of accessing a computer
Single machine administered locally vs Domains required for commercial use
4 more items...
User Mode - Security Components; Logon(winlogon), LSA(local security authority), SAM(security accounts manager).
Kernel mode- security component is Security Reference Monitor. Problem: device drivers from 3rd party products run in kernel mode.
Registry: Central configuration database - entries called keys. Groups of keys and values is a Hive.
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
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]
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.
Change access with chmod, change ownership with chown.
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
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)
UID: userID and GroupID are 16bit stored in the. /etc/pwd file
1 more item...
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.
'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
Privileged user UID 0 - root- all security checks turned off. Cannot write to read only file, nor decrypt passwords ( but can reset and remount)
Hash stored in shadow /etc/password. Use [crypt3] algorithm and salted.
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.
Windows -> Domain -> Domain Controller(Server)
1 more item...
1 more item...
2 more items...
2 more items...
System Access Control LIst SACL (mandatory)
Discretionary Access Control List DACL =restricting access to objects based on the identity of subjects and/or groups to which they belong
Access Control Structure: Capabilities and Access Control Lists, Locks and Keys
Lock and Key - hybrid of above. Objects have locks and subjects have keys (Cryptographic)
Access Control Matrix is table of all subjects and objects
Capability attaches authority to subject (Party Invite) Problem with copying invite or revoking invite.
Access control List attaches authority to object. Can be messy, but controls access to data and metadata
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