On-demand self-service

By design, cloud service providers allow customers to procure and provision cloud resources by anyone who wants or needs them. On-demand self-service means that a customer can request, set up, and use cloud services in an automated fashion and without interacting with another human. On-demand self-service allows full cloud usage without approval from your Manager, Legal Team, or Finance.

The upside to on-demand self-service is the tremendous ease of procurement. Cloud computing is designed to be easy to get started with; if you can pay for it, you can use it. Though self-service is helpful for productivity, security teams should be aware of the risks that come with it, and implement policies and procedures to help govern the use of cloud services.

Broad network access

Cloud resources should be accessible by any authorized cloud user with an Internet connection. The principle behind this characteristic is that cloud computing should make resources and data ubiquitous and easily accessed when and where they’re required.

Mature cloud offerings make accessing their resources device-agnostic, allowing cloud users the ability to connect to their cloud services from a variety of endpoint devices that include laptops, desktops, tablets, and even smartphones. From a security standpoint, this ability gives customers deploying cloud applications some additional considerations, as cloud computing extends their data to a variety of devices, that may or may not be within the enterprise’s control. For this reason, many companies need to examine their mobile device management policies when moving to the cloud.

Bring your own device (BYOD) has become increasingly common and means that companies are allowing employees to connect their own smartphones, tablets, and laptops to corporate systems. BYOD has the benefit of enabling broad access to cloud systems from many devices, but adds concerns regarding device management and secure access methods. Fortunately, cloud computing mitigates some risk of BYOD because it encourages users to store their data in cloud storage rather than on their devices. Even still, be mindful of your company’s BYOD policies and consider how cloud systems might impact them.

Resource pooling

One of the most critical concepts in cloud computing, resource pooling occurs when a CSP groups (or pools) its cloud resources for shared use between multiple cloud customers. What resource pooling allows the CSP to do is scale resources up and down, on a per-customer basis, as each customer’s resource needs increase or decrease. CSPs can have many thousands of servers, networking devices, and other resources available; pooling allows them to efficiently manage those resources between customers, with minimal waste.

Resource pooling works closely with rapid elasticity to provide cloud customers a dynamic set of compute, storage, and network resources that are allocated based on each customer’s needs.

Rapid elasticity

At the core of cloud computing, rapid elasticity allows a cloud customer to quickly obtain additional cloud resources as the user’s needs require. Think of a retail website during the Black Friday or Cyber Monday shopping frenzy. Rapid elasticity allows that website to seamlessly accommodate a sudden spike in traffic, without the cloud customer’s intervention, by automatically scaling and provisioning (referred to as auto-scaling and auto-provisioning) resource based on load.

It’s not uncommon for many businesses to have peak-hours or peak-seasons, during which their resource utilization may drastically increase. Outside of these peaks, many businesses can see their resource demands plummet for long periods of time. Rapid elasticity and resource pooling work together to give cloud customers as much compute, storage, and networking power as needed, and nothing more. This capability is important because cloud also leverages a pay-as-you-use model.

Measured service

Cloud computing makes it exceedingly easy for cloud customers to monitor, measure, control, and report on their resource usage. Measured service works in a similar manner to how you might have a measured (or metered) use for your water or electric bill. Similar to these home utilities, CSPs charge customers only for the resources that they use. As such, providing measured services that allows full transparency between a CSP and cloud customer is paramount.

Cloud service provider

The following are key roles and activities performed by the cloud service provider:

• Cloud service operations manager: Oversees and manages the operation and performance of cloud services provided to customers.
• Technical account manager: Provides account support and high-level technical guidance to cloud customers.

Cloud service customer

The following are key roles and activities performed by the cloud service customer:

• Cloud architect: Evaluates cloud technologies and services and designs the overall architecture of the cloud deployment to meet organizational requirements.
• Cloud service user: Uses services provided by the CSP.
• Cloud service administrator: Configures, manages, and monitors the use of cloud services.

Cloud service partner

The following are key roles and activities performed by the cloud service partner:

• Cloud auditor: Performs audits of cloud environments and provides audit reports.
• Cloud service broker: Provides a marketplace for approved services, manages contracting, and securely integrates cloud services with on-prem applications.

Infrastructure as a service (IaaS)

Infrastructure as a service, or IaaS, is in many ways what people first think of when they hear cloud computing. It’s the service category where the CSP provides compute, storage, and networking resources and the customer has the greatest level of control and customization over those resources. Think of things like virtual machines and storage containers or buckets — that’s IaaS.

NIST 800-145 describes IaaS as “the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).”

IaaS key characteristics and benefits include

• Cost efficiency: By using the IaaS service model, customers do not need to spend money on buying and managing hardware up front or as the need for additional resources grow. With IaaS, customers are able to trade Capital Expenditure (CapEx) for Operational Expenditure (OpEx). In addition, customers also benefit from the cloud provider paying for and managing physical security of the datacenters.
• Availability and reliability: Infrastructure as a service provides customers with load balancing and redundancy across vast infrastructures that can span many regions or even countries. These vast infrastructures provide customers with assurance that their resources will be highly available and resilient against availability threats (DDoS and others).
• Scalability: With IaaS service models, additional resources can be procured, provisioned, and expanded quickly and with ease to support growing demand. Whereas on-premise solutions would require a customer to purchase and set up new servers to support increased utilization, IaaS allows automatic scaling when necessary.

Platform as a service (PaaS)

Platform as a service, or PaaS, sits on top of the IaaS layer in the cloud stack and begins to shift control (and responsibility) over resources away from the cloud customer and back to the cloud provider. In PaaS offerings, the user is generally building their own application or solution using prepackaged libraries and features provided by the cloud provider. Having the infrastructure and development environment taken care of by the CSP allows the customer to focus on development rather than managing servers, virtual machines, and other granular resources. As a result of PaaS offerings, the barrier to entry for software development continues to fall. Developers, large and small, are able to spend less time and money developing infrastructures and managing resources and more time on being innovative.

You may be familiar with terms like up the stack and down the stack from TCP/IP discussions, and they carry over to the cloud computing world. In cloud, these terms refer to the way the three cloud service categories stack on top of each other to provide full cloud functionality. IaaS sits at the bottom of the stack and moves up to PaaS, followed by SaaS at the top.

NIST 800-145 describes PaaS as “the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.”

Though PaaS customers inherit many of the same benefits of IaaS, some will be unique to PaaS.

PaaS key characteristics and benefits include

• Cost efficiency: Similar to IaaS, the PaaS service category offers cost savings because application developers pay only for the systems and resources they use. As customers progress through the development cycle, they can scale up or down with ease and without incurring unnecessary costs.
• Flexibility: Developers receive a great deal of flexibility during their application development lifecycle when they use PaaS cloud offerings. Within a given cloud environment, developers can often easily switch between operating systems and software versions to suit their needs. Many cloud providers provide open source environments and applications for developers, which prevents vendor lock-in and affords them the ease of moving between environments, platforms, and even cloud providers.
• Simplicity: With the underlying infrastructure and operating systems being managed by the cloud provider, hardware and software upgrades and system patches are handled for the developer. Upgrading to the latest version of software is commonly as simple as clicking a few buttons, which minimizes downtime and lets developers focus on creating their applications rather than managing systems.
• Ease of access: Being cloud-based means that development platforms and tools are easily accessed from anywhere in the world. This ease of access makes it incredibly easy for global development teams to collaborate on projects, as opposed to on-prem development platforms that may require out of band collaboration (like emailing updated files or using less reliable technologies like shared drives).

Software as a service (SaaS)

Software as a service, or SaaS, sits at the top of the cloud stack and provides fully operational software applications to the customer. SaaS moves the majority of resource management to the cloud provider, allowing the end-user to simply use the provided application to meet their needs. Examples of SaaS offerings include Google Docs, Dropbox, and DocuSign; these cloud-based applications require little to no configuration by the customer.

NIST 800-145 describes SaaS as “the capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user specific application configuration settings.”

SaaS customers inherit many of the previously mentioned benefits from IaaS and PaaS, but SaaS does have some unique features and benefits.

SaaS key characteristics and benefits include

• Cost efficiency: You’re probably seeing a theme here: Cloud helps customers cut costs. Similar to IaaS and PaaS, software as a service helps customers manage costs by eliminating the need for system administrators and dedicated hardware and software. For SaaS applications, customers only need a device to access the given application and an Internet connection.
• Licensing: With SaaS, customers effectively lease or borrow licenses as they use software. Leasing eliminates the need for customers to purchase full sets of licenses, which may go underutilized for long periods of time. Cloud providers, due to the scale of their environments, are able to take advantage of friendlier licensing fees from third-party vendors, and some of those savings are able to be realized by the end user.
• Standardization: By nature, cloud applications are standardized regardless of who’s accessing or where they’re accessing the application from. From an application standpoint, standardization helps ensure consistent experiences from one user to another and makes sure that all users are using the latest and greatest software versions, with little to no action taken by the customer.

Public

According to NIST SP 800-145, “[public] cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.” In English, public cloud is a set of computing services that can be accessed by anyone willing and able to pay for them.

With enterprise offerings from tech giants like Google, Amazon, and Microsoft — as well as Apple’s consumer cloud product, iCloud — public cloud is typically what consumers think of when they think about “the cloud.”

Public cloud benefits and uses include

• Easy to set up and manage: In public cloud deployments, the cloud service provider owns and operates the infrastructure, which means the customer isn’t responsible to manage infrastructure like data center facilities, networking hardware, and operational expenses. In addition, public cloud commonly offers streamlined access to resources through easy-to-use interfaces.
• Highly scalable resources: Public clouds typically have vast infrastructures that are ready and able to handle heavy workloads.
• Resource efficiency and cost-effective: Customers don’t have to worry about wasted resources, as public clouds automatically scale a customer’s resources up or down, based on their usage and bill them only for what they use. Unused resources from one customer can be used (and paid for) by another.

Private

According to NIST SP 800-145, “[private] cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.” In other words, private cloud offers similar services to those offered by public cloud, but private cloud can only be accessed by members of a single organization.

Private cloud is sometimes referred to as an internal cloud and is often used for legal, compliance, or security purposes. In certain highly regulated industries, customers often want the convenience and features that cloud provides, without their data being mixed (or comingling) with other customers’ data.

Private cloud benefits and uses include

• Increased ownership: With private clouds, the customer/user is the same party that owns and operates it. As such, private clouds give users a greater level of ownership and the ability to control everything about it. One common example is for customers with data location requirements — for example, a bank may have regulations that require its data remains within the European Union (EU). The standard way to satisfy this requirement has historically been to build or use a private cloud that allows that bank to only let data travel to data centers within the EU. Newer offerings from some public cloud infrastructures are now allowing these customers to meet these types of requirements without managing their own private cloud.
• High level of system and data control: Similar to the point mentioned in the previous bullet, private clouds give customers increased control over all resources. Private cloud customers can control things like bandwidth, system patching, and software/application availability, whereas these things are often only controlled by the CSP in public clouds.

Community

According to NIST SP 800-145, “[community] cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.” Think of community clouds as private clouds that are extended to a limited set of related organizations.

Community clouds are common in highly regulated industries. Government customers, for example, will often seek out the moniker GovCloud for assurance that only government data resides within a given cloud. While the term GovCloud may entail a bit of marketing, it’s a great example of the intent of the community cloud deployment model.

Community cloud benefits typically mirror those of public clouds. The added benefit comes from all members of the cloud user base sharing a common set of privacy, security, or compliance requirements. A community of users with the same (or highly similar) set of requirements can ensure that the cloud meets their requirements exactly.

Hybrid

According to NIST SP 800-145, “[hybrid] cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).” Simply put, hybrid cloud consists of some combination of public, private, and/or community cloud features.

As you may expect, hybrid cloud models attempt to bring the best of multiple worlds together; when using a hybrid cloud deployment, customers are generally seeking public cloud features and scalability with private or community cloud control.

Hybrid cloud benefits include

• Re-use of existing infrastructure and technology: Many customers want the benefits and features that public clouds provide, but they may already have an expensive infrastructure that’s up and running. A hybrid cloud allows customers to reap the benefits of public clouds while still utilizing their private clouds, as necessary. A hybrid cloud is sometimes a stepping stone for customers dipping their toe in the cloud waters, but there are often compliance, legal, or other business reasons for customers maintaining private cloud (or on-premises) infrastructure.
• Control over critical or sensitive systems: With hybrid cloud deployment models, customers are able to keep data that they are most concerned about in their private cloud, while moving less sensitive data to a public cloud. By sharing characteristics of public and private (or community) clouds, customers are able to maintain a high level of control and ownership without missing out on the benefits that public cloud provides.
• Disaster recovery support: One common use case for hybrid cloud is in supporting disaster recovery. Customers already running on a fully functional private cloud can benefit from the redundancy and reliability assurance that many public clouds provide. Customers can continue to use their private clouds as normal, but can configure their resources to failover to the public cloud in the event of a disaster. Because the public cloud would be used only in case of emergency, customers will usually incur little to no costs under normal circumstances (because you’re billed for what you use).

Interoperability

Interoperability is the ability for two or more systems to seamlessly work together by sharing information and using that information as necessary. In cloud systems, interoperability ensures that cloud services can understand standard data formats, APIs, configurations, and identification and authorization mechanisms so that these cloud-based systems are able to work with the organization’s existing technologies or even other clouds.

Portability and reversibility

Portability is the ease with which a party can move or reuse application or service components. Portability means that the service provider, underlying platform, operating system, API structure, format of data, or other factors do not present obstacles to seamlessly moving services from one solution to another.

Vendor lock-in occurs when any of these factors prevents a customer from moving from one cloud provider to another. Portability ensures that an organization is able to easily move between cloud providers or cloud deployment models (from public to private cloud, for example), and host some or all of those components in different environments. Highly interoperable systems provide customers flexibility as their needs change and also tend to keep cloud providers on their toes because customers are able to migrate at any time.

Availability

As discussed in Chapter 2, availability is one of the pillars of information security and one of the greatest considerations for organizations moving to the cloud. In many ways, the availability of resources and systems can make or break a cloud provider’s success and their reputation. When an organization relies on a cloud provider for their infrastructure, platforms, or applications, the cloud provider’s failure to deliver can mean substantial impact to the customer’s business. It’s not uncommon for CSPs to commit to 99.9 percent (or higher) availability. Failure to meet this commitment can result in penalties, loss of customers, and degraded brand reputation.

Resiliency

Resiliency measures the ability of a cloud provider to continue providing fully functioning services in the event of disruption. In many ways, resiliency goes hand in hand with availability. As you learn in Chapter 2, disaster recovery and business continuity planning are two key reasons users move to the cloud. Given that CSPs commonly have incredibly vast amounts of resources (servers, storage, networking equipment, bandwidth, and so on), it’s easier for cloud-based systems to be highly redundant and resilient in the event of natural disaster, power failure, or other equipment outage. Potential cloud adopters should pay close attention to any resiliency commitments made in their contracts or SLAs.

Security and privacy

Security is often the top concern for potential cloud customers, and it can either be a major selling point or a barrier to adoption for any given CSP. For many organizations — especially smaller ones — moving to the cloud can significantly increase security capabilities, because large scale cloud providers are able to provide world-class security controls that some organizations either cannot afford or are not yet sophisticated enough to implement.

Many cloud providers will publicly state their baseline levels of security or share some of their most marketable security features, but they will typically fall short of listing specific security controls to avoid arming potential attackers with sensitive information that could lead them to compromising the CSP’s security. In general, the most mature cloud providers are able to offer just about any security feature a customer could want, but additional security can often incur additional costs.

Not all cloud providers are created equally, and not all are able to meet the same levels of security standards. As cloud security professionals, it’s important to not only understand what security features are available, but also which ones are enabled by default. Too many cloud breaches occur because users falsely assume that an advertised security feature is enabled without their action.

If security is concern 1A, privacy is often 1B for potential users of cloud services. The very nature of cloud means that customers’ data is not always 100 percent within their control. Remember that the global nature of cloud means that a customer’s data may exist in multiple locations around the world. Privacy laws and regulations are increasingly influencing CSPs’ behavior, but no universal or international set of laws or directives currently consistently enforce privacy standards from one CSP to another, across different geographical locations. Depending on a customer’s privacy needs, it may be necessary to negotiate specific requirements as part of contracts or SLAs. (I cover SLAs later in the section “Service Level Agreements [SLA].)

Performance

It might go without saying that cloud computing and high performance are intertwined. Few customers will select or stay with a cloud provider that can’t deliver consistently strong performance. The largest CSPs have been in a bit of an “arms race” for years and are releasing stronger, better, and faster compute, memory, and storage capabilities at least every year.

In the upcoming section “Impact of related technologies,” you can see some key emerging applications for cloud computing that rely on high performance.

Governance

Governance relates to the policies, procedures, roles, and responsibilities in place to ensure security, privacy, resiliency, and performance. Governance is required at the start of any cloud migration and continues through the entire lifetime of a cloud deployment. In other words, governance activities are ongoing from day zero until cloud services are no longer being used.

Many cloud providers make governance easier than it is with traditional data center models because they offer tools to generate reports and monitor relevant statistics and metrics. The ability to schedule and automate reporting enhances governance activities and allows customers to focus on their mission.

Service-Level Agreements (SLAs)

In cloud, a service-level agreement (SLA) is an agreement between a cloud service provider and cloud customer that identifies the minimum level of service that must be maintained.

SLAs can include anything from amount of uptime to minimum response time to customer service inquiries. In many ways, an SLA serves as a warranty when a customer moves to the cloud. Similar to the warranty you get when purchasing a car, a cloud SLA gives customers assurance that they are getting what they expect and provides remedies (like fee reimbursement) if those agreed upon expectations aren’t met.

Here are some examples of things you should look for in a Service Level Agreement. Keep in mind that this list is not exhaustive:

• Availability: How much uptime is the CSP committing to? The standard is 99.9 percent or more, but pay attention to the period of time over which this guarantee is made.
• Performance: What are standard and maximum response times?
• Data ownership: Who owns your data once it’s in the cloud?
• Location of the data: What geographical locations might your data be located? The location may have privacy or compliance implications.
• Portability of the data: Are you able to move your data to another provider whenever you choose?
• Data security and privacy: Is data encrypted at rest? In transit? Who is permitted to access your data?
• Disaster recovery: What solutions and processes are in place for DR and backup?

Maintenance and versioning

The cloud service category being used will determine just how much consideration a customer must give to maintenance and versioning. With SaaS offerings, the CSP is responsible for just about all patching, maintenance, and versioning. Moving up the stack to PaaS and even more with IaaS, the customer has increasing responsibility for these actions.

Maintenance and versioning responsibilities should be agreed upon and understood early on, and they should be specifically called out in contracts and SLAs. With versioning, customers should be aware of what ability the CSP grants for rolling back to previous versions, and what responsibility they have to upgrade (or rollback) from one version to another.

Regulatory compliance

Regulatory compliance is the requirement for an organization to meet or satisfy regulations, guidelines, policies, and laws relevant to its business. A company failing to meet these requirements may face financial penalties, legal action, or even termination of business operations. As a result, regulatory compliance is a major concern for potential cloud users, and it’s important to note that the nature of cloud means satisfying compliance is a shared responsibility between a CSP and its customer.

Having worked on compliance teams at two of the largest cloud providers, I can say firsthand that cloud customers often struggle to understand what is commonly called the Shared Responsibility Model. As a CCSP, it’s paramount that you understand what your organization is responsible for securing and what your CSP or customer is responsible for. The most transparent CSPs will provide substantial documentation to support your understanding of the Shared Responsibility Model; if this documentation is not readily available, it’s best to ask for sufficient details.

Many, many regulations and laws impact technology. Some key examples that impact cloud-based environments include Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry Data Security Standard (PCI DSS), Service Organization Controls (SOC), the Federal Information Security Management Act (FISMA), and the Federal Risk and Authorization Management Program (FedRAMP), among others. It’s important that cloud security professionals understand how their industry influences which of these or other regulations they are required to satisfy.

Auditability

As a CCSP candidate, auditability in the cloud is an area you should pay very close attention to because of the Shared Responsibility Model. Because customers do not have full control over the cloud environment the way they would in a traditional data center model, it’s important that they’re able to audit their compliance with various regulatory requirements, as well as monitor important user and system activity.

The CSP is responsible for providing logging and auditing capabilities to the customer and demonstrating that they are capturing and reporting on any events the customer may wish to audit. Most mature cloud service providers offer a wealth of auditing and reporting capabilities, but it is up to the customer to use them in accordance with their compliance obligations.

Data at rest

Data at rest refers to data that is stored on a system or device, and not actively being read, written to, transmitted, or processed. This data may be spreadsheets on a hard drive, documents stored on tape, or entire databases in a cloud-based backup.

If you think about data at rest, it’s essentially information that can be a sitting duck for attackers, if not properly protected. Large pools of data staying in one location are generally at greater risk than data that’s moving from point A to point B. Because data at rest is often exposed for long periods of time, you should pay special attention to encryption as a control against unauthorized access. Options include encrypting sensitive files prior to storage and/or encrypting the entire storage volume or drive itself.

Not all cloud data at rest solutions are created equal. Some CSPs enable encryption by default for all data at rest, while others require various levels of configuration to enable it. As a cloud security professional, make sure you refer to the CSP’s product configuration guides to understand what’s already done and what is your responsibility.

Data in transit

Data in transit (or data in motion) refers to data that is actively being transmitted across a network or between multiple networks. Data in transit can include data moving from a user’s laptop across the Internet to a cloud provider, data traveling between systems or services within a cloud environment, or any data traversing a trusted or untrusted network. Common examples of data in transit are email traffic, file downloads from the Internet, and commands sent over SSH.

The threats posed to data in transit differ from those of data at rest, and it’s important to understand how you can use cryptography protect data without causing unintended consequences. Some pitfalls to watch out for are interoperability challenges caused by improper or incompatible encryption between systems, as well as performance impacts due to the processing requirements that encryption adds.

Pitfalls aside, sensitive cloud data in transit should be protected with encryption. Encryption helps ensure that data makes it from the user to the cloud (and back) without unauthorized access or compromised integrity. Some key technologies for encrypting data in transit include SSL, TLS (including HTTPS), and VPNs. These technologies are covered in Chapter 2.

Data in use

Data in use is sometimes forgotten, but this third state of digital data refers to information that is actively being processed by an application. Data in use can be data that is being created, modified, or even erased; any data that is neither stagnant nor being transmitted from one point to another can generally be considered data in use.

Data in use is synonymous with data that resides in a system’s Random Access Memory (RAM) or cache memory.

Data in use can be very tricky to secure. For one, data in the cloud can generally be processed only in unencrypted form; indexing, searching, and analysis of encrypted data is anywhere from impractical to impossible. Even scarier, data in use often contains very sensitive data; things like encryption keys and certificates are commonly found in memory. Because of the limitations associated with encryption, cloud security professionals typically look to other security controls to manage risks to data in use.

Key management

Just as important as it is to encrypt sensitive data, it’s paramount that you have a method for generating, issuing, organizing, and managing encryption keys. A cloud security architect will generally assess an organization’s use of encryption and identify their needs for key management. When using public cloud, customers often want to use their own key management system as an added layer of privacy and control over their data. In doing so, customers remove dependency on the cloud provider to manage their keys and also avoid potential vendor lock-in due to using a CSP’s proprietary key management platform.

Most large scale cloud providers offer key management services. It’s important that you understand how using those services may impact the security or portability of your data. Don’t forget to check contractual terms, SLAs, and config guides associated with encryption and key management.

Customers commonly use two key management services (KMSs) with cloud environments:

• Remote KMS: A remote key management service is one that is owned, operated, and maintained on premises by the customer. This configuration gives the customer complete control over who can generate or access cryptographic keys. Something to keep in mind with remote KMS is that it requires constant network connectivity between the cloud customer and CSP; disruptions in connectivity may prevent encryption and decryption functions from operating.
• Client-side KMS: Client-side KMS is provided by the CSP, but the customer generates, holds, and manages the keys. Client-side KMS again gives the customer a great deal of control over their key management, but assures better integration with the cloud environment.

Account provisioning and deprovisioning

Access management begins and ends with account provision and deprovisioning, and both are critical pillars of IAM. Account provisioning deals with creating user accounts and enabling access to cloud resources, whereas deprovisioning is the opposite and entails removing users and their access.

Account provisioning should be designed to create an efficient account creation process that is consistent and easily monitored and audited. The goal is to have a standardized process by which new users are created and/or new access is granted for existing users.

Account deprovisioning is perhaps even more important, from a security perspective. Account deprovisioning is the process of removing access and disabling an account when a user no longer requires access to cloud resources. The easy use case is when someone leaves a company, but keep in mind that account deprovisioning also comes into play when users change roles or job functions; a user’s required access to resources would likely change if they moved from the IT department to a role in Finance, for example. Deprovisioning is all about enforcing the principle of least privilege and minimizing risk associated with unnecessary access routes.

Directory services

Directory services are another key pillar of IAM and security, both in traditional IT settings and in the cloud. A directory service is a relational hierarchy of cloud identities that manages the storage and processing of information and acts as the single point through which cloud users can locate and access cloud resources. In the on-prem world, Active Directory is a key example of a directory service, which offers authentication, policy enforcement, and other services for an enterprise organization.

While many traditional directory services providers were slow to migrate to the cloud, several third-party directory services offerings have become popular in cloud environments. Most major CSPs now offer cloud-native directory services, many of which can integrate with a customer’s existing on-prem directory services (like Active Directory). Within cloud environments, directory services play a huge role in establishing and maintaining a trusted source for organizational identities and access policies.

Cloud directory services use protocols like Lightweight Directory Access Protocol (LDAP) and Security Assertion Markup Language (SAML) to link user identities to cloud applications.

Privileged access management

Users with the highest privileges (root, admin, and so on) present the most risk to that system, both because of insider risk and due to the impact should those accounts be compromised by a malicious actor outside the company. Privileged access management includes the technologies and processes involved in managing the entire lifecycle of these sensitive accounts: from provisioning to deprovisioning, and everything in between.

While monitoring all accounts for suspicious activity is best practice, this monitoring is extremely important for privileged users accounts. Cloud security professionals should track and monitor successful and failed authentications and include information like date, time, user identifier, and location (or IP) of access. Effective privileged access management should seek to implement ad-hoc privileged access (for example, elevated privileges only when needed) rather than long-term privileged access and provide continuous visibility of privileged access to cloud resources.

Data breaches

Data breaches are what most people might think of when discussing security compromises or hacks. In short, a data breach occurs when an unauthorized party gains access to confidential or protected data; this access can include any type of data, with the key factor being the fact that it is viewed, retrieved, or otherwise accessed by someone who shouldn’t have access.

Data breaches are a top concern of cloud customers particularly because customers are inherently trusting a third party to protect their data as well as (or hopefully better than) they would themselves. It’s incredibly important that customers understand that securing cloud data and preventing breaches involves shared responsibility between a CSP and the customer (even though the customer is ultimately accountable for the security of their data). It’s essential that cloud providers are transparent about what they do to prevent data breaches and what a customer must do. Separately, it’s important to remember that not all data breaches can be fully prevented (as hard as we try!), and so CSPs and cloud customers must be diligent about detecting and responding to security incidents to minimize their impact.

Misconfiguration and inadequate change control

A leading cause of data breaches is the misconfiguration of systems and services that leaves data vulnerable to attack. Default credentials and settings, excessive permissions, and lack of basic security hygiene are some key examples of misconfiguration. A famous example of misconfiguration occurred in 2017 when a misconfigured AWS S3 storage bucket led to the exposure of more than 100 million American’s private information that was owned by Experian.

Inadequate change control often contributes to misconfiguration in cloud environments. Whereas traditional IT environments often rely on lengthy processes and several stages of review to implement changes, cloud environments are far more dynamic and tend to automate basic and common tasks.

Cloud customers that don’t understand the differences between legacy change control and cloud-based change control are prone to missing critical things and failing to effectively configure settings in a timely fashion. While CSPs are often expected to provide support in the form of configuration guides, best practices, and so on, proper configuration of settings and adequate change control are ultimately the responsibility of the cloud customer.

Lack of cloud security architecture and strategy

Customers moving their IT infrastructure or sensitive data to the cloud should have an established cloud security architecture as well as a well-defined strategy for managing the security of their cloud environment and data. It’s important that customers understand the differences between cloud and traditional IT so that they are prepared to adequately address the unique threats that cloud computing poses. Unfortunately, many companies embark on their cloud journeys without skilled cloud security professionals (like you!) to help with these unique challenges. It is paramount that customers consider how they will migrate, what security controls and configurations fit their business needs, and what processes they will follow to consistently manage the security of their data in the cloud.

Insufficient identity, credential, access, and key management

Identity and Access Management (IAM) and key management are hugely important topics in any type of environment; this set of tools and processes allows users to control and monitor who can access data and systems. In the cloud, these topics get even more critical because of the shared responsibilities between CSPs and customers. I discuss IAM and key management throughout the course of this book, but for now, remember that these issues present a great deal of risk to cloud customers who don’t prepare effectively.

Consider the following when you’re looking to mitigate threats associated with IAM and key management:

• Use strong passwords and multifactor authentication to protect access to sensitive data.
• Understand your cloud provider’s IAM services and examine the tradeoffs between on-prem and cloud-native IAM solutions. Along these lines, you should understand your CSP’s ability to support federated identity and what that means for your organization.
• Practice least privilege and allow only the minimal amount of access for cloud users.
• Remove unused credentials to minimize exposure through unnecessary accounts.
• Develop a robust key management plan that includes key rotation (automatic, where feasible).

While the cloud provider has responsibility to enable cloud customers to meet their security objectives (like IAM and key management), it is ultimately the cloud customer’s responsibility to implement and monitor these controls. Neglecting to do so is often the reason for data breaches and other cloud security incidents.

Account hijacking

Account hijacking occurs when an unauthorized party gains access to privileged accounts. This threat exists in traditional IT models, but the implications in cloud environments are massive. If not properly protected, the data in cloud accounts can be stolen, deleted, or made unavailable to legitimate users. Successful account hijacking can yield complete control over an account, along with the services and data associated with it.

Stolen credentials, phishing attacks, and weak security controls can all contribute to an account hijacking. As such, it is important that CSPs and cloud customers build security awareness training that highlights these risks, as well as employ a defense-in-depth approach to preventing and detecting potential account compromises.

Insider threat

Insider threat is the potential for someone who has or has had legitimate system or data access to intentionally or unintentionally compromise a system, data, or organization. Insiders can include employees, contractors, partners, or other trusted parties that have been granted a level of access based on trust. Because of this trust, insiders often do not have to go through multiple layers of security to affect the confidentiality, integrity, or availability of data.

An often forgotten insider is the former employee who may have detailed knowledge of an organization’s systems and processes and understand how to circumvent protections that are in place. Even worse, a disgruntled former employee may have even set up backdoor access that they can leverage to access sensitive information even after leaving a company. When building out your insider threat capabilities, make sure to account for anyone who has knowledge or access greater than that of the general public.

Aside from many of the security controls discussed throughout this book (encryption, least privilege access, and so on), it’s important to consider the fact that insiders pose a great deal of unintentional risk to information and systems. A comprehensive security awareness training is important to mitigate this risk and minimize the occurrence of accidental data leakage or system outages.

Insecure interfaces and APIs

Application Programming Interfaces, or APIs, are used to expose a cloud provider’s capabilities to the cloud customer. APIs, along with user interfaces, allow customers to take advantage of the products, services, and features that a CSP operates. As they often have public IP addresses, APIs are typically the most exposed part of a cloud environment, and if not protected, pose a great deal of risk to the data stored within the cloud. It’s important that CSPs design these APIs with security in mind.

Weak control plane

The control plane is the part of the cloud environment that carries information necessary to establish and control the flow of data through the cloud; it enables management of the cloud’s infrastructure and data security. A good control plane should enable a cloud architect to manage all aspects of migration, storage, and security in the cloud. The threat that a weak control plane poses is that it creates blind spots in the customer’s security awareness that could result in data corruption or loss. It is a CSP’s responsibility to provide thorough security controls for customers to meet their security and compliance obligations. Consequently, it is up to the cloud customer to determine whether or not a CSP provides an adequate control plane to meet these obligations.

Metastructure and applistructure failures

You’ve heard of infrastructure, but metastructure and applistructure are related terms you should know. Metastructure is the set of mechanisms that connects the infrastructure layer to the applications and data being used. Metastructure enables and supports infrastructure management and configuration, and is typically the line of demarcation between the cloud provider and customer. Applistructure includes the applications that are deployed in the cloud and the underlying services used to build them.

Failures to metastructure and applistructure often involve weak API security or poorly implemented and exposed APIs, in general. APIs are generally used to access all kinds of data within the cloud, including highly sensitive data. It is up to the CSP to be diligent in their design and testing of APIs, whereas cloud customers must take steps to understand how their existing applications must be implemented in the cloud securely.

Limited cloud usage visibility

Limited cloud usage visibility happens when an organization is unable to monitor and analyze their cloud service usage. In other words, the threat here is that the people responsible for securing their cloud deployment don’t possess the ability to determine whether users’ activities are safe or harmful.

Cloud security professionals need to understand and be able to monitor the use of authorized cloud services and applications, as well as monitor for the use of unauthorized services and applications. The latter, referred to as Shadow IT, occurs when cloud users access and use cloud systems and resources that have not been authorized by their organization. A common example of Shadow IT is when a company’s staff uses unapproved cloud services (like Dropbox or Box) to manage company data. Employees may find these tools easy and convenient to use, but their use of unsanctioned software can make it really hard for their organization to effectively secure sensitive data. The threat of Shadow IT is common in cloud environments because of the on-demand self-service aspect of cloud. The risk here is that unauthorized resources may present specific vulnerabilities that the organization simply isn’t checking for.

Cloud Access Security Brokers (CASBs) can play a role in controlling which applications are in use and analyzing the activities within a cloud environment. Web Application Firewalls (WAFs) are also helpful in providing awareness of connections to cloud services, including analysis of activities and identification of malicious trends. In addition to technical controls, cloud providers and cloud customers must both be vigilant in implementing training and awareness programs that inform employees on how to properly use authorized cloud resources.

Abuse and nefarious use of cloud services

The scale and anonymity offered by the cloud provides an attractive option for malicious actors looking to do harm. These bad actors can do things like launch DDoS attacks, brute-force attacks, or distribute email spam. Another attack that has grown in recent years involves a malicious actor compromising a customer’s cloud environment and using their resources to mine cryptocurrency, while the customer pays the bill. It’s incumbent upon both the CSP and the cloud customer to monitor their resources and quickly identify signs of abuse. A mature incident response process is also critical to stemming loses or damage associated with misuse of cloud services.

IaaS security concerns

Due to the nature of IaaS architectures and services, virtualization and hypervisors play a key role as attack vectors, though other security considerations do exist.

Some key IaaS security considerations include

• Colocation and multitenancy: With on-premise solutions, organizations can be certain that their data is physically separate from anyone else’s data. In cloud environments, an organization must assume that they share resources with dozens, hundreds, or even thousands of other organizations. While it is up to the CSP to logically (or virtually) segregate one tenant’s data from another, it is the responsibility of each customer to protect the data they deploy in accordance with any regulatory or contractual requirements they may have.
• Virtual machine (VM) attacks: Active VMs are susceptible to the same security vulnerabilities as physical servers — and whether active or offline, a compromised VM poses a threat to other VMs that share the same server. This risk is because VMs that reside on the same physical machine share memory, storage, hypervisor access, and other hardware and software resources. The CSP is responsible for preventing, detecting, and responding to malicious activity between VMs.
• Hypervisor attacks: Compromising the hypervisor can be considered a gold mine for attackers. An exploited hypervisor can yield access to the physical server, all tenant virtual machines, and any hosted applications.
• Network security: Cloud environments rely on virtual networks that contain virtual switch software that control the movement of traffic within the cloud. These switches, if not properly configured and secured, can be vulnerable to layer 2 attacks, such as ARP poisoning. Because customers do not have the level of control over the network as they would with on-prem solutions, it is up to the CSP to tightly control network activity and be transparent with the customer (within reason) about how their data is protected.
• Denial of service (DoS) attacks: DoS attacks are a threat in both cloud environments and traditional data center environments. The nature of cloud and the sheer size of many CSPs may make it more challenging to take down a cloud service, but it’s certainly not impossible. If one cloud customer is experiencing a DoS attack, it can potentially impact other customers on the same hypervisor. Even though hypervisors have mechanisms to prevent a single host from consuming 100 percent of a system’s resources, if a single host consumes enough resources, it can leave insufficient compute, memory, and networking for other hosts.

PaaS security concerns

PaaS services being platform-based, rather than infrastructure-based, present a different set of security considerations.

Some key PaaS security considerations include

• Resource isolation: PaaS tenants generally have extremely little to no system-level access of the underlying environment. This assures resource isolation, and prevents a single customer from impacting multiple customers with infrastructure- or platform-level configurations. If a customer is able to change underlying configurations within the environment, it can negatively impact other customers that share resources, as well as make it very hard for the CSP to effectively manage and secure the environment.
• User permissions: It’s important that each tenant in the PaaS environment is able to manage their user permissions independently. That is, each instance of the PaaS offering should allow the respective cloud customer to configure their own user-level permissions.
• User access management: Cloud security professionals must evaluate their organization’s business needs and determine what access model works for them in the cloud. It’s crucial that you find the balance between allowing quick user provisioning with proper and secure authentication and authorization. Cloud environments offer a great deal of power to automate these tasks, thanks to elasticity and autoscaling.
• Malware, backdoors, and other nasty threats: Autoscaling means that anytime there’s a backdoor or other piece of malware within a cloud environment, it can grow and scale automatically without intervention from a cloud security professional. In addition, these threats can start with one PaaS customer and rapidly expand to other customers, if not detected and eradicated. It’s up to the CSP to continuously monitor for new vulnerabilities and exploits, and it’s the customer’s job to use secure coding best-practices.

SaaS security concerns

SaaS presents very different security concerns from its infrastructure and platform peers. While most of these concerns will fall on the CSP, it’s important that you are familiar with some key SaaS security considerations:

• Data comingling: The characteristic of multitenancy means that multiple customers share the same cloud infrastructure. In SaaS deployments, many customers are likely to store their data in applications with shared servers, storage, or even potentially shared databases. This comingling of data means that any cross-site scripting (XSS), SQL injections, or other vulnerabilities can expose not one but potentially all customers in the shared SaaS environment. It’s up to the CSP to ensure that customer data is segregated as much as possible, through use of encryption and other technologies. In addition, the CSP is responsible for conducting vulnerability scans and penetration testing to identify and fix weaknesses before they are exploited.
• Data access policies: When evaluating a SaaS solution, you should carefully consider your organization’s existing data access policies and evaluate how well they align with the cloud provider’s capabilities. Again, multitenancy means that several customers are sharing the same resources — so the level of data access configuration and customization is potentially limited. As a cloud security professional, you want to be sure that your company’s data is not only protected from other cloud customers, but you’ll also want to ensure that you’re able to control access between different users within your own company (separate access for developers and HR, for example).
• Web application security: SaaS applications, by nature, are connected to the Internet and are meant to be available at all times. This interconnection means that they are constantly vulnerable to attacks and compromise. Because cloud applications hang their hat on high availability, any exploit that takes down a web app can have a great impact on a cloud customer. Imagine if an organization’s cloud-based payroll systems suddenly went down on pay day!

ISO/IEC 27001

ISO/IEC 27001 (often referred to as just ISO 27001) is an information security standard published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). ISO 27001 is the most popular standard within the ISO/IEC 27000 family of standards and is focused on the creation and maintenance of an Information Security Management System (ISMS), which ISO defines as “a systematic approach to managing sensitive company information so that it remains secure.” Said a different way, an ISMS is a set of people, processes, and technologies that manages the overall security of a company’s systems and data, and this standard describes the overall components of an ISMS. Organizations that complete an audit demonstrating that they meet ISO 27001 requirements may be certified by an ISO accredited body.

The most recent version of ISO 27001 was published in 2013 (YES! That long ago!). ISO 27001:2013 contains 114 controls across 14 domains (or clauses). The domains include

• Information security policies
• Organization of information security
• Human resource security
• Asset management
• Access control
• Cryptography
• Physical and environmental security
• Operations security
• Communications security
• System acquisition, development, and maintenance
• Supplier relationships
• Information security incident management
• Information security aspects of business continuity management
• Compliance

Although ISO 27001 is a globally recognized standard, it is not cloud specific. As such, it cannot be relied on for exhaustive and holistic examination of cloud-specific security risks and controls. Despite this fact, its overall importance and global popularity means that it will likely be relied upon by CSPs and customers as a general security benchmark.

ISO/IEC 27002

ISO 27002 is titled “Security Techniques — Code of practice for information security controls.” This standard, last revised in 2013, builds on ISO 27001 by providing guidelines for organizations to select, implement, and manage security controls based on their own security risk profile. In other words, ISO 27002 becomes more prescriptive than its counterpart by providing best practice recommendations to those responsible for implementing or maintaining an ISMS.

The security controls in ISO/IEC 27001 and 27002 are the same. The only difference is that ISO 27002 explains the controls in greater detail.

ISO/IEC 27017 and ISO/IEC 27018

ISO 27017 and ISO 27018 are more recent security Standards from ISO, and both are cloud-specific.

• ISO 27017:2015 builds on ISO 27002 and provides guidelines for security controls related to the provision and use of cloud services. The standard offers security controls and implementation guidance for both CSPs and cloud service customers.
• ISO 27018:2019 is focused on the protection of personally identifiable information (PII) in the cloud and again builds on the existing set of controls within the previously discussed standards, but adds privacy-related controls to the mix.

SOC 1, SOC 2, and SOC 3

If you’ve worked in traditional data center environments for a long time, you might recall that the Statement on Auditing Standards Number 70 (or SAS 70) was for many years the go-to standard for auditing and certifying the security of datacenter and other service providers — even though it was initially intended for financial and accounting auditing. In 2011, SAS 70 was replaced by the more comprehensive Service Organization Controls (SOC) reporting framework, which gives organizations the flexibility to be audited based on the needs of the particular organization.

Do not confuse SOC with SOX (Sarbanes-Oxley). SOX compliance helps protect investors from fraudulent financial reporting by corporations, and is completely separate from SOC compliance. The acronyms are very similar, and I’ve seen the two mixed up more than a few times.

The three commonly used types of SOC audits and reports are aptly named SOC 1, SOC 2, and SOC 3. All three reports align with the standards outlined in Statement on Standards for Attestation Engagements (SSAE) 18, which replaced SSAE 16 in 2017; the SSAE is managed by the American Institute of Certified Public Accountants (AICPA). Here are some additional details:

• SOC 1 is a control report that focuses strictly on an organization’s financial statements and a service organization’s controls that can impact a customer’s financial statements. A service organization that performs payroll or credit card processing would require a SOC 1 report.
• SOC 2 reports evaluate an organization based on AICPA’s five “Trust Services Principles: Security, Availability, Processing Integrity, Confidentiality, and Privacy.” These reports are of extreme interest to cloud security professionals, both at cloud providers and as consumers of cloud services.
• SOC 3 takes the same information contained in a SOC 2 report and abstracts all the sensitive details. In essence, a SOC 3 report will indicate whether an organization has demonstrated each of the five Trust Services principles, but will not disclose specifics. SOC 3 reports are intended to be publicly available, whereas SOC 2 reports are tightly controlled, due to the sensitivity of their contents.

Payment Card Industry Data Security Standard (PCI DSS)

The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary security standard established by Visa, MasterCard, American Express, Discover, and JCB International in 2004. PCI DSS governs all organizations that accept, store, or transmit cardholder data and/or sensitive authentication data. The Standard has six goals that generally align with security best practices:

• Build and maintain a secure network and systems
• Protect cardholder data
• Maintain a vulnerability management program
• Implement strong access control measures
• Regularly monitor and test networks
• Maintain an information security policy

The six goals are broken down into 12 requirements, which are broken down further into more than 200 security controls that specify security requirements that organizations must meet to fulfill their PCI DSS compliance obligations. The 12 PCI DSS requirements are:

• Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
• Requirement 3: Protect stored cardholder data.
• Requirement 4: Encrypt transmission of cardholder data across open, public networks.
• Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs.
• Requirement 6: Develop and maintain secure systems and applications.
• Requirement 7: Restrict access to cardholder data by business need to know.
• Requirement 8: Identify and authenticate access to system components.
• Requirement 9: Restrict physical access to cardholder data.
• Requirement 10: Track and monitor all access to network resources and cardholder data.
• Requirement 11: Regularly test security systems and processes.
• Requirement 12: Maintain a policy that addresses information security for all personnel.

Due to the technical and detail-oriented approach taken by PCI-DSS, many organizations outside of the payment card industry trust PCI-DSS as a security standard around which they can build their security standards. Many CSPs must either meet or support their customers in meeting PCI-DSS. As such, these audits are quite common in the cloud space, and understanding PCI-DSS is a valuable skill for cloud security professionals.

NIST SP 800-53 and FedRAMP

NIST releases and manages a variety of special publications related to computer security, cloud computing, and other technologies. NIST SP 800-53 — Security and Privacy Controls for Federal Information Systems and Organizations is NIST’s “bible” of information security controls. Though it’s targeted towards nondefense related federal agencies in the US government, it is widely considered one of the most comprehensive baselines of security controls and is used across many industries around the globe.

NIST 800-53 outlines hundreds of security controls across the following 18 control families:

• AC: Access Control
• AT: Awareness and Training
• AU: Audit and Accountability
• CA: Security Assessment and Authorization
• CM: Configuration Management
• CP: Contingency Planning
• IA: Identification and Authentication
• IR: Incident Response
• MA: Maintenance
• MP: Media Protection
• PE: Physical and Environmental Protection
• PL: Planning
• PS: Personnel Security
• RA: Risk Assessment
• SA: System and Services Acquisition
• SC: System and Communications Protection
• SI: System and Information Integrity
• PM: Program Management

The latest revision of 800-53, Rev. 4, was released in 2013 and included what was, at the time, forward-leaning information on cloud security. As of this writing, NIST 800-53 Rev. 5 exists in draft format, with its final publication expected in the near future. The revision is expected to add further focus on securing cloud systems among other emergent technologies.

The Federal Risk and Authorization Management Program, or FedRAMP is a US government-wide program that was established in 2011 to create a standardized approach to security assessment, authorization, and continuous monitoring of cloud service providers. FedRAMP effectively enforces NIST guidelines (including 800-53 and others) for any CSP that provides products or services to the US government. Known for being a rigorous assessment process, the FedRAMP model has been a major influence for Public Sector cloud security programs around the world.

Common Criteria

Common Criteria (CC), formally known as Common Criteria for Information Technology Security Evaluation (yeah, let’s just stick to CC) establishes processes for products to be evaluated by independent laboratories to determine their level of security. CC is another ISO/IEC standard (ISO/IEC 15408) and is internationally recognized as the gold standard for identifying secure IT products.

The Common Criteria consists of two components:

• Protection profiles: These profiles establish a set of security standards unique to a specific type of product, such as operating systems, firewalls, antivirus, and so on.
• Evaluation Assurance Levels (EALs): An EAL is a numeric score that is assigned to a product to describe how thoroughly it was tested during the CC process. EALs range from 1 through 7, with the higher levels providing more assurance of the product’s security claims. The seven EAL ratings are
  • EAL 1: Functionally tested
  • EAL 2: Structurally tested
  • EAL 3: Methodically tested and checked
  • EAL 4: Methodically designed, tested, and reviewed
  • EAL 5: Semi-formally designed and tested
  • EAL 6: Semi-formally verified design and tested
  • EAL 7: Formally verified design and tested

For more information on Common Criteria, including details about the evaluation process, visit https://www.commoncriteriaportal.org/.

FIPS 140-2 and FIPS 140-3

Federal Information Processing Standard (FIPS) Pub 140-2 (or FIPS 140-2) is another standard released by NIST of the US government; this one is related to the assessment and validation of cryptographic modules. A cryptographic module is simply any hardware, software, and/or firmware combination that performs encryption, decryption, or other cryptographic functions.

The latest revision to FIPS 140-2 was made in 2002, predating cloud computing as we know it. That aside, it is still recognized around the world as reliable guidance for certifying the effectiveness of cryptographic hardware and software.

At the time of this writing, FIPS 140-2 has recently been superseded by FIPS 140-3, but FIPS 140-3 won’t be fully rolled out and mandated until late 2021 at the earliest. I cover both standards here, as you could see either one on the CCSP exam or in the real world.

Similar to Common Criteria, FIPS 140-2 assessment is completed by one of several independent third party labs, who rates each product’s security between levels 1 and 4. The FIPS levels are

• Level 1: The lowest level of security. The basic requirement is that at least one approved algorithm is in use by the cryptographic module. The only physical security requirement is that production-grade components be used. FIPS Level 1 allows implementations of cryptographic modules that execute software and firmware on general purpose, unevaluated operating systems; higher security levels require that entire operating environments be evaluated by Common Criteria standards.
• Level 2: Security Level 2 adds additional physical security considerations to those in Level 1 by requiring cryptographic modules to show evidence of tampering (tamper-evident tape or pick-resistant locks, for example). The goal with this level is to provide visible assurance of a device’s integrity.
• Level 3: This FIPS Security Level adds even further physical security assurance by requiring that modules take steps to detect tampering and respond by protecting the module and any data within. An example of this level would be detecting that the hardware has been breached and erasing all plaintext data within the module to prevent unauthorized access.
• Level 4: The highest level of security, which requires rigid testing and scrutiny. Devices certified at this level require that cryptographic modules are fully surrounded by protections that are able to detect any and all unauthorized access attempts. A successful penetration of the physical barrier requires immediate erasure of any sensitive plaintext data within the module. Additionally, Level 4 devices require that cryptographic modules are protected against environmental attacks. For example, an attacker can attempt to cause a device’s security mechanisms to fail by manipulating electrical or temperature conditions of the device. This attack would be detected and responded to by a Level 4 device.

The information in this section serves as a good primer to FIPS 140-2 and covers what you need to know for the CCSP exam. The FIPS 140-2 Publication goes into some of these topics, so it’s worth a look if cryptography is important to you. You can find a link to the publication, along with other helpful resources, in Appendix B.

After years of teasing the cryptographic community, FIPS 140-3 was published in March 2019. The publication sets forth some very broad guidance, but most notably aligns the new standard with those set forth in ISO/IEC 19790:2012 (Security Requirements for Cryptographic Modules) and ISO/IEC 24759:2017 (Test Requirements for Cryptographic Modules). This is a big strategic move on the part of NIST, aligning US government standards with those of an international standards body like ISO.