By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.
Domain Objectives 2.1 Given a scenario, apply security solutions for infrastructure management. 2.2 Explain software assurance best practices. 2.3 Explain hardware assurance best practices. Objective 2.1 Given a scenario, apply security solutions for infrastructure management Infrastructure Management Managing an organization’s infrastructure can be a nightmare at worst, and a lot of hard work and attention to detail at best. This is especially true when you consider what is involved with infrastructure management. First, let’s define what infrastructure is. At first glance, the infrastructure may seem to be just the network devices, cabling, servers, and so on. But an organization’s infrastructure includes all those things and so much more.
A complete picture of an infrastructure includes not only servers, network devices, and the physical cabling that connects them, but also hosts and applications. It contains data flows and interfaces. It also includes storage locations. It even consists of the policies and procedures that impose the requirements on the infrastructure for how it will protect, transport, and store information.
Often the infrastructure is broken up and managed by function; that is, there may be a group of people in the organization that manages only applications or only the network devices. However, these different groups have to work hand-in-hand across organizational boundaries because all of these pieces of infrastructure are still connected and require a unified approach. All these different levels and segments of the infrastructure are responsible for creating, processing, transmitting, receiving, storing, and protecting data, which transits across management and organizational functions. In this objective, we’re going to look at different aspects of managing an organization’s infrastructure. We’ll talk about managing infrastructure within a cloud service offering versus on-premises infrastructure management.
We will discuss managing assets, and segmenting those assets, both physical and virtual. We’ll also discuss the network architecture itself and different aspects of how modern networks are designed and managed. We’ll discuss change management practices and their importance.
We’ll also talk about specific techniques to manage an infrastructure, such as virtualization and containerization.
We’ll also discuss the importance of identity and access management in the organization. Finally, we will discuss a hodgepodge of other essential aspects of managing the infrastructure, including cloud access security brokers, honeypots, infrastructure monitoring and logging, encryption, and certificate management. We will also emphasize active defense as a critical part of infrastructure security. Cloud vs. On-Premises In Objective 1.6, we discussed the different threats and vulnerabilities associated with cloud service models. You are already aware, then, that some of the advantages of using cloud models are a reduction in costs, less of a need to maintain in-house expertise, and less infrastructure to manage.
The disadvantages, however, include a lack of management visibility on organizational data and the assets that process that data. The same advantages and disadvantages apply to managing an organization’s infrastructure.
In a cloud-based infrastructure, your service level agreement (SLA) allows you to depend on the service provider to maintain an up-to-date infrastructure, to include patching, secure configuration, and state-of-the-art equipment. You also rely on them for guaranteed reliability and availability. These are issues you don’t have to concern yourself with as much as assets located on your organization’s premises. However, you are forced to transfer some of the control you might generally have to the service providers. You don’t always get to determine or dictate how assets are employed in support of the organization’s mission.
The following table summarizes the advantages and disadvantages of cloud-based infrastructure versus on-premises infrastructure: Asset Management Asset management is a broad term used to describe managing any asset that is a part of the organization’s infrastructure. Many inexperienced cybersecurity analysts believe that asset management is simply computer hardware inventory; it’s so much more than that.
Remember the definition of an asset: an asset is anything of value, tangible or intangible. Assets directly contribute to business operations and successful missions. An asset could be computer equipment, to be sure, but it also includes software, other specialized equipment, facilities, and people. Assets can also include knowledge or information or data.
These are all tangible assets, or assets you can physically touch, see, read, and so on. Although there are intangible assets as well, such as customer or stockholder confidence, the focus of this module is on specific tangible assets used in the organization’s computing infrastructure.
Asset management is also more than merely inventorying physical devices. Of course, you will maintain an accurate, up-to-date inventory of hardware and software, but it also means managing licenses, provisioning services and users, and supporting business operations. It may mean reallocating resources to critical processes from noncritical ones. Asset management is an ongoing, constant process. Asset Tagging Asset tagging refers to the practice of identifying assets, both hardware and software, through logical or physical means. Physically, computer hardware can be tagged using metal plates or other types of physical markings. A physical tag should include the name of the asset, make, model, and serial number. It also may indicate additional information, such as the organization that owns the equipment. A logical tag could apply to the underlying software or firmware that resides on the equipment. For example, modern firmware, such as a BIOS or UEFI implementation, may have that same information, such as make, model, and serial number embedded in it. Even software can have the same information embedded in it, from its licensing agreement when it is purchased and installed. Sometimes this information is changeable by administrators, but sometimes it is not. Both physical and logical asset tagging doesn’t end with merely applying a tag to a physical piece of equipment or embedding information in its firmware or software. By itself, tagging only serves to identify an asset visually. Where asset tagging is particularly useful is in having that information connected to a database or integrated asset management system. In this way, assets can be tracked according to their location, user, owner, and even the customer they support. Wireless and mobile assets benefit from asset tagging because you can add much more information about the asset into your asset management system and track its location in real time, using its wireless or cellular capabilities. This can help you track where the asset, such as a smartphone or tablet, is currently located, where it has been, and where it is going. You can also set up advanced features such as geofencing, which enables you to set a physical boundary in which the asset cannot leave that area or at least notify you when it does. This is typically only used for highly valuable or sensitive assets that may contain sensitive data and should not leave company premises. Segmentation Large network infrastructures are typically not flat, or contiguous. Networks are usually broken up both logically and physically, by location, by connection to certain other network devices, and through IP address subnets. Segmentation is important because it can help network performance, make it easier to organize the different assets and systems in use, and give you an additional level of protection in terms of security.
For example, from your earlier networking studies, you are probably already aware that smart switches are preferred over simple hubs to segment hosts because they can separate collision domains. Routers are also used to segment hosts, and indeed entire network segments, because they help eliminate broadcast domains. These logical and physical segmentations benefit the infrastructure’s performance. However, security is also a benefit of segmentation. Segmentation can allow a user to access only specific hosts on the network, because sensitive hosts are segmented away either logically or physically from users. Only certain groups of users may be able to access those hosts.
In this section, we will discuss several different categories of segmentation, all falling into the two types of physical or logical. These include physical, virtual, jump box, system isolation, and air gap. Physical Physical segmentation can involve a couple of different aspects. First of all, the physical location itself can segment critical assets. They can simply be in different parts of the building, or across the country in different geographic areas. This not only can help ensure redundancy in the case of duplicative equipment, but also ensure that if an adverse event occurs at one location, it spares another location where other critical assets are kept. Second, physical segmentation can make use of network devices, such as switches and routers, to physically separate hosts from being on the same physical network segment or cable. This can be especially advantageous if a piece of fiber or Ethernet cable is cut, for example, or the organization suffers a power loss to parts of its infrastructure that may not affect other parts due to the physical device segmentation. Virtual Virtual segmentation is a type of logical segmentation. This can take many forms. First, at a basic level, hosts and entire networks can be logically separated through the use of different IP subnets. Even if they are all attached to the same physical media, the traffic between hosts is logically separated in that it doesn’t have to be transmitted or received by all hosts on the network due to a logically separated addressing scheme. Logical separation can also be employed using encryption methods. It’s not uncommon to see sensitive information or even all traffic from specified hosts be encrypted and sent over unencrypted links that are shared with non-sensitive hosts. Each host that transmits or receives encrypted traffic must be specially configured to do so and can be set up to communicate only with other hosts that use the same encryption algorithms and keys. Still another form of virtual segmentation is the use of virtual hosts. Virtualization will be covered a little bit later in this objective, but segmentation using virtualization involves running independent virtual machines on a physical host where hardware is abstracted from the virtual machines. The virtual machines could be configured to communicate with any, all, or none of the other virtual machines, even if they reside on the same physical hardware. Jump Box Sometimes sensitive systems on the network have to be given special consideration for segmentation or protection away from the general population of the organization. There are many different ways to do this, and one of them is to use a jump box. A jump box is a specially configured host whose sole purpose is to log on to or access a sensitive network segment or systems. For example, rather than using a desktop computer, which is typically employed for routine tasks such as e-mail and web surfing, an administrator might use a specially configured box to access sensitive servers to perform administration tasks on them remotely. These servers would not be accessible from any ordinary workstation due to physical or logical segmentation. In this case, the jump box serves as an access point from where the administrator can perform their administrative duties on those sensitive hosts. While not a firewall or a bastion host, the jump box could be considered a chokepoint or a single-entry point into accessing sensitive systems. The jump box typically would be securely configured, stripped of unnecessary services and software, and hardened more than a regular workstation might. The jump box might also have more than one network card, enabling it to be logically on two or more different network segments, effectively allowing it to segment ordinary hosts from sensitive ones. System Isolation System isolation is used when you have a particularly sensitive host or system that needs to be separated from the general population of users and hosts on the network. Perhaps only certain users or hosts should be able to access this sensitive device due to the nature of the data it contains. There are several different ways you could isolate the system, and segmentation is one of them. For very sensitive systems, both physical and logical segmentation would be ideal. This might include dedicated subnets, switches, and routers. It also might mean the use of encryption for all traffic between that particular host and others. It obviously should require different authentication methods for access, including multifactor authentication, if possible. Sensitive hosts might reside on their own specific VLAN as well, and there might be intermediate network devices that use very strict access control lists to control who accesses the system, using only explicitly allowed ports and protocols. This would likely be a special-use box, not intended for anyone to access for e-mail or other general purposes. The key here is to isolate the system from the general-use network and other systems and ensure highly restrictive access to it. Air Gap An air gap is the ultimate in system isolation and segmentation. Essentially, there is no logical or physical connection to the host or network segment from the Internet or the general-use network. Any data transferred between an air-gapped system and another system would have to use physical media of some sort, such as a USB drive or CD. Even these might be highly restricted in their use; only specific external media devices might be allowed, and they might have to be part of a carefully controlled inventory.
The system requiring an air gap segmentation would likely be for highly sensitive or specialized use and would require no connection to the outside world or the company network.
An example of an air-gapped system might be one that you use to scan external media for malware. Anyone bringing any type of removable media into the organization, such as a USB stick or CD, would put that media in the air-gapped system and scan it for malware. Once it is determined to be safe, the media can be used on other systems connected to the network.
Another example of an air-gapped system might be one that contains a specialized database. The database doesn’t need to be connected to anyone, and only periodically someone might need to go to the system to retrieve specific data that must be manually input into a networked system. This ensures that the database itself is not connected to any network, so the risk of its loss or unauthorized access would be highly minimized. Exam tip: Keep in mind that segmentation is used to separate sensitive hosts from the general population of users in the network, no matter which method—physical, virtual, jump box, system isolation, or even air gap—is used. Network Architecture The term network architecture refers to how a network is designed and constructed. Networks aren’t merely a collection of hosts connected through cables or wireless networks to each other. There are both physical and logical aspects of network architecture you should be familiar with from your studies of basic networking, which we will discuss in the upcoming sections. Network architecture also describes data flows and interfaces, addressing, device placement, controlled entry points, and so on. We’ll take a look at both physical and software-defined (logical) network architectures, as well as how network architectures can be virtualized, such as through virtual private clouds and virtual private networks. KEY TERM: Network architecture describes how a network is designed and constructed at various layers, including the physical and logical layers. It also illustrates how components of the network interface with each other, how data flows between those interfaces, the security mechanisms in place across the network, the ports and protocols used to communicate on the network, and even how applications communicate across the infrastructure. Physical Physical network architecture describes the way that hosts are physically connected through different types of cabling or media to different network devices. The physical network architecture also describes, to a degree, the different types of signaling or connections that are involved in the architecture (Ethernet, wireless, or token ring, for example).
From your basic network studies, you probably remember the different types of basic physical architectures: - Star: Uses a centralized hub or switch from which hosts are connected individually through a network cable - Bus: Describes hosts that are attached to the same physical media, usually by tapping into a centralized cable - Ring: Uses a central hub with a cable connecting all stations in a logical circle or ring configuration - Mesh: Employs multiple hosts that are all connected - Hybrid: Could be a combination of any or all of these physical designs Smaller networks use simplistic designs; however, larger and more complex networks use highly complicated versions of these same basic physical architectures. Exam tip: You are not expected to answer questions directly regarding physical architecture, but you should be aware of the different physical layouts, including star, bus, and ring architectures. Software-Defined Networking Logical network architecture refers to how network devices are named, assigned addressing information, and communicate with each other via different network protocols. More often than not, software or operating system utilities determine these design elements. These are all straightforward elements; however, there are more sophisticated logical network architectures that are completely built within the software and define not only protocols and addressing but also subnets, network segmentation, access control, and so on. Software-defined networking (SDN) is a term that describes a network architecture built entirely in software, wherein various applications are responsible for determining data routing and control within the network. This approach also defines dynamic network programmability; this means the network can change as the organization’s requirements change.
Software-defined networking is defined in an Internet Engineering Task Force (IETF) Request for Comments (RFC) document, RFC 7426, and describes the structures used to create and manage these networks. It also defines standardization for how these programmable networks will use resources, network devices, interfaces, applications, and services. Exam tip: Remember that logical architecture is separate from and can be different than the physical architecture. The logical architecture is almost always defined in software or network services. Virtual Private Cloud (VPC) A virtual private cloud (VPC) is a set of dedicated resources, set aside for one organization’s use, either in its own data center or even in a cloud service provider. We’ve already looked at cloud models in Objective 1.6, so remember that this is one of the many models you can use to implement a cloud infrastructure with a cloud service provider. If a virtual private cloud is set up in an organization’s own data center, using organizationally owned resources and assets, there’s much not much difference between it and an on-premises infrastructure; it simply emulates a cloud infrastructure and is suited for use across geographically dispersed locations within the same organization. If the virtual private cloud is part of a public cloud service provider’s infrastructure, then it is segregated so that no other cloud service user outside the organization can access it. The organization dictates access controls, such as authorized users, authentication methods, and so on, subject to the provider’s offerings. Virtual private clouds are most commonly seen as an Infrastructure as a Service (IaaS) offering from a cloud service provider. The piece of the cloud that the service provider has segregated for the organization’s use is isolated using a multitude of technologies, including virtual LANs (VLANs), and even dedicated physical and virtual servers in some cases, as well as other structures that ensure complete privacy and isolation from other customers also supported by the cloud service provider. Major service providers that offer a virtual private cloud implementation include Amazon Web Services, Microsoft Azure, IBM Cloud, and Google Cloud Platform. KEY TERM: A virtual private cloud is a cloud infrastructure set up using an organization’s own resources and data center, and for the exclusive use of the organization, no matter where it is geographically dispersed and located. Virtual Private Network (VPN) A virtual private network (VPN) is essentially two private networks separated by a larger public network, such as the Internet. In a virtual private networking setup, a single host or even another branch office (called a site-to-site VPN) can logically connect to a private network through the use of a secure tunnel. Tunneling protocols provide the ability to encapsulate sensitive traffic inside other traffic. Think of putting a confidential message inside an envelope and sending it through the public United States Postal Service (USPS) system. The envelope is sealed and addressed appropriately so that it can travel through the postal system network to its intended recipient. The envelope, usually being opaque, prevents anyone from seeing the private message inside. VPNs work similarly. The client typically has to have specialized VPN software, which allows it to establish a connection through a public network, such as the Internet, using a tunneling protocol. The client is authenticated to the organizational network through a specified VPN gateway server at the organization’s private network, typically using credentials especially provided for VPN connections. Sensitive data is sent through the Internet, usually encrypted, using the tunneling protocol until it arrives. The traffic is deconstructed, and the sensitive information decrypted, which is then forwarded on through to the organization network, just as if the client was part of that network. The tunneling protocol generally used for modern VPNs is the Layer 2 Tunneling Protocol, or L2TP. L2TP is an updated version of a combination of two older VPN protocols: Point-To-Point Tunneling Protocol (PPTP) and Layer 2 Forwarding (L2F), developed by Microsoft and Cisco, respectively. Note that L2TP does not do anything except encapsulate the traffic that travels through a public network such as the Internet. It can’t encrypt or otherwise protect sensitive traffic; therefore, it’s usually used in conjunction with security protocols, such as IP Security (IPSec), which provides those encryption and authentication services. Note that there are also VPN connections that can take place over secure web browsers, using the HTTPS protocol, which uses Transport Layer Security (TLS) as its secure transport mechanism. IPSec is a security protocol that’s relatively new to the IP version 4 stack. It is native to IPv6, however, and mandated for use whenever IPv6 networks are used. IPSec has two modes of use: transport mode and tunnel mode. In transport mode, the IP address headers are not encrypted; this allows it to travel within a private network. When used in tunnel mode, however, it requires a tunneling protocol, such as L2TP. In tunnel mode, the IP address header information is encapsulated by L2TP, making it better suited for traveling across a public network. Tunnel mode is the mode associated with VPN connections. IPSec also uses two primary security protocols: Authentication Header (AH), which is used for data integrity and data origin authentication, and the Encapsulating Security Payload (ESP), which provides data encryption and other security services. IPSec uses security associations, where all parties of the communications session establish and share security attributes, such as algorithms and keys, so that all may communicate securely. Exam tip: VPNs make use of tunneling protocols, such as L2TP, and must also use security protocols such as IPSec for encryption and authentication services. Change Management An essential part of infrastructure management is managing change. Change management is concerned with the organized processes of approval, testing, and implementation of infrastructure changes, whether it’s adding new servers or subnets, updating enterprise applications, or adding new capabilities to the infrastructure. If the organization allowed random or unplanned changes to take place, the infrastructure would be severely impacted. There might be performance issues, interoperability issues, lack of standardization, and certainly security problems. Change management is the formal process that requires management involvement and approval for all infrastructure-related changes. The organization should have a change management policy and procedure, as it should with most processes.
The change management policy and procedure, directive in nature, should include the following items: - Roles and responsibilities - Formal change management processes - A requirement for business cases for all significant infrastructure changes - A requirement for security, functionality, and performance analysis for all proposed changes - Procedures for introducing, testing, and implementing all changes - Procedures for backing out changes that adversely affect the infrastructure - An impact rating for changes - A requirement for establishing a formal change control board (CCB)
For this last requirement, the policy should direct that a change control board be chartered. A CCB should include mid- to senior-level managers who are in charge of receiving recommendations for major infrastructure changes and deciding whether or not those changes should be allowed, based on risk to the organization. Even a change from a well-meaning system administrator might incur risk for the organization, such as causing the infrastructure to no longer be interoperable or secure. Because changes can impact the entire organization, it’s only common sense that management can review the proposed changes and have the power to approve or veto them. The CCB serves that function. For the change management process to work, a requester or initiator for the change must present a business case, often provided by a business unit, to the CCB, as well as documentation about the particulars of the change and how it will impact the organization. If the CCB initially approves the change, then ideally the next step would be to test the change on a development or test system before actually putting it into production. Based on the results of the test, the CCB may formally approve the change being placed into implementation. Once the change is final, the CCB is informed of any issues that have been caused by the change, or notified that the change has been implemented and is performing as expected. One item the CCB may require is a backup plan, in the event the change causes unexpected disruption or damage to the infrastructure. The backup plan would provide procedures for technicians to undo the change and restore the infrastructure to its original pre-change state. Another crucial part of the change management program is to create a rating system that defines changes based on their impact to the organization; this impact could be the risk to the organization if the change is not implemented, such as a low-impact change, a high-impact change, or critical change. There should also be provisions for emergency changes, in the event an incident or other significant event happens that requires changes that should be approved by the CCB. It’s important to note that configuration management is a subset of change management. Where change management can be viewed as managing sweeping changes in architecture, design, services, interoperability, and security across the infrastructure, configuration management happens at the system level. Configuration management is the process of ensuring that baseline configurations for network hosts and devices are maintained, updated, and monitored. Although technically a configuration change to a server’s baseline falls under change management, if the organization has set up a change rating structure, then routine changes to host configurations might not require full CCB approval. This might include regular patches, security configuration changes, and so on. Obviously, patches and updates should be tested and approved by someone before being implemented, especially critical patches, which may break the infrastructure. However, it may not require the full CCB for approval. The CCB should make policies and procedures for configuration changes across the infrastructure and how to deal with them. Exam tip: A change control board is usually created under the auspices of a charter, which details the board’s makeup, decision-making authority, meeting schedule, and levels of infrastructure change that require its approval. Virtualization Virtualization is another recent technology that has made managing infrastructure easier and more efficient. Virtualization involves creating multiple dynamic instances of hosts through software, called virtual machines, on physical machines. In other words, it’s possible to create a Windows 10 host, for example, through software known as a hypervisor, which resides on yet another Windows or even Linux host. Virtual machines behave as if they are actual physical machines; indeed, they share physical hardware with their host machine. The host, through the hypervisor, shares its physical hardware and manages access to memory, CPU, disk space, and networking, as well as other physical resources. If a physical host has enough memory, CPU power, and disk space, it could support many virtual machine instances on it. These virtual machines can be treated as regular hosts, running and providing a variety of services for users. They can also be backed up, replicated, and easily put into production, which makes managing them much easier, since when they are inactive, they are essentially files on disk. As mentioned, the host machine is the physical hardware that we traditionally think of as a networked host. It can run multiple virtual (guest) machines simultaneously, including those that have different operating systems than the host. Virtual machines rely on the underlying hardware power and robustness of the host machine for their performance. The host machine uses a hypervisor to manage and maintain the virtual machines.
You will typically see two types of hypervisors: Type I and Type II. A Type I hypervisor, also called a bare-metal hypervisor, is installed on a physical machine with a bare minimum of operating system files on it—essentially just enough to create and manage virtual machines. Also, it does not require an underlying operating system, as a Type I hypervisor actually is the operating system.
Examples of a Type I hypervisor include VMWare’s ESX server and Microsoft’s Hyper-V. A Type II hypervisor, on the other hand, is simply an application that sits between the host operating system and the virtual machines. Examples of Type II hypervisors include VMware Workstation, Fusion, and VirtualBox. These all require a base operating system to be installed on the host before they are installed and can manage virtual machines. Virtual Desktop Infrastructure (VDI) A virtual desktop infrastructure (VDI) is yet another way of implementing virtualization. It provides a way for users to have a desktop that is able to access network resources without requiring intense computing power for the client. Users use VDI software to make remote connections to shared network resources, such as file shares, applications, printers, and storage. The user’s client device is known as a thin client, since most of the processing takes place on a remote robust system, which delivers the visual and control experience to users’ display and peripherals. If this sounds a bit familiar, it’s because we may have come full circle with this paradigm, since way back in the early days of computing, using devices called terminals, this was almost exactly the architecture that existed because computing power and storage space was at a premium.
VDI has several advantages. First of all, it can help keep expense of resources to a minimum, as a user’s client machine does not have to be a high-powered, resilient workstation, since all the data processing and storage take place on a more robust server. The only thing the client workstation is responsible for is rendering video, accepting input from a user to send to the VDI software, and delivering output to the user. If the user’s workstation crashes, theoretically there’s no data lost. Second, VDI is useful from a security perspective. Since the user, in a restricted environment, may not be able to use external media devices, this can help prevent data loss through accident or malicious intent. Most VDI solutions also offer advanced authentication mechanisms, where the user would have to log in to their thin client and then centrally authenticate through to the VDI solution. This also enables more efficient, centralized monitoring and auditing of protected resources that can only be accessed through the VDI. Finally, a third advantage for using VDI is that it is easily implemented in mobile or teleworking environments. VDIs are particularly useful for implementation in a VPN environment. VDI implementations can be straightforward, such as using Microsoft’s Remote Desktop Protocol (RDP), or very complex, using enterprise solutions such as Citrix, or even cloud-based solutions that might use Desktop as a Service (DaaS). Critical factors in implementing a VDI solution, particularly across the enterprise, are network speed and latency as well as infrastructure robustness and resiliency. Note: Virtual desktop infrastructure is not the same type of technology as virtualization; it is referred to as “virtual desktop” because the user’s desktop presentation is a function of the VDI software and represents what’s taking place on the remote server. Containerization Just as operating systems can be virtualized within other operating systems, applications can be virtualized as well. On the surface, this may seem strange; an application is typically simply installed over an operating system, which provides it resources such as hardware, services such as authentication, and other software such as libraries. Additionally, you could conceivably create virtual machines for the sole purpose of installing applications in them to protect the host operating system from insecure applications. The virtual machine’s hypervisor can provide a layer of protection against aberrant applications, since they only affect the virtual machine they are running within. In the concept of containerization, all related files for the application are installed in a “container,” which is insulated from the operating system by another layer of abstraction; this controls communications between the application and the operating system, as well as between the application and hardware, libraries, and other services, including networked services. The reason for this is that it provides an additional layer of security and protection for both the operating system and the application itself. The container may be constructed from another management application, sometimes called the container runtime. This container application serves the same purpose as its hypervisor counterpart with virtualization. The container provides a space for the application and its libraries, files, and dependencies to run separately from those provided by the operating system; it translates all the application needs to and from the operating system to provide those resources. Whereas virtual machines are considered an abstraction of the hardware layer of the machine that supports them, containers are an abstraction of the software layer of the supporting operating system. Containers can assist in providing security for the overall system because they can shield applications from vulnerabilities suffered by the operating system, and vice versa. A disadvantage is that any issues encountered by the operating system can affect the containerization application, and may even allow damage to all containerized applications if the operating systems itself has been compromised. Popular containerization applications include Docker and Kubernetes. Applications that benefit from containerization include those that are created under Microsoft’s .NET framework and applications that make extensive use of the Java programming language. Note: Keep in mind the difference between virtualization and containerization: virtualization describes virtualized operating systems that are separated from the physical machine’s operating systems by a hypervisor, whereas containerization involves separating applications from the operating system through a software runtime layer. Identity and Access Management Identity and access management are two critical processes in the world of cybersecurity, especially in larger organizations. As cybersecurity analysts, one part of our job is to ensure that users and other entities are authenticated so they can use network resources. This is accomplished by validating the identity that an entity presents and then further controlling whatever access they have to our internal resources. We achieve this through several different methods and processes. In this section we are going to cover some of those methods and processes as well as discuss the particulars associated with the exam objectives that focus on identity and access management. We’ll talk about privilege and account management as well as discuss authentication methods, such as multifactor authentication, single sign-on, and federated authentication. We’ll also discuss access control models, such as discretionary, mandatory, role-based, and attribute-based models. Finally, we’ll talk about the necessity to monitor and review all of our different identity and access management processes. Authentication Methods While we can’t discuss every single authentication method you might encounter in your career as cybersecurity analyst, there are some essential concepts you must understand regarding authentication. Of particular importance is the role of multifactor authentication, single sign-on, and federated authentication. You should also be familiar with the basics of account and privilege management, which we’ll discuss next. Privilege Management Privilege and account management go hand in hand. They are two separate processes, but we can discuss them together. First of all, account management is the process associated with provisioning, maintaining, monitoring, and deprovisioning user accounts. This function may be delegated to a single entity, such as the help desk, or it may be dispersed across several different functions, such as within different departments. In any case, the account management function concerns itself with validating user accounts so that users can have approved and controlled access to the network and its resources. User accounts should normally be approved through several entities. First through human resources when someone is initially hired and then through the personnel security section so that their security clearance, if required, and suitability for access can be verified. They also need to be validated as requiring accounts by their supervisory chain. There are processes and procedures that go into account management to ensure that only authorized users have accounts, that these accounts can only access specific resources, and that actions these accounts can perform on those resources are controlled and monitored.
Privilege management involves the ongoing verification and validation that a user account has access to the correct resources and that they can perform the proper actions on those resources. Privilege management should be driven by the principle of least privilege, which means that a user should only have the minimum amount of privileges necessary to perform their job function, and no more. If a user’s privileges are not adequately monitored, they can eventually increase over time. This can happen if people move around from department to department and accumulate different privileges along the way. It can also happen when someone is granted privileges for special occasions that should be temporary, but then these privileges are not taken away. Initial privileges should be granted by resource or data owners who should periodically validate that user accounts still require those privileges. Privileges, which can include rights and permissions to perform actions and access objects, should be validated periodically and removed when they are no longer needed. Whereas account management may be assigned to a particular function that controls accounts across the organization, privilege management could be a function of individual resource or data owners who must approve access to those particular resources. The account management function can also be assigned to grant or revoke those privileges as resource and data owners see fit. Exam tip: Privilege management and account management are two different processes, although in the practical world they may be combined and serviced by the same administrative group in an organization. Account management involves the provisioning of user accounts, and privilege management is a function of resource owners granting access to those users. Multifactor Authentication (MFA) Remember that authentication is the process of validating that a person or entity is who they claim to be. Authentication has several requirements to it. In order to authenticate, obviously an individual or entity must present some sort of credentials as identification. Credentials could include a username and password combination, a smartcard or token, and a personal identification number (PIN). Other identifying characteristics can also be presented, such as biometric items like a fingerprint or retinal scan. Authentication is often thought of in terms of single factor or multifactor. There are several factors, or requirements, that must be met for authentication.
Factors include the following: - Something you know (knowledge factor), such as a username and password combination - Something you have (possession factor), such as a smartcard or token - Something you are (inherent factor), such as a fingerprint or retinal pattern
In a single-factor authentication scheme, a user only needs one of those factors to identify themselves and authenticate. The most common example of a single-factor authentication system is the username/password combination, which uses the knowledge factor. Multifactor authentication uses more than one of these factors. This is because individually, a single factor could be defeated, and someone can be impersonated. For example, someone could discover your username and password and use that to authenticate themselves. Multifactor authentication is more difficult to defeat because you must have at least two separate factors. For example, to withdraw money from a bank’s ATM, you must have a debit card (something you possess) and also know its associated PIN (something you know). If you lost the debit card, it would be much harder for a malicious person to find it and use it, since they do not know the PIN that must be used with it. Multifactor authentication requires at least two factors, such as something you have, like a smart card, along with something you know, such the PIN. You can also see multifactor authentication in use with a fingerprint (something you are) and a PIN. Note that the use of the username and password combination is not multifactor authentication. It is single factor because it only uses one requirement—the knowledge factor. In addition to these three factors, authentication systems can augment these factors with temporary characteristics, or attributes, that can modify the authentication requirement for a given instance. For example, location and time (temporal attribute) can be used to specify additional requirements for authentication. In addition to requiring multifactor authentication, the system may also require that authentication occur between certain hours of the day, or from a specific geographical location (either logical, such as from a particular IP address, or physical, such as from a specific host in the building). Exam tip: Remember that multifactor authentication requires at least two different factors in use during the identification and authentication process. Username and password authentication is only single-factor authentication because it only uses one factor—the knowledge factor. Single Sign-On (SSO) Single sign-on (SSO) is an aspect of authentication that involves the use of a single credential to access multiple systems or resources. Most frequently, you will see single sign-on in a centralized authentication model, such as a Windows domain. In this type of model, you would authenticate once to the centralized authentication server, such as a domain controller in Windows, and not be required to authenticate to other resources on the network, such as shared folders, printers, and so on, as long as those resources are configured to use the same authentication credentials. This requires that those resources and the servers that house them trust the centralized authentication mechanism. In environments that don’t use single sign-on, you not only might be required to authenticate for every single resource you use, such as a shared folder or a website, but your authentication credentials might be different, and even have different requirements, such as password length and complexity. For single sign-on to work, resources have to trust a centralized authentication mechanism, and the appropriate protocols have to be in place.
Examples of authentication protocols that enable single sign-on include both Kerberos and Sesame. Federation A federation is also another aspect of an authentication model in which you may have multiple organizations that either trust each other, so that authentication mechanisms and credentials are transitive across organizations, or use a centralized authentication provider. Trust is the key in a federated model; an organization must trust the authentication provider that is validating the user’s credentials, and those credentials must be valid for use in that organization. An example of a federated authentication provider that you may have seen is Google. For example, given Google’s wide range of products and services, you might use your Gmail username and password to authenticate to other Google services. Even non-Google services might accept your Google credentials. In the corporate world, an example might be where several companies trust each other and permit the use of one company’s credentials to access resources in another company, or the credentials that are authenticated through a common third party. Federated identities are often also used in single sign-on environments. Because there many third-party identity providers (IdPs) that maintain user credentials and enable users to employ the same credentials to log in to multiple sites across different organizations, standardization was needed to ensure that all these different authentication services could communicate with resources and the federated identity managers associated with the organizations. OpenID is one such standard. OpenID enables users to authenticate to different organizations and services using these third-party authentication providers. The standard defines three roles in this process: the end user, who desires to be authenticated to a resource; the relying party, which is the organization or infrastructure that owns the resource itself; and the OpenID provider, which is where the user account and credentials reside that will be used for access. Access Control Models Access control models dictate how users and other entities (such as hosts, processes, services, and daemons) are given the appropriate access to resources, based on functional need, role, and even level of trust. There are several different access control models, and we will cover the more commonly used ones—particularly the ones you will see on the exam. We’ll discuss discretionary, role-based, attribute-based, and mandatory access control models. Each has its place, depending on the requirements of the organization, and in fact there can be different combinations of each in use in the same organization, depending on data sensitivity and other protection requirements. Discretionary Access Control (DAC) The discretionary access control (DAC) model dictates that the owner of a resource be able to grant privileges for that real resource at their discretion (hence the name). They alone have the power to determine who has different levels of access to their resources. They can use whatever criteria they wish, but more often than not it’s based on their job role’s functional need, what role they play in the data process, and other factors determined by the resource owner. This is the most common access control model seen in large environments. Rights, permissions, and privileges can be granted to individuals or to groups of individuals who have like access requirements. Mandatory Access Control (MAC) Unlike DAC, mandatory access control (MAC) is not a model where access is left up to the discretion of the creator or owner of the resource. Access is only granted by specific administrators. This model uses data sensitivity separation as one factor; for example, systems can be dedicated to a specific data sensitivity level, such as Top-Secret or Secret. All data is labeled with a specific data sensitivity level. Users can only access the level of data sensitivity that they are allowed by the administrator. They also must have the required security clearance level and the need to know. Data is highly compartmentalized in this model, and even if a user had the proper security clearance, they may not have access to data at the same level. The MAC model is only used in environments where the data is highly sensitive, such as a military organization. Role-Based Access Control (RBAC) In a role-based model, access is not granted to individuals, but to roles. An individual may serve in one or more roles, such as a database administrator, account manager, and so on. Roles normally have defined functions, so privileges are granted according to what functions they must perform. In most role-based models, privileges can be cumulative, as users can be a member of more than one role, such as a database administrator and supervisor, at the same time. Note that you should not confuse roles with Windows groups, although they can be similar. Windows groups are constructs that provide convenient administration for groups of similar users. If you include all administrative users into a group and then assign privileges to that group, you are in fact assigning privileges based on roles, but you are still using a discretionary access model, since the owner of a resource still has discretion over assigning privileges to whichever users they like inside or outside the group. In a strict role-based model, only specific administrators can assign privileges roles, whether or not they are the resource owner. Attribute-Based Access Control (ABAC) With attribute-based access control (ABAC), certain attributes or characteristics can be added to an authentication requirement. Most of these attributes are temporary in nature, such as location and time of day. In other words, the user must also meet these additional requirements to authenticate, but may not be in a position to do so if they are trying to authenticate from another location or during a different time of day. Attributes can be set for the authentication process, or even as part of the requirements to access a particular resource (a folder, for example). Resources such as printers may only be available during business hours and not available afterward (in order to prevent someone from printing large volumes of personal materials on corporate printers, for instance).
Here are some of the more commonly used attributes: - Subject: Attributes about the person requesting access, including role, location, and security clearance - Object: Characteristics of the resourced accessed, including data sensitivity level, topic, and file location - Action: Requested action, such as add, delete, or modify - Context: Characteristics of the access session, including time of day, subject, and object status
ABAC offers the ability to finely tune access control, since theoretically you could grant access based on certain hours of the day, only to certain people with a specific clearance, only from a particular location, and only to files that have been changed in the past 24 hours, for example. The downside of ABAC is that it can be administratively prohibitive if it’s not well organized and maintained. Exam tip: DAC is the least restrictive and most flexible access control model, and the most commonly used. MAC is the most restrictive model and is only used in highly secure environments. Access Management Manual Review Like most of the security processes, identity and access management can be monitored through the use of automated tools. Most often, these are auditing types of tools, which serve to audit actions on objects taken by individuals. However, automated auditing tools may not catch everything; manual review is often required to look for anomalies that may be connected but are outside the normal baseline for automated tools to catch. When reviewing identity and access management, cybersecurity personnel should look for anomalous or strange patterns in behavior—a user employing privileges they have never used before, for example, and doing so without explanation. Audit logs can provide an event-by-event breakdown of which user accounts have been using which privileges, as long as auditing is properly configured. Object access must also be reviewed, which assumes that object auditing has been properly configured as well. This data can be combined with other sources, such as operating system or application logs, and fed into an aggregation engine, such as a SIEM system, to help with manual analysis and to determine if there are any disturbing patterns in access control management. Cloud Access Security Broker (CASB) In a modern organization that uses cloud services, it’s not very often that you find your organization is exclusively tied to one cloud service, where the connection is simplistic and easy to manage. More often than not, organizations use multiple, different cloud service product providers for different services. Cloud service providers don’t always have standardized methods of access control or monitoring, and every service that the organization uses may require different types of access control mechanisms, authentication protocols, and so on. One solution for this is to use a cloud access security broker (CASB), which sits between the organization and all of its different cloud services. A CASB can be configured to monitor all activity between users and cloud services, handle authentication, enforce access control policies, and audit for malicious action or policy violations. Key term: A cloud access security broker is an intermediate management mechanism that manages and negotiates authentication and security services between users or internal hosts and various external cloud service providers. Honeypot A honeypot is nothing more than a sophisticated decoy that’s set up to attract malicious entities so they will focus on it instead of attacking your network. A honeypot is a special host, usually placed in an isolated segment away from critical or sensitive hosts, that has numerous vulnerabilities programmed into it. The idea of a honeypot is that if an attacker is looking to attack your network, they will be distracted by the decoy and focus their time and attention on it. This can give your intrusion detection and prevention systems time to alert your administrators so they can monitor the attack, learn about the attackers techniques, and attempt to detect details about the attacker that can be used to stop them, locate them, and prosecute them. Larger organizations may deploy many such decoy hosts in a network configuration, called a honeynet, which may be very sophisticated in nature and appear to be a full-fledged segment with sensitive hosts, network devices, and so on. The idea is to offer enough potential attack surfaces to a malicious entity that they will be kept busy with the honeynet and not get around to attacking your real network. Note: When setting up a honeypot or honeynet, it is critical that you make sure your organization is reasonably secure, since you are essentially inviting a malicious entity to attack your network. Ensure you have performed your due care and diligence in setting up intrusion detection systems, perimeter defenses, and other security controls to prevent those attackers from attacking your real network. Monitoring and Logging We discussed the importance of monitoring threat intelligence as well as insufficient monitoring and logging as a vulnerability. You might believe that there’s not much more to say on either topic, but there is still plenty. These are both common themes throughout the major objectives of the CySA+ exam. In this section, we will cover yet another aspect of monitoring logging as it pertains to overall infrastructure management. We will also discuss monitoring and logging a bit more in depth during the different objectives of Domains 3, 4, and 5, as we discuss security monitoring, monitoring in the incident response context, and continuous risk monitoring.
In terms of infrastructure management, monitoring and logging are critical processes because you need to monitor several aspects of your network, its hosts, applications, and even your users. You need to understand what’s going on in the network at any given moment. You will be monitoring for major events, of course, but you’re also monitoring day-to-day smaller issues that could lead up to major events. Monitoring includes not only security monitoring, but performance monitoring, function monitoring, and user behavior monitoring. All this monitoring should be considered smaller pieces of a bigger puzzle that you’re looking to put together, sometimes on a day-by-day basis, and sometimes over a longer period of time. You want to know not only what’s happening at a point in time, but also to be able to perform historical and trend analysis so you can detect longer-term issues and problems.
Here are some of the key elements of your infrastructure you will monitor: - Network device, server host, and application performance - Bandwidth utilization - Routine network traffic - User behavior (also called real user monitoring, or RUM) - Endpoint security - Infrastructure changes, through a formal change management program
This is definitely not an all-inclusive list, as you will get down into the weeds and monitor so many more things, including anomalous network behavior, ports, protocols, services, and so much more. The point of all this monitoring is that you need to know what’s going on across your network at all times. However, monitoring does you no good at all if you are not doing something with the data that you get. Remember that information is data given context, and unless you give it context, it’s all just a lot of meaningless trivia. Aggregating all this data, developing context, and analyzing it is where the payoff comes in. Monitoring serves not only to point out all the small little things going on your network, but how all infrastructure events, no matter how small or large, are connected and show how your network is performing and how secure it is. This is where automated monitoring comes in. No single person or even a group of people can effectively monitor all of the events going on in your infrastructure. In a large network infrastructure, data will be generated at a massive rate—sometimes at a rate of thousands of events per hour, faster than human beings can sort and review them. Automated systems are needed to consume that data, aggregate it into useful information, give it context, and provide it for analysis to human beings. Security information and event monitoring (SIEM) systems are the key to successful infrastructure monitoring. A good SIEM system can take thousands of data points from a wide variety of disparate sources and put them together so that an analyst can see multiple data points at a time, how they are related, the patterns they may generate, and how they are affecting the overall infrastructure. This gives the human analyst the ability to see the overall big picture, as well as to drill down to the weeds if they need to without being inundated with so many data points that they can’t see the forest for the trees. Logging goes hand in hand with monitoring. While monitoring can be in real time, as events are happening, it also occurs over time. For monitoring to be effective, data has to be captured in some manner. That’s where logging comes in. Logging captures data that is of importance to a cybersecurity analyst so that it can be monitored after the fact, and over longer periods. There are two key considerations with logging: logging the right data and actually reviewing the logs. If these are done properly, there’s no point in logging at all, and by extension no point in monitoring the network’s security and performance. Logging, also closely related to auditing, involves determining what data points are useful and configuring your systems to collect and store events related to those data points. Logging can occur on a system basis, on an application basis, or on a network-wide basis. You can log performance information for your systems, security event information, and error information. All this information could be related, as security issues sometimes cause performance problems and generate errors that might be misunderstood until aggregated and put into context with other data sources. Most modern operating systems and applications can be configured to log specific data; however, the out-of-the-box configuration that most operating systems and programs use for logging is usually not sufficient. Knowledgeable cybersecurity analysts have to determine which specific data they need logged, and how they will use it. Logging is a balancing act, since logging everything requires a great deal of storage space and increases the amount of data, both useful and otherwise, that you must go through to discern important, relevant information. On the other hand, insufficient logging means that you won’t get any data of consequence that you can use to make informed decisions. The key takeaway from this discussion is that you cannot adequately manage your infrastructure, including its performance and security aspects, without adequately logging the events and activities that occur in your network, and monitoring them for a potentially negative impact. Encryption Although a technical discussion of encryption is a different focus from the CySA+ exam and this particular objective, encryption in the context of infrastructure management is critical. You should remember the essential concepts of encryption from your Security+ studies and other experiences, but we’ll go over the key concepts here in a brief refresher. If you feel you’re weak in the area of cryptography, you should take the time to review a more detailed explanation of its foundational concepts. Cryptography Concepts Remember that cryptography encompasses a variety of processes, including encryption, decryption, and hashing. Encryption is the process of turning ordinary human or machine-readable data, or plaintext, into data that is scrambled or otherwise obfuscated, rendering it unreadable. The result of encrypting plaintext is called ciphertext. Decryption reverses that process and returns ciphertext back to its readable form. Cryptography supports many security goals—particularly confidentiality and data integrity—because it prevents unauthorized access to data by entities who cannot decrypt the data as well as ensures integrity by generating cryptographic fingerprints of data that, when changed, indicate the data has been disturbed in some way. Cryptography uses various techniques to encrypt data—some of them very simplistic, such a simple substitution and transposition ciphers, and some of them quite complex, using techniques that make them almost mathematically impossible to decrypt. Encryption depends on strong algorithms and keys, discussed in the upcoming section, in order to be effective. Algorithms and Keys A cryptographic algorithm is a mathematical method or process used to transform data from plaintext into ciphertext. Most modern cryptographic algorithms are extremely complex and rely on advanced mathematical constructs or formulas. Algorithms are usually subject to scrutiny by experts in order to ensure their validity and discover any weaknesses that may expose the encryption method to compromise. It is outside of this scope of the CySA+ exam objectives to know the various algorithms properly used in cryptography, but some of the more common ones are the Advanced Encryption Standard (AES), Blowfish, Twofish, and the Rivest–Shamir–Adleman (RSA) algorithm. Encryption requires an algorithm and a key. The key portion of this process, since the algorithm is publicly known and tested, is what is kept confidential. Whereas the algorithm is a mathematical formula, the key is the unique piece of information the algorithm uses to encrypt and decrypt data. Keys can be created or generated by users or applications or other cryptographic mechanisms and may come in the form of passwords, PINs, or other unique sets of data. Except for public keys, keys are normally kept confidential. In simplistic cryptography, a key is used to encrypt data, in conjunction with the algorithm. When data is decrypted, the same or related key must be used. Without keys, encrypted data cannot be decrypted. Note: Robust encryption requires both strong algorithms and keys. Make sure you’re using cryptographically proven algorithms that have not shown any weaknesses, as well as a large key space. Remember that keys are strengthened by length and number of possible characters. Symmetric Cryptography You should be familiar with two general types of cryptography: symmetric and asymmetric. Symmetric cryptography is fairly simple to understand. It typically uses a single key to encrypt data, and the same key must be used to decrypt that data. Symmetric cryptography is sometimes also known as secret key or session key cryptography. It is most often used to encrypt a large amount of data, since it is very efficient. The problem with symmetric cryptography is that key exchange can be an issue. For a simple exchange of information, two individuals only need to ensure that each one has the correct key. However, think of using symmetric cryptography on a large-scale basis, where you have multiple users or entities. If you’re sharing the same data that everyone can access, you still need a single key. However, if certain individuals can have access to the data, but other individuals can’t, then you start getting into having many more keys that are only used between particular individuals. Additionally, key distribution is an issue because sending the key to decrypt confidential information over an unsecure means, such as e-mail, means that the key could be easily compromised, and someone who obtains the key can access the encrypted data. Symmetric algorithms are normally classified in two ways: as blocks or streams. A block algorithm encrypts chunks of plaintext in predefined blocks consisting of a number of bits. For example, you could encrypt a block of plaintext in a 64-bit block. Streaming cipher, on the other hand, encrypts data one bit at a time. There are many different block algorithms, such as 3DES, AES, Twofish, and Blowfish. The most popular streaming algorithm, used in both SSL and TLS as well as in wireless security protocols such as WEP, is the RC4 algorithm. Exam tip: You are not expected to recite or identify various encryption algorithms on the CySA+ exam, but you should be familiar with them from your earlier studies or experience in security, as they are a fundamental part of security knowledge. Asymmetric Cryptography Whereas symmetric cryptography uses a single key in its most simple form, asymmetric cryptography uses two keys. These keys are always generated in a pair; they are not the same key, but are closely related mathematically. These keys are normally referred to as a public/private key pair. One key is kept secure and confidential, and the other key is released for public knowledge. You know these keys are not identical; they are mathematically related. Therefore, what one key encrypts, the other key is able to decrypt. Using this key pair method, the paradigm for encryption and decryption changes somewhat. Anyone possessing the public key can encrypt a message to the owner of the key pair, and only that person who possesses the private key can decrypt it. This process makes it so one-way encryption to a particular individual is possible without worrying about key compromise, since anyone can have the public key but only the intended recipient of the message possesses the private key. When multiple people have key pairs, and all public keys are in possession of each party, anyone can encrypt a message to anyone else without having to worry about key exchange. Only authorized recipients can then decrypt messages. Using the public key to encrypt data for an intended recipient ensures confidentiality, since only the private key can decrypt it. However, if the opposite process were to occur, where a message was encrypted using the private key from an individual, this would not ensure confidentiality, since anyone holding the public key could decrypt it. In this scenario, confidentiality is not the goal. Nonrepudiation is a benefit of this process—only the person holding the private key could have encrypted the data since the private key is kept confidential. Anyone holding a copy of the public key can decrypt this data; therefore, authenticity, versus confidentiality, is the goal here. This is the basis of digital signatures. A disadvantage of public key cryptography, as asymmetric cryptography is often called, is that it’s not efficient at encrypting and decrypting a large amount data, because of the computational power required for encryption and decryption using public and private key pairs (since asymmetric algorithms require a great deal of computational power due to their complexity). However, key exchange is not an issue as it is with symmetric cryptography, since the public key can be freely given away to anyone who wants it without compromising confidentiality. The process of generating and issuing public/private key pairs, while ensuring that the identity of the individual or entity receiving these keys is authentic, as well as managing those keys throughout their lifecycle, is called a public key infrastructure (PKI). These keys are often issued to individuals by a trusted authority in the form of an electronic file called a digital certificate, which we’ll discuss in the upcoming section. As you’ll see later on when we discuss cryptographic applications, we can use the advantages of both symmetric and asymmetric cryptography to cancel out the disadvantages of each and create a system where key exchange is not an issue, confidentiality is maintained, the ability to encrypt large pieces of data is easy, and both integrity and authenticity can be ensured. Key Terms: Symmetric keys are the ones more often used to send and receive encrypted data back and forth between two entities. Asymmetric keys are primarily used for identification, authentication, secure key exchange, and nonrepudiation. Hashing Hashing is a cryptographic process, but it is not the same thing as encryption. Hashing is the process of running a hashing algorithm, such as MD5 or SHA, on a piece of plaintext and generating a finite-length piece of data, called a hash or message digest. This hash does not represent encrypted data that can be decrypted. Just like a fingerprint on a human being does not represent the entire human being, but it does, however, uniquely identify that person. A hash serves to uniquely identify the piece of data in the state it was in when the hash function was performed. The data can be variable length in nature; a Word document or a JPEG file or any other piece of data can be hashed. However, the hash itself that is produced is of finite length, meaning that it will only be a certain number of digits, depending on the hashing algorithm used.
For example, an MD5 hash is a 32-bit hexadecimal number, regardless of the length of plaintext used in its generation. Hashing is used to support the security goal of integrity. When the same hash function is performed against a piece of plaintext, it always produces the same hash value, as long as that document never changes. Since a hash is the resulting fingerprint uniquely identifying a piece of data, if that data changes at all, even by one bit, then the hash will change. Even changing a single letter or adding a space to a 50,000-page document would change the hash produced the next time the same hashing function is run against that document. Based on two different hashes produced by running the same algorithm against this document, you would know that that document has been altered in some way. Either intentionally by someone or accidentally in some way, possibly by disk or file corruption, faulty data transmission, and so on. In this way, the hashing process guarantees data integrity. Note that no cryptographic system is perfect; algorithms are often discovered to have flaws in them that could enable a malicious person to compromise them and be able to access or change data they are not otherwise authorized access. This is true with both symmetric and asymmetric algorithms, and it is also true with hashing algorithms. There have been both theoretical and demonstrable attacks on weak hashing algorithms where a collision (the instance of two different pieces of plaintext producing identical hash values, which should be theoretically impossible) could occur. Exam tip: Hashing is not the same thing as encryption, because it does not transform data into an unreadable form; it merely produces a fingerprint of the data in its current state. Hashing cannot be “decrypted” or reversed since there is no key to decrypt or reverse it. Cryptography Applications It’s helpful to discuss these topics as a refresher before you take the exam. Now that we’ve talked about the different forms of cryptography, such as symmetric, asymmetric, and hashing, we can briefly discuss how all of these work together and are applied to create secure solutions. Remember in its basic form, cryptography involves encrypting a piece of data with a key. Whoever is the intended recipient for that data, whether it’s over e-mail, using data at rest, or sending/receiving data in transit, must have the same key to decrypt it. One of the problems involved here is secure key exchange. As mentioned, symmetric key encryption is not particularly good with key exchange, and it doesn’t scale very well to large numbers of people or entities. This is where you can use a combination of symmetric, asymmetric, and hashing cryptography to ensure secure data transmission. Let’s look at the following scenario to illustrate this point. You need to encrypt data to send to a particular recipient. You also need to get them the key that will be used to decrypt this particular piece of data. Obviously, you should not use the same symmetric key over and over, because just like passwords, they can be compromised since an unauthorized person could conceivably intercept the key and be able to access all the encrypted data you ever send. So, you should use different keys every time you send encrypted data to an individual. Because you’re only using the key once, this is called a session key, and it’s used only for that particular communications session. Now take a look at key exchange. How do you get the other authorized individual the session key, especially when it may change? You can’t very well send it over unsecure means, such as e-mail or chat or even snail mail, since all those can be easily intercepted and read. This is where you can use public/private key cryptography to ensure secure data exchange. If both parties had a public/private key pair, you could try to use this to send data back and forth with the other party, but because asymmetric key cryptography does not handle bulk data very well, this might be inefficient. However, you could combine symmetric and asymmetric cryptography methods and encrypt the session or symmetric key with the other party’s public key and send it to them. Then, they can use their private key to decrypt the message containing the secret session key. Both parties could then use the session key to encrypt data throughout the remainder of the communications session. The scenario works very well to ensure confidentiality in secure key exchange. We can also add data integrity, sender authenticity, and nonrepudiation to the mix by adding hashing cryptography into this process. In addition to sending encrypted data back and forth between the two parties after they have encrypted and decrypted the session key with their public/private key pair, the user generating the session key could also create a hash of that key. That user could then encrypt that hash using their private key. They would then send that to the recipient. The recipient could decrypt that part of the message using the sender’s public key, so this would ensure sender authenticity. It would also ensure nonrepudiation since no one else could have sent that message because no one else has the private key. Once the receiver decrypts the hash, they could run the hashing function against the session key they received in a separate message to ensure that those hashes match. When they do match, this ensures data integrity. If they do not match, then there’s a possibility that the message was altered during transmission or otherwise compromised. Note that this sounds like an overly complicated process, but with most modern cryptography applications, all of this is completely transparent to the user, assuming they have been issued public and private keys. Most cryptography applications generate the session key without user intervention, so the user doesn’t even have to know what the session key actually was. The cryptography application will take care of all hashing, encryption, decryption, and digital signature processes. For the most part, this all happens so quickly during the initial parts of the communications session that the users never even realize it has occurred. The method we’ve just described using a combination of symmetric, asymmetric, and hashing cryptography has a wide variety of applications. This is how users communicate with secure banking sites, for example, or use secure e-mail. Managing Encryption in the Infrastructure How do you manage encryption in your organization? As with all other things, it starts with policy. The organization must develop a policy that covers the use of cryptography throughout the infrastructure.
The policy should address the following: - Instances where encryption is both required and not allowed (for example, for e-mailing sensitive information and off-site backups) - Requirements for encryption of data at rest and in transit - Required encryption strength and algorithms - Use of organizational-approved encryption products versus personal encryption - Key management Note that your encryption policy should go hand in hand with your data sensitivity policy. The data sensitivity policy should detail, based on stated sensitivity levels, which data should be encrypted, and under which circumstances. Once the policy is developed and approved, supporting procedures for encrypting data can be developed. The procedures should detail which cryptography applications users are allowed to use, how they use them, and what configuration settings (algorithms, key strength, and so on) must be used. One important aspect of managing encryption in the organization is key management. Keys must be centrally managed, balancing the requirements for nonrepudiation and ensuring that encrypted data is recoverable. Nonrepudiation, as a reminder, ensures that a user cannot deny that they took an action. If keys are centrally managed (meaning that administrators need to and should control access to them), it could be argued that a user did not act if it can be shown that a rogue administrator used a private key belonging to someone else for nefarious purposes. On the other hand, if a disgruntled user were to encrypt the only copy of highly sensitive or critical data, and then that user leaves, the data cannot be recovered. Key management must balance between these two requirements by carefully controlling access to keys, while at the same time ensuring the organization has a back door that can be used to decrypt critical data if absolutely necessary. To balance those two requirements, an effective key management policy provides for secure private key provisioning (key generation, issue, storage, and controlled access to the same), strict usage policies, and auditing key usage. Exam tip: Managing encryption in the infrastructure is critical; unmanaged encryption can lead to more security issues than it prevents. Ensure you have a solid policy regarding the use of encryption within the organization, and actively spell out the use of encryption for sensitive data as well as key management practices. Certificate Management As part of your overall key management strategy and supporting policies and procedures, managing digital certificates is a critical process. Digital certificates are issued to individuals for signing and encrypting e-mail as well as for accessing systems, so they are an important part of an organization’s identity and authentication management process. Since digital certificates contain cryptographic keys, protecting them and preventing their compromise is of utmost importance. Certificate Management Concepts From our earlier discussion on symmetric and asymmetric cryptography, you know that asymmetric cryptography involves two different keys: a public key and a private key. A trusted authority issues these public/private key pairs after validating the ID of the individual or entity requesting the keys. Digital certificates are electronic files that essentially contain not only the keys issued to an individual, but also the trusted path from the issuer. Certificates contain information about the issuer, the purpose for which the certificates are issued, and the expiration information for the certificate. Digital certificates can be issued for a variety of purposes, but the most common are for digital signatures and encryption purposes. Certificate Infrastructure An organization can maintain its own public key infrastructure, or it can use the PKI of an external organization, such as a commercial trusted entity that issues certificates. The requester of a digital certificate can be an individual user or another entity such as a corporation. The basic organization of a PKI consists of an entity called a Certificate Authority (CA). The CA generates a public/private key pair and issues a digital certificate to the requesting entity based on a positive identification of the entity requesting the certificate, as well as any other criteria they determine as critical. In the case of large organizations that may handle a large volume of requests, the portion of the process related to identity verification may be performed by another entity known as a Registration Authority (RA). The CA infrastructure is hierarchical, with a root CA server at the top. This is usually the first CA server created in the hierarchy, and it holds the root certificate. The root certificate may be self-generated, or it may be issued from yet another trusted CA, further extending the trusted path. In small organizations, the root CA may be the server that issues the actual digital certificates, but usually in larger organizations the root CA generates certificates for subordinate CA servers and is then taken offline to prevent its potential compromise. The root CA should be the most trusted certificate in the organization, and it generates a path of trust for any certificate it generates, including the subordinate CA servers. Therefore, if the root CA is compromised, it jeopardizes the trust path of all certificates it has ever generated. Subordinate CAs (also sometimes called intermediate CAs) handle the daily tasks of issuing certificates to individuals, entities, and even subordinate CA servers further downstream. Occasionally, organizations must trust other organizations’ certificates. This happens in the event of a business partnership, for example, where users from one organization must authenticate to resources in the other organization, so the certificates used to identify those users must be trusted. In that event, a cross-certificate trust is set up between the infrastructure of both organizations. Certificates are normally not valid for long periods of time; their life span is usually set to expire after a specified period, in accordance with the certificate policy of an organization. Certificates expire and become invalid after the specified period (typically two to three years) to prevent their eventual compromise or misuse. The certificate must then be renewed and reissued by the CA. Certificates can also be suspended or even revoked. A suspension occurs when the organization temporarily invalidates the certificate, due to some event (an investigation, for example). The certificate can be reinstated for use pending the outcome of the investigation. A certificate is revoked if it has been determined to have been misused or compromised in any way. In the event of a certificate revocation, a new certificate must be issued to the user or entity, if determined to be appropriate by the CA. The old certificate can no longer be used for authentication or digital signature purposes. The organization periodically publishes a certificate revocation list (CRL), which lists all certificates that have been suspended or revoked. Through a process that is fairly transparent to the user, certificates are checked through online means to ensure they are still valid. For example, when a user accesses a secure site and their browser checks the site’s certificate validity, it is compared against a CRL published online by the issuing CA. If the certificate is expired, suspended, or revoked, or if there is any other issue with the certificate, the user will likely get a warning informing them of this and asking if they still wish to trust the certificate and its authenticity. Unfortunately, many users click through this warning and expose themselves to a serious security vulnerability in the process by trusting an invalid certificate. As mentioned earlier, certificate management is a critical process in the overall key management and security infrastructure management program. Keys, root certificates, and the servers that generate them must be protected at all times. Exam tip: Be familiar with the basic certificate management infrastructure, including CAs, RAs, and subordinate CA servers. Active Defense For years, traditional cybersecurity theory taught that we should focus on perimeter defense only, and this would keep malicious entities out of our network. In the current threat landscape, we know this is no longer the case. For our defensive measures to be effective, we must be more proactive and adopt a defense-in-depth (also known as a layered defense) mentality. We must actively monitor for threats and constantly strive to strengthen our security posture. Active defense is a critical part of infrastructure management. Layered defense means we cannot just rely on perimeter defense; firewalls and border routers that filter solely on ports and protocols are not effective against malware, phishing attempts, compromised applications, malicious scripts hiding in allowed traffic, or, the most critical vulnerability of all, human beings. Active defense means constantly monitoring each layer of our infrastructure and determining new threats and vulnerabilities. At a minimum, the following are key areas that must be constantly monitored and strengthened: - Perimeter devices - Inbound and outbound traffic - Allowed applications and programs - Rogue devices - Privileges - Humans To actively monitor and strengthen our defenses, we must look at each of these areas, determine what vulnerabilities we have, what threats they may be exposed to, what impact the organization would face if those threats exercise those vulnerabilities, and what the likelihood of this happening is.
In other words, we need to determine what our risk is. To minimize this risk, active defense requires us to do the following: - Harden all network devices, servers, and hosts. - Ensure that we have a proactive patch management strategy. - Maintain up-to-date antimalware software and signatures. - Filter and examine inbound and outbound network traffic. - Ensure users understand their role in securing the organization’s assets. - Train users on how to deal with social engineering attacks. - Require the use of encryption for sensitive data. - Implement strict access controls based on the principle of least privilege. - Implement allowed/denied lists for applications, network traffic, websites, e-mail, and user privileges. - Actively monitor and log relevant events that occur on our infrastructure. - Perform threat modeling and vulnerability assessments. - Take steps to reduce risk whenever possible. Remember that active defense is more than just configuring security devices or mechanisms and leaving them to do their job. You must always be vigilant to verify that your security controls are working, as well as validate that those controls are the ones that are most effective for reducing risk and securing your infrastructure. Key Terms: Active defense, defense in depth, and layered defense are all terms that essentially mean the same thing—a focus on proactive defensive measures at various layers of the infrastructure. REVIEW Objective 2.1: Given a scenario, apply security solutions for infrastructure management In this objective, we focused on managing the organizational infrastructure, and we discussed several technical and managerial solutions enabling us to do so. We discussed the pros and cons of cloud-based versus on-premises infrastructure, as well as the importance of managing assets such as data, servers, hosts, network devices, and other equipment. You learned about the importance of segmentation, including how you can use physical and logical segmentation to protect highly sensitive assets. We pointed out the differences between system isolation and air-gapped separation and the scenarios in which you might use each. We also discussed the use of virtualization and the importance of a jump box in accessing sensitive segments and hosts. Network architecture describes how the infrastructure is designed and constructed; we looked at different aspects of physical and logical architecture, including physical layout, software-defined networking, virtual private cloud, and the use of a secure virtual private network implementation. Change management is an important part of managing your infrastructure, as unintended and potentially malicious changes in infrastructure can cause performance, function, interoperability, and security issues. We talked about the importance of the change control board and how changes are initiated, tested, approved, and implemented. Configuration management is a subset of change management, and while it does not involve major changes across infrastructure, it is critical to maintain a known-good baseline across all network devices and hosts. Any changes to those baselines should be carefully considered for incurring more risk to the network. Virtualization enables you to run discrete operating systems on top of physically abstracted hosts, through the use of hypervisors. Type I hypervisors serve as the physical machine operating system, and Type II hypervisors are merely applications that run on top of an existing server operating system. Hypervisors manage the interaction between the physical machine and the virtual machines, communicating with physical hardware, providing resources, and adding a layer of security to the overall virtual machine infrastructure. We discussed the virtual desktop infrastructure paradigm, which is essentially thin clients that access resources located on other more powerful machines, enabling you to save on costs of robust desktops and further secure your network by minimizing the amount of data that users run on their workstations. Containerization is similar to virtualization, except that software containers are abstracted from operating systems and use a containerization manager or runtime environment to communicate back and forth with the operating systems about the use of resources as well as security. Containerization protects both the application and operating system from each other’s inherent weaknesses. Containerization is an important part of locking down your hosts and infrastructure and preventing potentially compromised applications from enabling an attacker to do further damage to your network. We covered a great deal about the critical processes of identity and access management. We looked at the importance of privilege and account management. We also talked about authentication technologies such as multifactor authentication, single sign-on, and federated identities. We discussed access control models such as DAC, MAC, RBAC, and ABAC, and how each of them grants a different degree of privileges and access to resource owners, roles, and individuals. Organizations that use many different cloud services can benefit from a cloud access security broker (CASB) to serve the secure management layer between users and cloud services of all types. We also discussed the benefits of using a honeypot and honeynet to delay an attacker’s entry into the network while giving us time to analyze the attack, trace the attacker back to their point of origin, and alert the authorities. Honeypots and honeynets emulate vulnerable hosts and may distract an attacker long enough for administrators to engage in detective and preventative measures. They also increase our incident response capability. Monitoring and logging are two critical pieces of infrastructure management, and they cover a wide variety of topics throughout security. We discussed the importance of determining what the organization must monitor, at different levels, including applications, network devices, hosts, and users. You know that you must be very particular about what you log because logging generates a lot of data that takes up storage, and it can be difficult to sift through if it’s more than the analysts can handle. We looked at the importance of using automated tools, such as a SIEM system, to collect, aggregate, and assist in analysis with large volumes of log data. Additionally, we discussed the importance of managing cryptography in the organization. We discussed various cryptography fundamentals, including algorithms and keys, symmetric cryptography, asymmetric cryptography, and hashing. We also discussed how to use these different cryptography methods in our daily applications, such as secure e-mail and digital signatures. We also talked about the importance of managing digital certificates in the organization, including their expiration time and the certificate revocation list. Finally, we discussed the importance of active defense in the organization, beyond merely monitoring the perimeter. We talked about the different layers of defense that we should be paying attention to, including network devices, traffic, hosts, applications, and users. Each one of these presents different vulnerabilities that we must constantly assess and monitor for risk. We also discussed some of the various ways we can proactively strengthen each of these areas.
Join 4M+ learners. Unlock unlimited quizzes, wrong-answer tracking, flashcards + reminders, study guides, and 1-on-1 challenges.