Cyber Security TM256 Lecture Notes PDF

Cyber Security TM256 Block 2: Systems Security BY Dr. Ahmed Mahfouz AOU, Oman Agenda Part 5: Authentication, authorization and accountability 1. Authentication 2. Authorization 3. Accountability Part 6: Operating system security 1. An overv...

Cyber Security TM256 Block 2: Systems Security BY Dr. Ahmed Mahfouz AOU, Oman Agenda Part 5: Authentication, authorization and accountability 1. Authentication 2. Authorization 3. Accountability Part 6: Operating system security 1. An overview of operating systems 2. Operating system architecture 3. Principles of operating system security 4. Server hardening Learning outcomes Demonstrate an understanding of the theory and practice of systems security that includes identifying associated threats, controls and policies. Recognize threats, vulnerabilities and attack methods, and propose appropriate mitigation and security controls towards the design and implementation of secure systems and infrastructure. Communicate and analyze problems effectively within a computing environment using appropriate personal and technical skills. Demonstrate the ability to undertake ongoing learning to keep up to date with cyber security developments within digital systems. Part 5: Authentication, authorization and accountability 1. Authentication 1. Compromising passwords 2. Password policies 3. Multi-Factor Authentication 2. Authorization 1. Mandatory Access Control 2. Discretionary Access Control 3. Role-Based Access Control 4. Enforcing authorization policies 3. Accountability 1. Establishing accountability 2. Data collection 3. Log storage and management 4. Accountability challenges 1 Authentication Authentication mechanisms are used to verify the identity of an entity (i.e., user, process or device) accessing a resource in a system. Achieving the security objectives of confidentiality, integrity, availability and non-repudiation depends on being able to verify the identity of the entity accessing the system. Authentication is a key security objective that can help prevent other objectives from being compromised and so it is important that the compromise of authentication mechanisms is prevented. 1.2 Password policies Passwords are a basic element of approaches to authentication. The use of very simple passwords that can be guessed or hacked is quite common. To try to ensure that passwords provide a certain level of security, organizations often adopt a password policy: minimum password length, typically 8 characters the required mix of alphabetic, numeric and symbol characters the lifetime of a password before it must be changed words that cannot be used as a password or part of a password prevention of the reuse of previous passwords. When deciding on a password policy, human factors also need to be considered. 1.2 Password policies Users employ different passwords for each application they use. If one account is compromised, potentially all accounts will be compromised too. Users can employ password management applications that includes the following functionalities: encryption of passwords enforcement of a password policy storage of other secret information, such as credit card details, which can be accessed easily to make payments online a web-based service with access from anywhere for a wide range of devices creation of project teams and storage of passwords for the team members synchronization (in enterprise-level applications) so that changes by a team member are reflected in the passwords stored by all other applications that are running locally. A master password is often used to enable user to access the password store (e.g., biometric authentication or a hardware security key).  1.3 Multi-Factor Authentication Use two or more factors to achieve authentication. Two-Factor Authentication (2FA) use a username and password as the first factor and some other confidential information as the second factor.  1.3 Multi-Factor Authentication There are measures that are commonly taken to counter attempts to break into an account. If several attempts are made to log in, the system can prevent further attempts for a fixed time period. This protocol is designed to prevent certain types of attack, such as Brute-Force Attacks and dictionary attacks, from compromising the authentication mechanism of the system. However, it is possible for an attacker to compromise the availability of a system by exploiting this feature to launch a Denial of Service (DoS) attack, which locks out legitimate users of the system. Defending against this requires the system to take additional steps to check and filter authentication requests, based on their frequency or other features characteristic of a DoS attack. 2 Authorization The right or a permission that is granted to a system entity to access a system resource (NIST, 2023). The combination of authentication and authorization is called access control. Access control rules is a set of rules specified in a firewall to determine which device is authorized to communicate with another across the network. List of terms used in specifying authorization rules, or policies: subject: entity attempting an operation on an asset object: the asset on which the operation is being performed action: the operation that the subject is attempting to perform on the object permission: whether the request to perform the operation is allowed or denied. 2 Authorization key security properties that authorization enables in a system: least privilege: ensuring that a subject should be authorized to perform only the minimal set of operations required to complete its functions separation of privilege: ensuring that different operations involved in completing a task are assigned to different subjects, making it harder for a single subject to perform a series of sensitive operations. Access control models: 1. Mandatory Access Control (MAC) 2. Discretionary Access Control (DAC) 3. Role-Based Access Control (RBAC). 2.1 Mandatory Access Control An access control policy that is uniformly enforced across all subjects and objects within the boundary of an information system. A subject that has been granted access to information is constrained from doing any of the following: 1. passing the information to unauthorized subjects or objects; 2. granting its privileges to other subjects; 3. changing one or more security attributes on subjects, objects, the information system, or system components; 4. choosing the security attributes to be associated with newly-created or modified objects; 5. changing the rules governing access control. Sensitivity is a label assigned to every object and subject outlining what restrictions are placed on it: Information that can be widely shared has a low sensitivity Information that is restricted to only a few users has a high level of sensitivity. Rules governing reading and writing: No Read Up (NRU): a subject can read an object only if they have a clearance greater than or equal to the object’s classification. No Write Down (NWD): a subject can write to an object only if they have a clearance less than or equal to the object’s classification. Activity 2.27 Mandatory access control 2.1 Mandatory Access Control MAC advantages: 1. high levels of security since every subject and object must have a sensitivity label 2. MAC works very well in organizations where objects are strictly categorized by sensitivity MAC disadvantages 1. it is difficult to implement in practice 2. administrators must assign the correct sensitivities to potentially a very large number of objects 2.2 Discretionary Access Control (DAC) DAC is the most widespread access control model. It is used by wide range of operating systems (i.e., Microsoft Windows, Linux and macOS). Discretionary refers to the ability of subjects in a DAC system to set access controls on any object that they own. The subject has the discretion to choose how widely they wish to share an object. DAC allows owners of objects to change object access controls without seeking authorization. Administrators of DAC systems retain the power to change access controls on objects without asking the owners. 2.2 Discretionary Access Control Advantages: Access Control Lists have the advantage of being relatively simple to describe and implement. ACLs work well on computer systems with a small number of long-term users. Disadvantages: ACLs can not keep track of which resources have been used by individual users. ACLs takes a lot of time on computer systems with a large number of users. DAC is not well-suited for a user that needs access to a resource for a limited period of time. Checking that every user and every resource in a computer system always has the correct permissions is a complex and time-consuming task. 2.2.1 Access control lists In a DAC system, objects are associated with so-called permissions: 1. read (i.e., r) allows you to open a file, but not to make changes 2. write (i.e., w) allows you to make changes to a file 3. execute (i.e., x) allows you to run a program. Access Control List (ACL) is one way of controlling which subjects have access to objects by specifying a list of subjects and their associated permissions. Authorization mechanisms can be implemented at different levels of an overall system. DAC ACLs can be used to specify the permissions associated with specific objects, such as files. DAC allow ACL rules to specify more fine-grained criteria for deciding when a subject should be allowed to perform an action on an object. Activity 2.28 Permissions and ACLs 2.3 Role-Based Access Control (RBAC) RBAC is an access control model based on user roles. RBAC can handle the following issues (i.e., ACLs used in DAC-based authorization): In the size of the organizations. High rates of staff turnover Regularly change employees' responsibilities. Under RBAC, every user has one or more identified roles. Every role is associated with one or more transactions Each transaction is a combination of an object and an action. Activity 2.29 Exploring RBAC for hospital scenario 2.3 Role-Based Access Control (RBAC) 2.3 Role-Based Access Control (RBAC) Advantages of RBAC RBAC allows organizations to create a single set of transactions for all users in a role. Users are automatically assigned the correct transactions as soon as they assume a role. Every user in the role automatically has access to the most up-to-date transactions. RBAC also avoids potential security risks caused by users retaining permissions after leaving a role. Users cannot receive additional permissions without the creation of a new role. Disadvantages of RBAC For small organizations, the processes of identifying, creating and maintaining roles is likely to be more labor-intensive than assigning individual permissions under DAC. role explosion 2.3.1 Role hierarchies Roles can be arranged into a role hierarchy. A child role inherits all the transactions of its parent role as well as having its own specialised transactions. 2.4 Enforcing authorization policies Reference monitor is a set of design requirements on a reference validation mechanism that enforces an access control policy over all subjects and objects. Reference monitor encounter three different situations: 1. There is no access control rule for the subject/object/action combination being requested. 2. There are multiple access control rules for the subject/object/action combination, which specify both allow and deny permissions. 3. There is a single access control rule for the subject/object/action combination. When evaluating and making an access control decision, a reference monitor performs two tasks: 1. It authenticates any evidence supplied by the subject with an access request 2. It evaluates the request with respect to the given policy, in order to make a decision. Figure 2.45 Simplified reference monitor architecture 3 Accountability The principle of accountability and traceability states that it must be possible to trace security-relevant actions (i.e., subject–object interactions) to the entity on whose behalf the action is being taken. This principle requires a trustworthy infrastructure that can record details about actions that affect system security (e.g., an audit subsystem). To do this, the system must not only be able to uniquely identify the entity on whose behalf the action is being carried out, but also record the relevant sequence of actions that are carried out. Further, the accountability policy must require the audit trail itself be protected from unauthorized access and modification. (definition by the NIST) Main types of accountability requirements: 1. Non-repudiation: preventing entities from denying they performed particular actions on the system. 2. Digital forensics: supporting investigation of what happened during a breach in security. 3. Compliance: provides the organisation, or auditors, with the information needed to determine if the system is operating in accordance with the relevant standards, regulations or internal policies. 3.1 Establishing accountability Recording data concerning activities and events Storing information in a manner that supports analysis to determine exactly what is taking place and the investigation of any compromises of the system. Consider physical and human aspects. For instance, If a server is compromised it may be that someone has accessed the server itself directly rather than over a network. 3.2 Data collection A mechanism to record the information needed to answer the questions posed by the accountability requirements. Data could be collected by different components of the system independently. Logged information could include, for example, system-, application-, and user-initiated events such as login attempts; critical operations such as file deletions; or modifications of access control lists. Deciding what data is collected is important. Figure 2.46 An example of the logs kept by a web server application 3.3 Log storage and management Logs of different types of activity are stored in different locations, depending on the type of activity being recorded. Logs make the accountability mechanism more robust However, distribution of logs can make it harder to analyze logs where it is necessary to combine different types of data. Using of clock synchronization protocol to ensure all the components of the system can use a common timeline to log their activities. The accountability mechanism needs to have the ability to manage the data collected 3.3.1 Logging obligations UK’s General Data Protection Regulation (GDPR) requirements that have obvious obligations for logging whenever personal data is processed: tracking access to data in terms of who accessed what and when tracking modifications to data in terms of who changed what and when logging GDPR actions, such as a user giving consent for their personal information to be stored, in terms of who gave consent and when logging other GDPR-specific actions and data, such as recording the receipt of a user complaint, in terms of who complained about what and when. GDPR includes several principles for controlling the collection of personal data and restricting the subsequent use of data. These include the following: Purpose limitation Data limitation Storage limitation Accountability principle 3.3.2 Logging tools GrayLog. Nagios LOGalyze ELK 3.4 Accountability challenges The use of cloud infrastructure raises legal concerns as to where the data is stored and therefore which laws govern its access and use. Accountability requirements are going to increase in the context of the Internet of Things (IoT), due to the scale, distribution and variety of logs involved. The range of connected devices, some with little security, results in a more vulnerable networked presence. Summary of Authentication, authorization and accountability You have revisited and explored the security objectives of authentication, authorization and accountability. The security mechanisms that can be designed into information systems to achieve these objectives can help mitigate repudiation threats. You have looked at how a system can be configured to ensure that only authorized users are allowed to perform operations on components of the system. You have also looked at how different access control models can be used to help ensure security objectives, such as confidentiality and integrity, are met. Finally, you explored how accountability mechanisms and tools can be used to address repudiation threats by logging and analysing data relating to the use of a system. Part 6: Operating system security 1. An overview of operating systems 2. Operating system architecture 1. Basic operating systems 2. Monolithic operating systems 3. Principles of operating system security 4. Server hardening 1. Keeping Linux up to date 2. Server hardening activities 3. Low-level operating system hardening 1 An overview of operating systems An operating system (OS) is fundamental in managing a device’s memory and processes. Windows, macOS and Linux The security of an OS is important, not just for the protection of the device itself but also for the protection of applications and information being hosted. If the security of the OS is compromised, it may provide an attacker with access to other networked devices and resources. The core OS (kernel), provides the most essential and basic services to manage Figure 2.48 Basic layers of a computer system hardware resources. 1 An overview of operating systems The OS must also control and protect its own critical data and records of resource allocation, processes, users, and errors. It uses techniques such as access control (e.g., DAC and MAC) and encryption to achieve the protection. It provides a range of basic security services as well as resource management. It controls access to files and input and output devices, ensuring that these resources are accessible only to authorized users. Figure 2.49 OS components 2 Operating system architecture 1. Basic operating systems 2. Monolithic operating systems. 2.1 Basic operating systems The basic OS add all components in a trusted boundary. The trusted boundary ensures that the user is authenticated and authorized to access the entire system. The applications and OS components, together with users accessing the system, have access to all system components in a single domain design (i.e., less security). OSs have evolved to separate components and provide more isolation between them Figure 2.50 Basic OS model (i.e., more security). 2.2 Monolithic operating systems A monolithic operating system separates core OS components out into the kernel, which can execute with a higher privilege level than user applications. This separation allows applications to be allocated in different areas of memory for data storage, preventing them from accessing or corrupting the data of other applications or the OS itself. These OSs are considered monolithic because all the OS functions are still combined within a single trust boundary (see Figure 2.51), which can be accessed only by system administrator (or root). Applications are isolated outside of the boundary and have controlled access to resources. This design is still widely used by popular OSs like Linux, Windows and macOS. Figure 2.51 Monolithic OS model 2.2.1 Multi-server operating systems A multi-server operating system separates each OS component into its own trust boundary, with each component using the scheduler to be executed as needed. This provides an extreme model of component isolation, in which components need to use Inter-Process Communication (IPC) mechanisms to interact with each other (Figure 2.52). Multi-server OSs can integrate additional security mechanisms, such as authentication, authorization and accountability, within each component. Figure 2.52 Multi-server OS model 2.2.2 Hypervisor-based operating systems The scheduling and resource management system is known as a hypervisor. This manages virtual resources (networking, memory, disk, etc.) that are supported by the various physical hardware. In a hypervisor-based operating system, the scheduler becomes the core kernel component of the OS, providing an interface between the hardware components of the system (see Figure 2.53). A tenant is a single user account or a group of user accounts but more generally a tenant represents a project, which may have one member or be a group project. Each tenant is given a resource allocation to use in creating virtual resources. create a network on which to run virtual machines. with a router allowing access to the internet and that access controlled by security rules the tenant defines. Accessing a tenant requires authentication and authorization for the tenant account. As tenants cannot access the resources or environments of others, it is ensured that key security objectives, such as confidentiality and availability, are met. Figure 2.53 Hypervisor-based OS model 3 Principles of operating system security Understanding high-level principles of security control Confidentiality, Integrity, Availability Understanding high-level principles of server hardening Activity 2.30 Exploring OS security principles 4 Server hardening System hardening is the process of securing a system’s configuration and settings to reduce IT vulnerability. Security of a server computer (running a set of different services). What action can be taken to harden a Linux server and a Windows server? Tools, command-line interfaces, Graphical user interfaces. 4.1 Keeping Linux up to date One of the most basic and simple steps in improving security is to ensure that all the software on the server is up to date. The yum command can be used in a Red Hat Linux to ensure the system is fully up to date. maintaining a list of the software and versions installed on the system enabling new software to be installed enabling installed software to be deleted upgrading application and system software maintaining a list of repos. Activity 2.32 Keeping software updated in Linux Yum instruction to install updates Figure shows the yum update command  4.2 Server hardening activities Figure 2.55 Outline of a Linux firewall The activities use a range of Linux commands with various options to secure a Linux server. 1. Replacing the root user account (Activity 2.33 NetLabs) 2. Creating a password policy in Linux (Activity 2.34 NetLabs) 3. Removing services that are not required (Activity 2.35 NetLabs) 4. Removing software that is not required (Activity 2.36 NetLabs) 5. Blocking ports that are not required (Activity 2.36 NetLabs) 6. Creating a password policy in Windows (Activity 2.37 NetLabs) 7. Using scanning such as Windows Defender (Activity 2.38 NetLabs) 4.3 Low-level operating system hardening This type of hardening is focused on quite low-level areas such as booting the computer, memory and CPU protection. How to secure the embedded software (i.e., firmware), that manages the start-up of hardware components and then loads the OS when the computer is powered on. The start-up firmware is commonly called the Basic Input/Output System (BIOS), which describes its main functionality. The implementation of the BIOS firmware has been updated to use a standard called the Unified Extensible Firmware Interface (UEFI) The start-up firmware is responsible for a series of steps in starting the system: 1. Establish trust 2. Test hardware 3. Load additional firmware 4. Select boot device 5. Start the OS Activity 2.40 Exploring start-up firmware security Summary of In this block, you explored OS architectures, including basic and monolithic OSs. You then explored the security design principles associated with this important component of all information systems. Finally, you learned about reducing the vulnerability of a system by system hardening and reinforced your knowledge by practicing some of the steps used to secure a server OS. Block 2 has provided a broad coverage of the foundational principles of system security. Having studied this material, you should have a good understanding of the elements of system security and how they come together to make the system secure. You will build on this knowledge and understanding in Block 3, which covers how to secure different layers of information systems – namely: networks, host devices and applications – together with physical security considerations. Questions?