As cloud computing has exploded in use and popularity, so has the need for skilled security professionals who have the specific knowledge that cloud computing demands. While many organizations have skilled security professionals and operations staff, much of the knowledge from a traditional data center is not sufficiently applicable to the unique challenges and facets of cloud computing. To bridge this gap, (ISC)² and the Cloud Security Alliance (CSA) collaborated to form the Certified Cloud Security Professional (CCSP) certification as a means of verifying the knowledge and skills of cloud security professionals and providing the education needed to provide adequate security in the cloud environment.

Why Get Certified?

Obtaining an industry standard certification that is widely respected and recognized will serve the career of any IT professional. With cloud computing growing rapidly and more organizations clamoring to leverage its potential, the CCSP will serve as an independent verification of your skills and understanding of these concepts to any employer or regulatory agency. The CCSP can benefit anyone working in IT security at any level, from starting security analysts up to an organization’s Chief Information Security Officer (CISO). While the CCSP will in many cases complement other security certifications such as the CISSP, it can also serve as a first or stand-alone certification.

How to Get Certified

The following steps and requirements for the CCSP were valid at the time of writing, but as with anything in the IT industry and its rapidly changing landscape, you should always verify directly with (ISC)² as to the most current requirements. The website for the CCSP can be found at https://www.isc2.org/ccsp.

The requirements to obtain the CCSP certification are as follows:

•   Experience   A candidate must have five years of full-time IT work experience. Within this five-year period, they must have three years minimum experience in IT security, and at least one year minimum in at least one of the CCSP domains. If a candidate has the CCSK certificate from the CSA, it can be substituted for the CCSP domain experience requirement, and the CISSP from (ISC)² can be used solely to fulfill the entire experience requirement for the CCSP. If you do not already have the required years of experience, you can still sit for the exam and become an Associate of (ISC)². As an Associate, you will have six years to earn the required experience and become a fully certified member.

•   Exam   The candidate must register for and pass the CCSP certification exam. Information about registration and the required fees can be found on the CCSP website. The exam is three hours in duration with 125 questions. A candidate can successfully pass the exam with a scaled score of 700 out of 1000 points.

•   Agree to the (ISC)² Code of Ethics   As part of a group of security professionals, anyone holding the CCSP agrees to be held to the highest standards of professionalism and ethics. For the Code of Ethics, see https://www.isc2.org/Ethics.

•   Endorsement   Upon meeting the experience requirements and successfully passing the exam, a candidate must have their application endorsed by a current (ISC)² certification holder. This endorsement must be done by someone who knows the candidate and can attest to the validity of their experience and professional credentials.

•   Maintenance   After being awarded the CCSP, a certification holder must complete specific continuing professional education (CPE) requirements and pay annual maintenance fees (AMFs). Refer to the official (ISC)² site for current information about both requirements.

CCSP Domains

The CCSP exam content is structured into six distinct but interrelated domains that cover the wide range of cloud-related security and operational concerns and issues. The weighting of the six domains is shown in Figure 1-1.

Figure 1-1   The six CCSP domains and their weightings

Domain 1: Cloud Concepts, Architecture, and Design

The Cloud Concepts, Architecture, and Design domain lays the foundation for a strong understanding of the basics of cloud computing. These building blocks are based on the ISO/IEC 17788 standard. The domain defines the different and crucial roles that individuals and other entities play within a cloud implementation, from the perspective of both the cloud service provider and the cloud service customer. It outlines the key characteristics of cloud computing, including on-demand self-service, broad network access, multitenancy, rapid elasticity and scalability, resource pooling, and measured service. It also introduces the key building blocks for a cloud environment, such as virtualization, storage, networks, and the underlying infrastructures that host and control them.

The domain covers the Cloud Reference Architecture, introducing cloud computing activities, cloud service capabilities, cloud service categories, cloud deployment models, and cross-cutting aspects of cloud computing that impact all areas of cloud implementations and deployments. The cloud computing activities are based on the ISO/IEC 17789 standard and include the key roles of the cloud service provider, cloud service customer, and cloud service partner, as well as the wide range of sub-roles encapsulated under each. The main cloud service capabilities, including the application, infrastructure, and platform service capabilities, are introduced and defined, as they form the basis of many of the cloud structures and models that are commonly used and understood. Following the cloud service capabilities, the major cloud service categories are introduced, including Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The cloud service categories can exist within different cloud deployment models as well, including public, private, hybrid, and community clouds. The last component of the Cloud Reference Architecture is a collection of cross-cutting aspects of cloud computing that are applicable to all cloud environments, regardless of the service category or deployment model. These cross-cutting aspects include interoperability, portability, reversibility, availability, security, privacy, resiliency, performance, governance, maintenance and versioning, service levels and service level agreements (SLAs), auditability, and regulation. Domain 1 also delves into the impact of related technologies on cloud computing, such as machine learning, artificial intelligence, blockchain, containers, and quantum computing.

While security concepts are important and central to any hosting environment, there are special considerations that make them applicable to cloud computing. What’s more, some security concepts are unique to cloud computing. As with any data center environment, security is vital in regard to network security, access control, data and media sanitation, cryptography, and virtualization. All of these are very similar to a traditional data center model, but the importance of cryptography is significantly higher in a cloud environment with multitenancy, as multiple customers are residing within the same pool of resources, as opposed to the isolation of a traditional data center. This also applies to the unique challenges with data and media sanitation, where access to and disposal of physical media are not feasible or practical in a cloud environment. With cloud computing being based on virtualization and the abstraction from physical hardware, the importance of hypervisor and container security presents new challenges compared to the traditional data center model. The common security threats facing cloud computing are introduced, as published by the Open Web Application Security Project (OWASP), along with a discussion about how security challenges apply to the different cloud categories (IaaS, PaaS, and SaaS) and any unique security challenges of each.

There are specific design requirements for secure cloud computing. While there is overlap with a traditional data center, certain aspects of a cloud environment require special considerations or methodologies. This applies to the cloud secure data lifecycle as well as the different approaches for business continuity and disaster recovery in a cloud environment. With these differing approaches and considerations, an organization must undertake a cost–benefit analysis that includes the operational changes, policy changes, regulatory challenges, and any configuration changes that would be necessary to move to a cloud environment—even whether the organization should consider moving to a cloud environment. The functional security requirements of cloud computing, including interoperability, portability, and vendor lock-in, are introduced.

Lastly, Domain 1 delves into certifications as a way of instilling trust in cloud systems. Because they do not host and control the entire environment, cloud customers are left looking for other means of verifying the security posture and operations of a cloud provider, and an easy and trustworthy means to do so is to look at independently tested and verified certifications. These certifications are based on published and well-understood standards and requirements; they serve as a means for trusting the security posture and controls of a cloud provider, as well as provide a common means for comparing different providers. Certifications can be done for entire environments and applications, or they can be focused on specific components and services. The Common Criteria is an international security standard that has been adopted with widespread use, whereas other certifications and standards such as FIPS 140-2 are focused on specific cryptographic modules, their security, and validations.

Domain 2: Cloud Data Security

The Cloud Data Security domain delves into the design, principles, and best practices for systems and applications to protect data, taking into account all types of systems, services, virtual machines, networks, and storage technologies within the hosting environment. Domain 2 begins with a discussion of the cloud data lifecycle, which shows how data flows from its creation through its disposal, and how it is handled through varied uses and activities while it remains within a system or application.

Each of the cloud categories (IaaS, PaaS, and SaaS) has different types and methodologies of storage associated with it and used by it. Domain 2 explains the volume and object storage types of IaaS, the structured and unstructured data types of PaaS, and the information and storage management as well as the content and file storage possibilities of SaaS. With each type of storage come unique and applicable security challenges, but strategies to address them are often similar and uniform. This includes strategies such as encryption and data loss prevention (DLP).

The technologies employed in a cloud environment to ensure data security are similar to those of a traditional data center; they just take on increased importance within a cloud due to multitenancy and virtualization technologies. The main data security approach used is encryption, including the importance of key management, hashing, masking, obfuscation, tokenization, and data de-identification. The exact use of specific technologies, including how they are used and to what extent, will be dependent on the type of data being processed or stored, along with its data classification and any regulatory or legal requirements for specific security controls or policies. Domain 2 also touches on some new and emerging technologies, such as homomorphic encryption, and the likely and important role they will play in the future of data security in general, and specifically within a cloud environment.

With any type of data security, the processes of data discovery and data classification are important. Data discovery involves finding and making value out of data that exists within a system or application, as well as ensuring that all data is known and has the proper security controls attached. Within a cloud environment, data discovery is even more complex and important because data is housed over disparate and diverse systems; data owners and cloud customers may not even have a good understanding of exactly where it resides. Once data is known, data classification is the process of determining the appropriate security controls and policies needed based on attributes of that data. The data classification rules can originate from corporate policy or from legal or regulatory requirements. Within a cloud environment, this is increasingly important due to possible exposure through multitenancy to unauthorized entities.

Many data classifications, especially those dealing with personally identifiable information (PII), are driven by appropriate jurisdictional requirements and controls. These originate from various privacy acts, which then dictate the necessary data discovery and classification processes required. The appropriate controls can then be mapped and applied to meet jurisdictional requirements; special subsets of PII, such as personal health information (PHI), require additional controls and special handling.

Two of the main approaches for protecting data are through data rights management (DRM) and information rights management (IRM). DRM applies to the protection of consumer media, whereas IRM applies on the system side to protecting information. These concepts and the specific tools that implement them can be used to set policy for auditing, expiration of access, policy control, protection, and support for many different applications and formats of data. Both allow for a much greater level of granularity and control than typical system or application data controls allow.

With any data policy, the concepts of retention, deletion, and archiving are extremely important. Many regulatory and legal requirements set explicit retention policies for data and especially for logs, and it is up to the organization and data owner to determine what policies and technologies are necessary for compliance. With any archiving system, it is crucial to ensure that archives are properly created, secured, and can be accessed and read for the duration of any retention policies or regulations. Clearing data for removal from a system must be done in a comprehensive and secure manner to ensure that it cannot be recovered and accessed later by unauthorized parties. A special category of data retention, the requirement of preserving data in specific formats or states for legal holding, is also introduced.

Lastly, a key component to data security is the logging of appropriate and detailed events from systems and applications. This includes both system- and application-level events and logs, and should be scoped to the specific type of data or application as to what kind of events and to what detail. Regulatory and legal requirements are also key factors in determining the types of events and detail required. This collection of events can be utilized for regulatory compliance, security oversight, and also for business intelligence and system resource utilization. Most organizations use a centralized collection and aggregation implementation for logs and analysis. As with any type of digital evidence and data, the proper mechanisms to preserve chain of custody and nonrepudiation are crucial for event logs and the systems that store and preserve them.

Domain 3: Cloud Platform and Infrastructure Security

A cloud environment consists of a physical infrastructure and a virtual infrastructure, and both carry with them unique security concerns and requirements. While cloud systems are built on virtualization and virtual components, underneath those virtualization layers is physical hardware and its security requirements, the same as with a traditional data center. This includes access to physical systems, such as the BIOS and hardware layers, as well as the software that hosts and maintains the virtualized environments on top of them. Any breach of security or controls on the physical layer could put all virtual hosts managed within it at risk as well. Security controls within a cloud environment apply to the standard set of resources: network and communications, storage, and computing. However, the use of virtualization also requires the consideration of security in regard to the management plane used to control the virtual machines. Domain 3 delves into the cloud-specific risks, the risks associated with virtualization, and the specific countermeasure strategies that can be employed.

With cloud computing used extensively to bridge organizations and provide services to large numbers and groups of users, identity and access management is a crucial concept for the Cloud Security Professional to be well versed in. Topics covered include the proper identification of users and the security mechanisms commonly employed to authenticate them and prove their identity to the satisfaction of either policy or regulatory requirements. Once identity has been proven, tight authorization controls are necessary to ensure users only access information for which they are authorized, and through the means they are authorized to do so. A commonly used approach with many cloud-based systems is federated identity, where users can authenticate through their own organization’s identity provider and then have a service provider accept those authentication tokens for access, rather than the users needing an account on the specific system.

Lastly, Domain 3 covers the concepts of business continuity and disaster recovery (BCDR). Although a cloud platform and its inherent redundancy can mitigate many typical outages that might impact a traditional data center, proper planning and analysis are still crucial. For applications that are completely within a cloud environment, interoperability and portability enable organizations to utilize other cloud providers or other offerings within the same cloud provider for BCDR strategies. Even applications still hosted in traditional data centers can use cloud offerings for BCDR, especially considering cloud services only incur costs when they are used, thus alleviating the need for standby hardware. For proper BCDR strategies to be implemented, the planning stages are crucial, but it is also imperative to conduct regular tests to ensure all components are still appropriate and feasible.

Domain 4: Cloud Application Security

Using cloud environments and cloud technologies is quickly gaining in popularity for their cost and flexibility. Cloud environments offer incredible efficiencies and ease in bringing online environments and virtual machines quickly for developers, and costs are only incurred while they are live and operating; the lead time and costs associated with procuring environments or test servers in a traditional data center are largely mitigated in a cloud environment. In order for optimal cloud development to be leveraged, especially with security in mind, the Cloud Security Professional and developers need a solid understanding of the realities of cloud environments, what is required to secure them, as well as the common threats and vulnerabilities facing a cloud.

While not unique to cloud hosting or development, several different types of application testing and scanning are discussed in Domain 4. These types consist of different approaches and views, and used in combination they allow for exhaustive and comprehensive testing of systems and applications. Dynamic application security testing (DAST) is considered “black-box” testing, which is done against live systems with no special or inside knowledge of them, whereas static application security testing (SAST) is done with full knowledge of system configurations, as well as access to source code, and is done against non-live systems. Penetration testing is done with the same approach and toolsets that attackers would use against systems to determine vulnerabilities, whereas runtime application self-protection (RASP) focuses on the capabilities of some systems and applications to self-protect and block or mitigate attacks as they occur.

Because most modern applications, especially those typically found in cloud environments, are built on components, services, and APIs that consume other services and data, the selection and verification of appropriate pieces that meet security requirements are essential. The old adage about the weakest link is certainly valid within this context, as any weakness of a single component could expose an entire application or system to threats and exploits. The same verification process and selection apply regardless of the source of the components, including commercial, open source, and community-sourced applications.

Domain 4 covers the software development lifecycle (SDLC) as it relates to a cloud environment, including an in-depth walkthrough of each phase, what it entails, and the key components to be addressed before moving to the next stage, as well as the cyclical nature of SDLC. The main threats and vulnerability concepts from the STRIDE and DREAD models are introduced, including their applicability to cloud environments.

On top of secure development concepts and methodologies, other commonly used technologies and paradigms within cloud computing are introduced. These include XML appliances, web application firewalls (WAFs), and systematic approaches such as sandboxing and application virtualization. Their importance in regard to cloud computing as well as their essential use and reliance on cryptography is also discussed. Lastly, Domain 4 covers the strategic approaches to identity and access management and building them into applications during development, including multifactor authentication technologies.

Domain 5: Cloud Security Operations

The operations domain begins with a discussion of planning for data centers, including both the physical and logical layers and technologies employed. This also incorporates how environmental concerns and needs are addressed along with physical requirements, including reliable and redundant access to cooling and electrical resources, as well as adequate protection from natural disasters and environmental issues.

Although cloud environments are mostly virtualized in the manner that most think, they still have the underlying physical environment and concerns of a traditional data center, even if those burdens are being handled and maintained by the cloud provider and are largely abstracted from view and concern of the users and cloud customers. The physical layer consists of the servers that are hosting the virtualized environment, as well as storage and network components. From the network perspective, all the concerns of a traditional data center are still present, such as firewalls, routing, and network-based intrusion protection and detection systems. Physical devices can be operated in a stand-alone or clustered configuration as well, depending on specific concerns for the environment or specific requirements and expectations. The physical environment also carries many of the same requirements in a cloud environment as servers would in a traditional data center, including patch management and versioning, access control, log collection and preservation, and auditing requirements. The physical environment, because it has a direct impact on the virtualized environment, requires extensive planning and scheduling for maintenance and management activities.

The logical environment carries the same burdens and requirements as the physical environment for the most part, but with a different focus on the systems and applications of the cloud customer, such as the actual virtual machines and network appliances used within cloud environments. These systems also require patch management and versioning strategies, but, depending on the cloud model used, the approach can differ widely from that of a traditional data center model. The logical environment will necessitate robust performance monitoring because it ties into the performance of the physical environment as well as how systems are dynamically balanced and how resources are allocated across physical systems to maintain optimal performance, because loads and demands constantly shift. Backup and recovery of logical systems are also covered.

Domain 5 covers extensively the components and concepts from ITIL, a set of best practices for IT service management used widely throughout the IT industry, as they form a comprehensive approach to operations management that can be applied to any system or application. Ten main components are addressed, including ones very familiar to all who work in IT systems and services, such as change management, configuration management, and information security management.

Another important part of operations is the collection and preservation of electronic records for use as digital evidence. These systems and programs need to be an integral part of an operational plan, and not something that’s only addressed when the need arises. Domain 5 covers these topics from an introductory operational standpoint, and the discussion is expanded to include a regulatory standpoint in Domain 6.

Domain 5 covers as an important aspect of operations the appropriate communication with relevant stakeholders. The stakeholders include those at all levels of an engagement or contract, such as venders, customers, partners, regulators, and any other potential stakeholders based on the particulars of the data, application, or system. Proper and efficient communication is important for fostering and maintaining strong relationships, and may be required specifically in regard to both frequency and level of detail, as required by contracts, SLAs, or regulations.

Lastly, Domain 5 covers the management of security operations within an organization. This encompasses the establishment of a security operations center to monitor both the technical and operational security requirements of the organization. With the establishment of security controls, it is imperative to implement mechanisms to monitor the controls and ensure they are not changed outside of official processes and approval, as well as ensuring they are working as designed and intended. Logging data is collected and maintained in a centralized manner to enable the correlation and monitoring of incidents. To cover all security events and respond to any incidents, a strong incident management process and personnel should be established and dedicated to security.

Domain 6: Legal, Risk, and Compliance

Domain 6 is focused on the legal and regulatory compliance requirements for IT systems, including how they are specifically related to cloud computing and its many unique facets. Cloud computing presents many unique risks and challenges because it often spans different regulatory or national borders. As such, it is subjected to many different requirements, which are sometimes in conflict with each other. This domain explores legally mandated controls from the perspective of multiple jurisdictions, as well as legal risks that are specific to cloud computing. The specific definitions and legal requirements for personal information and privacy as they relate to jurisdictional controls are covered, as well as the differences between contractual and regulated personal data protections.

Some of the most common legal impacts on any IT system or application are eDiscovery orders and requirements to produce records or data in response to a formal court order or request. The domain explores the overall concept of eDiscovery and digital forensics, especially as they relate to cloud computing and the specific challenges a cloud implementation represents. Many of the tools and processes for both areas that people are familiar with are not directly feasible in a cloud environment, because the cloud customer will not have the type of access required to perform data collection, so such requests must be addressed through contracts and other formal processes.

One of the most important aspects to IT security and compliance is the auditing process. Domain 6 delves into the various types of audits, their purposes, and the requirements from a regulatory perspective, as well as their specific impact on cloud computing. A major challenge with cloud computing is visibility and access into the underlying infrastructure on behalf of the cloud customer, and how cloud providers use audits and auditing reports to ensure confidence in security programs for multiple customers, without giving each customer access or having to do multiple infrastructure audits. Domain 6 covers extensively the standards surrounding auditing and certification, the commonly used auditing paradigms and reports, the applicable use and audience for each, and the proper identification of relevant stakeholders.

Risk management is also explored in depth in Domain 6, as well as its specific applications and concerns with regard to cloud computing. The introduction of cloud computing and the loss of direct control can become major facets of risk management within an organization and require special evaluation and understanding. The various processes and procedures for risk management, as well as different risk frameworks and assessment methodologies, are covered. This risk assessment process encompasses four stages: framing, assessing, responding, and monitoring. Each stage builds in sequence, starting with defining the process and risk categories, undertaking the assessment, determining appropriate responses or accepting any risks identified, and then monitoring those risks for future evolution or change in response strategies. Overall, risk can be accepted, avoided, transferred, or mitigated, or a combination of these approaches can be used.

Lastly, Domain 6 covers the various concerns and requirements for managing and scoping contracts for cloud hosting engagements. This includes guidance for selecting a cloud provider as well as the key components and issues that need to be addressed in the contract that are specific to cloud hosting and the concerns a cloud customer will have.

Introduction to IT Security

Although many candidates pursuing the CCSP certification will already hold other major security certifications, such as the CISSP, this is not a requirement. What follows is a brief introduction to some basic security concepts integral to all security professionals. Also included are brief introductions to the concepts of risk management and business continuity and disaster recovery (BCDR). If you have extensive experience in IT security or hold another major certification, feel free to skip this section and dive right into the next chapter, which covers the first domain for the exam. However, even if you are an experienced professional, you may find this information of value, especially if you are pursuing your first security certification.

Basic Security Concepts

The following are basic concepts of security that apply to all systems and applications, regardless of the purpose or technological details.

Least Privilege

The main driving principle in the world of IT security is that of “least privilege.” The foundation of the least privilege principle is that all access to systems, applications, or data should be granted to users in a manner that allows only the access that is explicitly required for their purposes and authorization. For example, users who have administrative privileges on a system should only use that level of access when it is absolutely necessary, and only for the specific functions and duration required. These users should operate with normal user access, and elevate to administrative-level access only when necessary. They should then return to user status immediately after performing the necessary functions.

Adhering to this best practice has multiple security and operational implications and benefits for an organization. First, it prevents a user operating for long durations of time with administrative access, where the likelihood of error or a mistaken command could have wide-reaching ramifications for a system. It also prevents the compromise of an account leading to extensive access to systems in instances where the elevation to administrative access is done without other independent verifications or requirements. In many instances, administrative access will be restricted to certain means of access, such as a requirement that users be on their corporate network, where other defensive security measures are in place to mitigate risk. It is also very common to require either multifactor authentication or separate and distinct credentials to elevate to administrative privileges. With additional credentials required, even if a user’s password were to be compromised, achieving administrative-level access would necessitate further compromise, where the likelihood of detection or prevention would be higher.

The same concept also applies to the service or system accounts utilized within an environment or application. Components such as web servers, application servers, databases, and so on, all run on the system as a specific account. Much like with user accounts, these system accounts should also run where only the minimal level of permissions required is assigned to them. This serves to separate and isolate processes on a system, and prevent them from accessing other data or processes without an explicit need to do so. For example, rather than processes being run as the “root” or “admin” account on a system, separate accounts specific to those applications or processes should be created and utilized. When processes are run under such accounts with wide access and privileges, if they were to be compromised, the malicious actor would automatically gain wide access to the system and any data or other processes contained or running on it.

While most associate privileges with the ability to read data, they also apply to the ability to update files on a system. Unless explicitly needed, services and processes should not be able to write or modify files on the file system. If this functionality is needed, then steps must be taken to limit where writing and updating can occur, and these actions should be as isolated and restricted as possible. No service should have the ability to update binaries or application configurations on a system to prevent Trojans or malware from being introduced and executed. An obvious and common exception is enabling a process to write log files to the system, but this also should be restricted to specific locations or files, and access should be enforced by file system permissions or other security settings specific to the environment.

The actual implementation of least privilege can be tricky in any environment. It is not possible to get to a point where a process has only the exact level of access needed, because a system is built on common libraries and configurations that all processes on the system will need to access or execute. The key is ensuring that sensitive data and functions are not exposed, as well as ensuring that a process cannot update or delete data or configurations without an explicit need and authorization. All access needs to be evaluated within an organization’s risk management processes, with specific access documented and approved before being granted.

Defense in Depth

The premise behind defense in depth is the use of multiple layers and different types of technologies and strategies to provide security. With multiple layers, a failure or vulnerability at any single point can possibly be mitigated or minimized through other security mechanisms and systems in place. While multiple layers of security will not totally eliminate any potential attacks or successful exploits, they can dramatically increase the difficulty of success, or make it far more likely for an attack to be discovered and prevented before it can be successful.

Many common strategies can be used together to constitute a defense-in-depth approach for a system or application. The obvious starting point is the security on the actual system or application itself. In front of the end point are other technologies such as firewalls, virtual private networks (VPNs), intrusion detection or prevention systems (IDSs/IPSs), vulnerability scans, physical security, logging and monitoring, and many other approaches and strategies. Based on scans and audits of the actual systems or applications, the selection of specific other strategies and technologies can be done with an eye toward specific mitigations and weaknesses, as well as the standard depth approach that data centers already employ.

Using multiple and independent devices and technologies for security also removes the interdependence of specific defenses and makes their successful exploit or bypassing far more difficult. For example, if an application uses a variety of software on a server for security, such as firewalls and virus scans, if the server itself has an administrative compromise, those processes could be disabled, stopped, or have configurations altered to make them useless, many times in a manner where detection of such changes is very difficult because the attacker will have full control over the server. By using appliances and components that are not running on the same server, as well as hardware-based implementations, the possibility of concurrent compromise is effectively eliminated. While this largely mitigates successful exploit from the outside, having separate devices or appliances that are managed by different teams and policies also mitigates prospects of insider threats.

Confidentiality, Integrity, Availability

The concepts of confidentiality, integrity, and availability are considered the base of IT security and the foundation of pretty much everything after that. While all three concepts work together, different types of data will have greater or lesser importance in each of the three areas depending on specific needs and regulatory requirements.

•   Confidentiality   The prevention of sensitive data from being accessed or viewed by any party other than those authorized. The level and degree of protection are typically based on the damage or consequences of the data being disclosed, either in regard to an organization’s reputation or possible regulatory or legal consequences from data disclosure to unauthorized parties. Security controls to promote or enforce confidentiality can be technological in nature, but also typically involve user training on policies, best practices, and safe handling.

•   Integrity   Maintaining the consistency and validity of data at all times within a system or application. Integrity ensures that the data has not been altered by any unauthorized parties, and that it has not been altered during transit. While access controls will be the main tactic used to prevent unauthorized modification, other technologies such as checksums are commonly used to verify that a file or data is still in its intended form and can immediately detect if any changes at all have been made to it.

•   Availability   Although availability may seem like an operational issue rather than a security issue, many aspects of security play a crucial role in availability. While ensuring that data is protected and valid is crucial in regard to confidentiality and integrity, respectively, if systems aren’t available to those authorized users who are dependent on them, they are of no organizational use. Security practices such as firewalls, intrusion protection systems, and the prevention of denial-of-service attacks are all key components of a security program. This also extends to the prevention of data loss and business loss through backup and recovery, business continuity, and disaster recovery.

Cryptography

Cryptography is the process of making information unreadable by unauthorized entities, while keeping it easily readable to those who are authorized to access it. Cryptography essentially takes data and makes it appear as completely random gibberish by using mathematical formulas and complex algorithms. The process of encrypting and decrypting data is based on the use of keys. Someone in possession of the keys can easily decrypt data, which can be virtually impossible to do without them. For the most part, all encryption can be broken with the appropriate amount of time and computational resources. The level of strength of the encryption is based on the time required to break it with available resources, technology, and knowledge. For example, although modern encryption systems are possible to break, doing so could take hundreds, if not thousands, of years, even with the required computing resources. Of course, technology, computing power, and mathematical breakthroughs are always occurring, so what is considered secure today could be vulnerable tomorrow. Cryptography and the use of keys falls into two categories: symmetric and asymmetric.

With a symmetric key implementation, the same key is used to encrypt and decrypt the data, so the key must be known and available on both sides from the onset. However, the use of a shared key also makes the processing of the encryption much faster than the asymmetric method. The use of symmetric encryption is typically confined to communications that are ongoing and established between two trusted parties, such as server-to-server communications and tunneling implementations that are used regularly or continuously.

With asymmetric (or public-key) encryption, different keys are used to encrypt and decrypt communications. While this is slower than symmetric encryption, it is the most commonly used method because parties are typically not known ahead of usage, such as when a user communicates with a secure website. Public-key encryption relies on the use of a pair of keys from each party, which are commonly known as the public key and the private key. The public key is exactly what it sounds like: publicly available and distributed or published by the user. The associated private key of the pair is always held securely and never distributed. When a secure communication is needed, the sending party can encrypt the data or communication using the public key of the recipient. Because the key is public, the initial communication channel does not need to be secure, which is not true with symmetric encryption. This is another major benefit of asymmetric encryption, which is commonly used with web and mobile applications. The receiving party then decrypts that data or communications channel using their private key, which is known only to them. The same method can be used to digitally sign data to authenticate the sender or originator, and to ensure that it has not been modified during transport. Public-key encryption systems form the basis for common security protocols such as TLS and SSL.

Certificates

A certificate forms the basis for proving identity and authenticating ownership of a public key to a specific user. The certificate contains information about the user, their organization, locality, and so on, and will be visible to the requesting party. To ensure validity and trust, certificates are digitally signed and issued commonly by a Certificate Authority (CA). In most instances, this will be a commercial vendor that is trusted by users and applications. For example, web browsers contain a number of “root” certificates of CAs that are considered trusted. These organizations have established and rigorous processes in place to ensure the identity and standards required to issue a trusted certificate. This third-party trust relationship is what allows communications to be secured and trusted between two parties that otherwise have no prior relationship or established credential exchanges. With both parties trusting the CA, they can be assured of the validity of each other.

While the use of prominent CAs is very common, within specific applications and uses, a smaller community may establish its own CA for its own purposes and users. For example, a university may establish its own CA for issuing certificates to all students and the systems that only its population of users access, alleviating the costs associated with procuring commercially verified certificates for the community. In these types of scenarios, rather than having to accept individually each certificate for a person or system, the user can choose to trust the root certificate of the CA. Thus, it works the same as those root certificates and all certificates signed under the CA’s authority that are commonly loaded in a browser.

If a user attempts to communicate with an entity that does not present a trusted certificate, the user will receive a warning in their browser or client that they are being presented with an untrusted certificate, or that the root authority is not a trusted issuer. Although the user has the option to override and accept the certificate, this should only ever be done when the user has very specific knowledge about why this warning has appeared, and they know themselves that the source can be trusted. This should never be done with systems that are used by the larger public community or with commercial sites.

Physical Security

While most security discussions in regard to IT systems are based on the protection of data through hardware and software solutions, the protection of physical assets and access is also paramount to IT security. Physical security is related to the actual defense of the building and location where IT resources and data are housed, as well as the physical equipment on which the data resides. The same defense-in-depth principles that are used with IT security also apply to physical security. With a physical structure, layered security such as fencing, surveillance, security guards, locked doors, hardened structures, and many other concepts all play a central role.

A breakdown of physical security or having insufficient physical security can lead to many problems with the loss of data or services for an organization. The most obvious is a loss of services due to the destruction of physical assets such as servers, storage systems, or network connectivity. A breach of physical security can also lead to someone using physical access to break into systems as they are running. However, even when systems have robust security for perimeter attacks and access, in many situations they are still susceptible to someone with physical access to the consoles and hardware, and thus to the systems themselves. Lastly, a lack of physical security can lead to theft of physical assets. While countermeasures can be employed to prevent a malicious actor from accessing systems over a network, if someone manages to steal hardware or storage systems with sensitive data on them, they would have access to extensive tools and methods for accessing the data, without the constraint of time or other mechanisms for disabling their access.

Risk Management

Risk management is the process of determining through analysis and testing the specific weaknesses, vulnerabilities, and risks associated with the data and systems in place for an organization. This also includes determining the appropriate mitigation efforts or accepting specific risks. Risks can come in many different forms, including physical threats, natural or environmental threats, software weaknesses and exploits, as well as malicious insider threats. All organizations must constantly evaluate risks to all systems, applications, and data, coupled with management’s appetite for risk and the level of risk they are willing to accept. Although it is not possible to totally eliminate all risks, a sound approach is to mitigate those risks that you can, and to minimize the likelihood of occurrence of the rest and any potential damage they could cause. Many decisions in risk management are also guided by specific requirements from regulatory or legal systems, as well as potential and specific penalties for data access or exposure as a result of a successful exploit.

Business Continuity and Disaster Recovery

BCDR is the planning for handling the sudden, unexpected, or catastrophic loss of systems or data for an organization. It encompasses several different aspects of IT operations, including the incorporation of resiliency within IT systems, the ability to recover from any loss, and the contingencies for handling major incidents or disasters that have a long recovery time.

The first major concept of BCDR is resiliency. Systems and processes should be implemented with sufficient redundancy and capacity to mitigate most types of threats or issues from the onset, preferably without noticeably affecting the users of the systems. This can be accomplished through having redundant systems and resources at all levels, ranging from power and cooling to system availability and personnel.

The second major concept of BCDR is the ability to recover from outages or system corruption. Within this context, recovery refers to outages where physical resources are likely still available and the loss comes from corruption or physical failure of portions of a system or environment. In this case, backups can be used to restore systems to a recent point. This will be defined by management as to what level of data loss they are willing to assume in the case of a failure or outage, and in most instances services can be restored quickly and within the same environment.

The last major concept is disaster recovery, where a catastrophic loss from a natural disaster, terrorist attack, fire, or other such major incident occurs. In this case, recovering from the widespread loss within an acceptable time is not feasible. In such instances, planning and preparation are required for moving to another hosting arrangement, where data and services can be recovered and returned to operational status within an acceptable timeframe. These efforts are to be considered a last resort to be used for a catastrophic outage, because the time, money, and resources required to make such a switch, and to return to normal services down the road, can be very substantial.

Chapter Review

This first chapter covered the requirements for obtaining the CCSP, as well as provided an overview of the domains that comprise the content for the examination. It also provided a brief introduction to some basic security concepts that will serve as the basis for the more in-depth and comprehensive discussions that follow.