Systems to Understand for the CISSP Exam

On the CISSP exam, you need to be able to recognize the techniques used to identify and fix vulnerabilities in systems and the techniques for security assessments and testing for the various types of systems.

Client-based systems

The types of design vulnerabilities often found on endpoints involve defects in client-side code that is present in browsers and applications. The defects most often found include these:

• Sensitive data left behind in the file system. Generally, this consists of temporary files and cache files, which may be accessible by other users and processes on the system.
• Unprotected local data. Local data stores may have loose permissions and lack encryption.
• Vulnerable applets. Many browsers and other client applications often employ applets for viewing documents and video files. Often, the applets themselves may have exploitable weaknesses.
• Unprotected or weakly protected communications. Data transmitted between the client and other systems may use weak encryption or use no encryption at all.
• Weak or nonexistent authentication. Authentication methods on the client, or between the client and server systems, may be unnecessarily weak. This permits an adversary to access the application, local data, or server data without first authenticating.

Other weaknesses may be present in client systems. For a more complete understanding of application weaknesses, consult OWASP.

Identifying weaknesses like the preceding examples will require one or more of the following techniques:

• Operating system examination
• Network sniffing
• Code review
• Manual testing and observation

Server-based systems

Design vulnerabilities found on servers fall into the following categories:

• Sensitive data left behind in the file system. Generally, this consists of temporary files and cache files, which may be accessible by other users and processes on the system.
• Unprotected local data. Local data stores may have loose permissions and also lack encryption.
• Unprotected or weakly protected communications. Data transmitted between the server and other systems (including clients) may use weak encryption or use no encryption at all.
• Weak or nonexistent authentication. Authentication methods on the server may be unnecessarily weak. This permits an adversary to access the application, local data, or server data without first authenticating.

These defects are similar to those in the client-based systems. This is because the terms client and server have only to do with perspective: in both cases, software is running on a system.

Database systems

Database management systems are nearly as complex as the operating systems on which they reside. Vulnerabilities in database management systems include these:

• Loose access permissions. Like applications and operating systems, database management systems have schemes of access controls that are often designed far too loosely, which permits more access to critical and sensitive information than is appropriate. Another aspect of loose access permissions is an excessive number of persons with privileged access. Finally, there can be failures to implement cryptography as an access control when appropriate.
• Excessive retention of sensitive data. Keeping sensitive data longer than necessary increases the impact of a security breach.
• Aggregation of personally identifiable information. The practice known as aggregation of data about citizens is a potentially risky undertaking that can result in an organization possessing sensitive personal information. Sometimes, this happens when an organization deposits historic data from various sources into a data warehouse, where this disparate sensitive data is brought together for the first time. The result is a gold mine or a time bomb, depending on how you look at it.

Database security defects can be identified through manual examination or automated tools. Mitigation may be as easy as changing access permissions or as complex as redesigning the database schema and related application software programs.

Large-scale parallel data systems

Large-scale parallel data systems are systems with large numbers of processors. The processors may either reside in one physical location or be geographically distributed. Vulnerabilities in these systems include

• Loose access permissions. Management interfaces or the processing systems themselves may have either default, easily guessed, or shared logon credentials that would permit an intruder to easily attack the system.
• Unprotected or weakly protected communications. Data transmitted between systems may be using either weak encryption or no encryption at all. This could enable an attacker to obtain sensitive data in transit or enough knowledge to compromise the system.

Security defects in parallel systems can be identified through manual examination and mitigated through either configuration changes or system design changes.

Distributed systems

Distributed systems are simply systems with components scattered throughout physical and logical space. Oftentimes, these components are owned and/or managed by different groups or organizations, sometimes in different countries. Some components may be privately used while others represent services available to the public (for example, Google Maps). Vulnerabilities in distributed systems include these:

• Loose access permissions. Individual components in a distributed system may have individual, separate access control systems, or there may be one overarching access control system for all of the distributed system’s components. Either way, there are too many opportunities for access permissions to be too loose, thereby enabling some subjects access to more data and functions than they need.
• Unprotected or weakly protected communications. Data transmitted between the server and other systems (including clients) may be using either weak encryption or no encryption at all.
• Weak security inheritance. What we mean here is that in a distributed system, one component having weak security may compromise the security of the entire system. For example, a publicly accessible component may have direct open access to other components, bypassing local controls in those other components.
• Lack of centralized security and control. A distributed system that is controlled by more than one organization often lacks overall oversight for security management and security operations.

This is especially true of peer-to-peer systems that are often run by end users on lightly managed or unmanaged endpoints.

• Critical paths. A critical path weakness is one where a system’s continued operation depends on the availability of a single component.

All of these weaknesses can also be present in simpler environments. These weaknesses and other defects can be detected through either the use of security scanning tools or manual techniques, and corrective actions taken to mitigate those defects.

High quality standards for cloud computing — for cloud service providers as well as organizations using cloud services — can be found at the Cloud Security Alliance and the European Network and Information Security Agency.

Cryptographic systems

Cryptographic systems are especially apt to contain vulnerabilities, for the simple reason that people focus on the cryptographic algorithm but fail to implement it properly. Like any powerful tool, if the operator doesn’t know how to use it, it can be useless at best and dangerous at its worst.

The ways in which a cryptographic system may be vulnerable include these:

• Use of outdated algorithm. Developers and engineers must be careful to select encryption algorithms that are robust. Furthermore, algorithms in use should be reviewed at least once per year to ensure they continue to be sufficient.
• Use of untested algorithm. Engineers sometimes make the mistake of either home-brewing their own cryptographic system or using one that is clearly insufficient. It’s best to use one of many publicly available cryptosystems that have stood the test of repeated scrutiny.
• Failure to encrypt encryption keys. A proper cryptosystem sometimes requires that encryption keys themselves be encrypted.
• Weak cryptographic keys. Choosing a great algorithm is all but undone if the initialization vector is too small, or too-short keys or too-simple keys are used.
• Insufficient protection of cryptographic keys. A cryptographic system is only as strong as the protection of its encryption keys. If too many people have access to keys, or if the keys are not sufficiently protected, an intruder may be able to compromise the system simply by stealing and using the keys. Separate encryption keys should be used for the data encryption key (DEK) used to encrypt/decrypt data and the key encryption key (KEK) used to encrypt/decrypt the DEK.

These and other vulnerabilities in cryptographic systems can be detected and mitigated through peer reviews of cryptosystems, assessments by qualified external parties, and the application of corrective actions to fix defects.

Industrial control systems

Industrial control systems (ICS) represent a wide variety of means for monitoring and controlling machinery of various kinds, including power generation, distribution, and consumption; natural gas and petroleum pipelines; municipal water, irrigation, and waste systems; traffic signals; manufacturing; and package distribution.

Weaknesses in industrial control systems include the following:

• Loose access permissions. Access to monitoring or controls of ICS’s are often set too loosely, thereby enabling some users or systems access to more data and control than they need.
• Failure to change default access credentials. All too often, organizations implement ICS components and fail to change the default administrative credentials on those components. This makes it far too easy for intruders to take over the ICS.
• Access from personally owned devices. In the name of convenience, some organizations permit personnel to control machinery from personally owned smartphones and tablets. This vastly increases the ICS’s attack surface and provides opportunities for intruders to access and control critical machinery.
• Lack of malware control. Many ICS’s lack security components that detect and block malware and other malicious activity, resulting in intruders having too easy a time getting into the ICS.
• Failure to air gap the ICS. Many organizations fail to air gap (isolate) the ICS from the rest of its corporate network, thereby enabling excessive opportunities for malware and intruders to access the ICS via a corporate network where users invite malware through phishing and other means.
• Failure to update ICS components. While the manufacturers of ICS components are notorious for failing to issue security patches, organizations are equally culpable in their failure to install these patches when they do arrive.

These vulnerabilities can be mitigated through a systematic process of establishing good controls, testing control effectiveness, and applying corrective action when controls are found to be ineffective.

Cloud-based systems

The U.S. National Institute of Standards and Technology (NIST) defines three cloud computing service models as follows:

• Software as a Service (SaaS): Customers are provided access to an application running on a cloud infrastructure. The application is accessible from various client devices and interfaces, but the customer has no knowledge of, and does not manage or control, the underlying cloud infrastructure. The customer may have access to limited user-specific application settings.
• Platform as a Service (PaaS): Customers can deploy supported applications onto the provider’s cloud infrastructure, but the customer has no knowledge of, and does not manage or control, the underlying cloud infrastructure. The customer has control over the deployed applications and limited configuration settings for the application-hosting environment.
• Infrastructure as a Service (IaaS): Customers can provision processing, storage, networks, and other computing resources and deploy and run operating systems and applications, but the customer has no knowledge of, and does not manage or control, the underlying cloud infrastructure. The customer has control over operating systems, storage, and deployed applications, as well as some networking components (for example, host firewalls).

NIST further defines four cloud computing deployment models as follows:

• Public: A cloud infrastructure that is open to use by the general public. It’s owned, managed, and operated by a third party (or parties) and exists on the cloud provider’s premises.
• Community: A cloud infrastructure that is used exclusively by a specific group of organizations.
• Private: A cloud infrastructure that is used exclusively by a single organization. It may be owned, managed, and operated by the organization or a third party (or a combination of both), and may exist on or off premises.
• Hybrid: A cloud infrastructure that is composed of two or more of the aforementioned deployment models, bound together by standardized or proprietary technology that enables data and application portability (for example, failover to a secondary data center for disaster recovery or content delivery networks across multiple clouds).

Major public cloud service providers such as Amazon Web Services, Microsoft Azure, Google Cloud Platform, and Oracle Cloud Platform provide customers not only with virtually unlimited compute and storage at scale, but also a depth and breadth of security capabilities that often exceeds the capabilities of the customers themselves. However, this does not mean that cloud-based systems are inherently secure. The shared responsibility model is used by public cloud service providers to clearly define which aspects of security the provider is responsible for, and which aspects the customer is responsible for. SaaS models place the most responsibility on the cloud service provider, typically including securing the following:

• Applications and data
• Runtime and middleware
• Servers, virtualization, and operating systems
• Storage and networking
• Physical data center

However, the customer is always ultimately responsible for the security and privacy of its data. Additionally, identity and access management (IAM) is typically the customer’s responsibility.

In a PaaS model, the customer is typically responsible for the security of its applications and data, as well as IAM, among others.

In an IaaS model, the customer is typically responsible for the security of its applications and data, runtime and middleware, and operating systems. The cloud service provider is typically responsible for the security of networking and the data center (although cloud service providers generally do not provide firewalls). Virtualization, server, and storage security may be managed by either the cloud service provider or customer.

The Cloud Security Alliance (CSA) publishes the Cloud Controls Matrix, which provides a framework for information security that is specifically designed for the cloud industry.

Internet of Things

The security of Internet of Things (IoT) devices and systems is a rapidly evolving area of information security. IoT sensors and devices collect large amounts of both potentially sensitive data and seemingly innocuous data. However, under certain circumstances practically any data that is collected can be used for nefarious purposes, security must be a critical design consideration for IoT devices and systems. This includes not only securing the data stored on the systems, but also how the data is collected, transmitted, processed, and used. There are many networking and communications protocols commonly used in IoT devices, including the following:

• IPv6 over Low power Wireless Personal Area Networks (6LoWPAN)
• 5G
• Wi-Fi
• Bluetooth Mesh and Bluetooth Low-Energy (BLE)
• Thread
• Zigbee, and many others

The security of these various protocols and their implementations must also be carefully considered in the design of secure IoT devices and systems.