Hardware specific security configuration requirements

As with traditional data centers, a cloud data center’s infrastructure begins with its physical hardware — all the servers, networking devices, and storage components that you’d find in the on-premise world. While these environments have many similarities, there are some unique points to consider when implementing and building a cloud infrastructure. There are many types of hardware components, each with countless combinations of configuration requirements and settings. This variety becomes even more pronounced in a cloud environment due to the sheer size of cloud infrastructures and the often diverse set of hardware devices that need to be configured and secured.

Installing and configuring virtualization management tools

From hypervisors to Software-Defined Networks, and everything in between, virtualization is the backbone of cloud infrastructures. Virtualization management tools interface with virtualized components as well as the underlying physical hardware to oversee and manage the operations of the virtualized environment. With such a heavy reliance on virtualization, cloud security professionals must ensure that careful attention is given to securely installing and configuring these management tools. The tools that manage the hypervisor and management plane are incredibly sensitive and must be protected at all costs! Successful attacks against virtualization management tools can compromise the confidentiality and integrity of cloud user data or even jeopardize the availability of the entire infrastructure.

There are many types of virtualization technologies, and even more virtualization vendors that supply them. Each vendor generally has its own tools and guidelines for managing and securing their products. As with any third-party product, you should first consult your particular virtualization vendor’s documentation and support team for installation and configuration guidance. In my experience, the best cloud providers form strong relationships with their vendors, and I’d recommend that any organization with a highly virtualized environment establish similarly strong relationships with their vendors. If possible, you should form these relationships early in the development of your cloud solution and leverage your vendors’ guidance throughout the entire development lifecycle.

Virtualization management tools, when properly configured, provide you with greater awareness and automation of your virtualized environment:

• Awareness: Configure your management tools to capture a unified view of your entire virtualized environment and all associated components. Using virtualization management tools provides the unique ability to see and understand your whole environment at a glance.
• Automation: Configure your virtualization management tools to automate standard infrastructure management tasks, including workload management, performance monitoring, and resource optimization. These tools can be used to automate the less strategic tasks so that your IT resources can focus on more impactful and innovative projects.

Aside from properly installing and configuring virtualization management tools, it is crucial that you take a comprehensive approach to the security of these tools. Vendor guidelines go a long way to ensuring a secure installation and configuration — but, that’s only the beginning. Effective security of these tools generally follows best practices for effective security of any highly sensitive system.

Starting with our friend, the principle of least privilege, you should ensure that the fewest people possible have access to your virtualization management tools. Such high-impact access should be limited to personnel with an absolute business need for such access, and they should be sufficiently background checked to help ensure their suitability for such roles. You may want to rethink giving that intern access to your virtualization management tools (sorry, interns!). For users with a proper business need, RBAC and strong authentication mechanisms are a must. Use multifactor authentication. Period.

Network isolation is a major control in safeguarding your virtualization management tools, and all virtualization management should occur on its own segregated management network. Segregating your critical management tools from customer environments ensures that vulnerabilities in a tenant environment cannot affect other tenants (by pivoting through the management tools) or even impact your entire infrastructure. I discuss network management further in Chapter 5.

In addition to these preventative mechanisms, make sure that you thoroughly log and monitor all access to these management tools, including logging access denials, which may alert you to brute force attempts or other foul play.

Virtual hardware specific security configuration requirements

Configuring virtual hardware requires awareness and consideration of the underlying physical hardware. For example, you’d have a problem if you had a physical host with 100TB of storage, but you configured your virtual hosts to use a total of 150TB of storage. This trivial example demonstrates just how in sync the virtual and physical worlds must be. Each vendor generally documents a set of required and recommended configuration settings for their virtualization products. As the cloud provider goes through the process of generating and configuring virtual images for customer use, it’s important that they consider those requirements in order to ensure functional and secure management of virtual resources for all cloud customers.

Installing guest operating system virtualization toolsets

Most of this section is focused on the virtualized hardware that serves as the underlying host for tenant VMs. The other side of this coin focuses on the virtualization toolsets that enable the guest OS to be installed and run from a VM; this toolset is essentially a set of technologies and procedures provided by an OS vendor that allow it to run in a virtualized environment rather than directly on a physical machine.

Virtualized environments can run any type of OS that provides a virtualization toolset (most popular operating systems do). Therefore, the variety of operating systems available to cloud customers is limited mainly by the cloud provider and what they’ve configured. When a CSP chooses to support a given guest OS, they should carefully configure and manage the associated virtualization toolsets in accordance with the OS vendor’s guidelines and recommendations.

Configuring access control for local and remote access

When thinking about access control for cloud environments, a lot of attention is usually given to controlling access to customer environments and data and rightfully so — that’s important stuff. While much of this book is geared toward that user-centric access control, I use this section to focus on access control for the underlying cloud infrastructure. Many of the access control principles from traditional data center security apply here — things like limiting physical and logical access to sensitive data, physically securing buildings and rooms that store critical components, conducting personnel screening for data center employees, and so on.

There are three primary mechanisms to consider when securing local and remote access:

• Keyboard video mouse (KVM)
• Console-based access
• Remote desktop protocol (RDP)

All of these access methods should require MFA and thorough logging and monitoring, at a minimum. You explore additional configuration recommendations in the following sections.

I discuss the principle of least privilege throughout this book. A set of fairly new concepts, Just-in-Time (JIT) and Just-Enough-Access (JEA), should be used to ensure that only the right amount of access is issued during only the right times. Tools like CyberArk and other Privileged Access Management systems can be used to enforce these concepts and ensure true least privilege.

Secure network configuration

Secure network configuration in the cloud involves the use and configuration of several technologies, protocols, and services. VLANs, TLS, DHCP, DNS, and VPN are some of the key concepts you must understand for the CCSP exam and for real world applications.

Hardening the operating system through the application of baselines

When securing any physical computing device, one of the first things you should focus on is its underlying operating system. Creating and applying baselines is a standard procedure for securing operating systems in traditional IT and cloud environments alike; it involves establishing and enforcing known good states of system configuration. OS baselines should be developed with least privilege in mind and configured to allow only services, features, and access methods that are absolutely required for system functionality — turn off and disable any unnecessary services, close unused ports, and disable access routes that aren’t required.

Depending on your business requirements and technology implementations, your organization may develop a single baseline for each OS in your environment, or you may find it necessary to develop multiple baselines to cover specific use-cases. For example, it is very common to see a Windows baseline for webservers, another baseline for Windows-based database servers, and another one for employee desktops — each separate baseline must have its own policy that identifies what services and functions are required and which are prohibited.

No matter which OS you’re securing, the process for creating baselines generally starts with taking a fresh OS install and disabling all unnecessary ports, protocols, and services. If nobody will be browsing the Internet, then go ahead and remove that vulnerability-prone browser. If only HTTPS traffic is allowed, then consider disabling port 80. Anything and everything that is not needed for system functionality should be shut down, deleted, and disabled. Doing so reduces the attack surface of not just one device, but every single device that gets this baseline configuration. Aside from this generic process, specific OS vendors have their own tools and best practices for baseline configuration and deployment. I explore Windows, Linux, and VMware baseline management in the following sections.

In addition to applying security best practices and ensuring least privilege, OS baselines can and should be used to enforce any OS-related legal and regulatory compliance obligations.

Availability of standalone hosts

Within a computing environment, a standalone host is a physical machine that operates independently from other machines in the environment. Standalone hosts are commonly used in traditional data center models when it’s desirable to isolate one system from others, whether for security, compliance, performance, or other reasons. Although less common, standalone hosts are still used in cloud environments.

CSPs generally make standalone hosts available to customers who want to streamline their cloud migration. By offering standalone hosts, customers are able to maintain their existing system architectures and configurations as they move everything to the cloud. Another great use-case for standalone hosts is in providing physical separation between systems or datasets, often for compliance purposes.

The concept of standalone hosts is growing in popularity among CSPs, again with regulatory and compliance being a huge driving factor. AWS offers services like dedicated hosts and dedicated instances, while Google Cloud offers sole-tenant nodes. Be sure to familiarize yourself with each product’s documentation to ensure they meet your technical and compliance needs.

Availability of clustered hosts

A host cluster is a group of hosts that are physically or logically connected in such a way that they work together and function as a single host. Each host’s resources are pooled together and shared among the cluster. Every host within the cluster is set to perform the same task, which is controlled and managed through software. Clustered hosts help protect against software and hardware failures of a single machine and can also be used for load balancing and parallel processing.

Resource-sharing concepts like reservations, limits, and shares help orchestrate and manage resource allocation among tenants using the same host cluster. These topics are discussed in Chapter 5.

Every CSP is different, but more times than not, you’re getting some form of clustered hosts when moving to the cloud. For the CCSP exam, you should know the differences between standalone and clustered hosts and when to use each.

Availability of guest operating system

In the same way that clustered hosts and storage clusters increase the availability of physical resources, tools and processes to support redundancy increase the availability of guest operating systems. A cloud customer expects their guest OS to be available whenever they need it, and a cloud provider should really live up to that expectation if they want to keep customers in the crowded CSP market. A guest OS is little more than a file on the provider’s physical hardware, and so ensuring its availability starts with protecting that file via standard data protection mechanisms discussed throughout this chapter and the rest of the book.

Access controls for remote access

Given the nature of cloud computing, customers and users require remote access to use and manage their logical environment. Remote access to the cloud’s physical environment, however, should be restricted to very few privileged CSP employees. As a CCSP, your job is to ensure that all routes, methods, and mechanisms used for remote access are fully secured and monitored.

Common remote access methods used include

• Virtual private network (VPN)
• Remote desktop protocol (RDP)
• Secure terminal access
• Secure Shell (SSH)

No matter which remote access methods are deployed and used, you must ensure that the underlying systems supporting remote access are hardened (via OS baselines), vulnerability scanned and patched, and monitored for suspicious activity (using event logging and other controls discussed throughout this book).

Remote access comes with inherent risk, especially privileged access and when traversing the Internet. All remote access should be encrypted with TLS or a similar mechanism, and all privileged remote access should go through a secured system (like a bastion host or jump server). Multifactor authentication should be considered a requirement for all privileged access, and I highly recommend it for remote access, wherever possible. I introduce MFA in Chapters 2 and 5 and provide a deeper look in Chapter 6.

Operating system baseline compliance monitoring and remediation

I introduce the concept of OS baselines earlier in this chapter. Applying baselines is an important step to toward ensuring consistent and secure operating systems, but it’s far from a set it and forget it process. Once OS baselines are applied, it’s important to ensure that systems remain in compliance with those baselines through continuous monitoring. Compliance can be accomplished by using configuration management tools with automated baseline scanning functionalities. You load these tools with your approved baselines for each OS and scan your infrastructure to detect any noncompliant systems. In doing so, you are able to spot systems with unexpected configurations, which may occur for several reasons:

• Your baseline was not applied to all systems, either intentionally or accidentally.
• A legitimate administrator made an unauthorized change to a system.
• A malicious outsider gained access to a system and made modifications — for example, discovering an unauthorized open port may be an indication that a hacker has set up backdoor communication.
• A system has an approved policy exception that the baseline scanner did not account for (for example, port 80 may be disallowed in your Linux baseline, but allowed on a handful of webservers that use HTTP instead of HTTPS).

Patch management

Patch management is a subset of configuration management that includes all processes for finding, testing, and applying software patches (or code changes) to your systems. Patch management includes more than just vulnerability management, although that is a huge component of it. Patches are released by software and firmware vendors and made available for their customers to install; the patches typically provide new functionality, improve stability, and, of course, fix known security vulnerabilities. Every organization should develop a patch management policy that identifies which assets require what type of patches on what schedule. In addition, your organization should create and maintain a set of patch management procedures that define what steps to take in order to acquire relevant patches, validate their appropriateness for your environment, apply them to all assets, and test their effectiveness.

Organizations approach patch management in several ways, but a typical patch management process may look something like the following:

1. Identify.

   The first step is to identify that a required patch actually exists. This step entails gathering information from all relevant vendors about all outstanding patches for all your software and firmware. In most cases, vendors offer notification mechanisms or other means for customers to quickly identify when new patches are released. This step can be quite tedious for large public clouds with many systems and numerous types of software. All outstanding patch information should be aggregated into a database or patch management tool for consistent, automated, and streamlined deployment.

2. Acquire.

   After identifying that patches exist for your environment, this next step is to actually obtain those patches by downloading the appropriate executables, scripts, or packages. Some software is able to phone home and download relevant patches directly within the software itself, while other software requires navigating to the vendor’s website or other means. Your patch management procedures should include documented steps to procure patches for each vendor within your environment.

3. Test.

   Many vendors provide hashes for you to validate the integrity of their patches after downloading — installing a compromised patch can wreak havoc on your systems, and hashes help prevent that. Regardless of whether you have a hash, you should first test patches in a development environment to ensure that they don’t break your systems or introduce new risks. Once you confirm that a patch causes no harm, then you can approve it for deployment/installation.

4. Deploy.

   Now that you’ve found, acquired, and tested your patches, you can go ahead deploy them across your production environment. You should consult your patch management policy to determine the appropriate patching schedule. In many cases, organizations implement deployment windows during which patches and system updates can be made. Automation is critical here, especially in large cloud environments. In most cases, cloud infrastructures rely on patching baseline images and redeploying those baselines to impacted systems; patching images removes the need to individually patch thousands of systems and reduces the risk of one-off errors.

5. Validate.

   This final step requires that you validate that your patches are installed properly and confirm that everything is in working order. In some cases, it can be as simple as a looking for a confirmation message, but others can be as involved as running tests to ensure the underlying host is operating as expected.

I cannot stress enough how important automation is for cloud patch management. Infrastructures with thousands (or even hundreds of thousands) of systems cannot be effectively managed individually or manually. I have seen some very sophisticated automation technologies used to streamline the entire patching lifecycle, and even then, patch management can still be a major headache. Doing your homework early on and developing a robust patch management plan and process can help tremendously.

On the cloud customer side, remember that your patch management responsibilities are dependent upon your particular cloud service model (IaaS, PaaS, or SaaS) and what cloud services you’re using. I’ve seen this be a major point of confusion for cloud customers who incorrectly believe that patching is 100 percent handled by the CSP, even for IaaS services. The cloud provider is completely responsible for patching the underlying infrastructure, but IaaS (and even PaaS customers, to an extent) must be aware of their patching duties. For example, if you’re using AWS EC2, Amazon is responsible for patching the underlying physical hosts that run your EC2 instances, but you are wholly responsible for patching your OS images. Consult your CSP’s documentation for information specific to your implementation.

Performance and capacity monitoring

Performance monitoring is a critical task that every cloud provider must perform on a continuous basis to ensure that systems are running dependably, and customer SLAs are being met. Performance monitoring involves routine collection and analysis of performance metrics for key components of the cloud environment. Key components that should be monitored include network, compute, and disk, and memory. Most vendors offer performance metrics and recommend techniques for monitoring them, but some things to examine include

• Network: Latency, dropped packets, and other standard network performance metrics
• Compute (for example, CPU): Excessive utilization and response time
• Disk: Read/write times and capacity limits
• Memory: Excessive usage and capacity limits

When conducting performance and capacity monitoring, it’s important that CSPs consider their ability to support all current customers as well as their capacity to support autoscaling and future customer growth. Due to rapid elasticity, a cloud provider must have enough capacity to withstand an unexpected spike in resource utilization by one or more customers; capacity planning must take this into account.

Hardware monitoring

When talking about monitoring cloud environments, it’s almost natural to jump straight to the virtual infrastructure and its resources. After all, cloud computing is all about virtualizing network, compute, and storage resources, right?! While that may be true, it’s important not to forget that underneath all of that virtualized infrastructure lies actual physical hardware that must also be monitored. The same key components (network, compute, disk, and memory) must be monitored in the physical plane just as you do for virtual performance and capacity monitoring. In many cases, you can use the same processes and even similar tools to monitor physical hardware and virtualized infrastructure. As always, make sure to first check with each hardware vendor for recommended monitoring utilities and best practices.

In addition to the standard monitoring mentioned in the previous paragraph, hardware should also be monitored for things like fan speed, device and surrounding temperatures, and even voltage readings. This type of information can help you track the overall health of your hardware and can help you identify overworked or aging hardware before it fails.

Monitoring vast cloud infrastructures is a monumental task. Due to resource pooling, clustering, and other high availability features, it’s often necessary to consider large sets of hardware rather than each machine individually. Consistent with a major theme of this chapter, automation should be used wherever possible to streamline these efforts. Most integrated hardware monitoring utilities provide dashboards with at-a-glance details of your hardware’s health status and any important metrics or alerts.

Configuring host and guest operating system backup and restore functions

Whether in a traditional data center or a cloud environment, backup and restore are some of the most critical security functions. Ensuring that important data is backed up and easily restored, when needed, supports the core information security principle of availability. For cloud infrastructures, it’s essential to configure physical hosts as well as guest operating systems so that important systems and data are available and functional after an incident or disaster.

You should be familiar with three main types of backup technologies:

• Snapshots
• Agent-based
• Agentless

Network security controls

Securely managing the logical and physical infrastructure for a cloud environment requires security controls at multiple layers. (You can read about defense-in-depth in Chapter 2.) A layered approach to network security relies on several types of technologies, including firewalls, IDS/IPS, and more.

Management plane

Managing the physical and logical infrastructure of a cloud environment requires effective task and operations scheduling, efficient orchestration of activities and resources, and comprehensive, yet minimally disruptive maintenance. All of these activities take place in the management plane.

Change management

Change management is an IT discipline focused on ensuring that organizations employ standardized processes and procedures to make changes to their systems and services. The overall objective of change management is to allow IT changes to be made in a structured and secure manner, while minimizing negative impacts to users.

You may hear the term change management used in project management circles and assume that it’s strictly up to a PM to handle change management. Unfortunately, you’re not quite off the hook. Changes to an IT environment may potentially impact the security posture of that environment, and so every cloud security professional has a responsibility to partner with their organization’s Program Management Office (PMO) to securely manage these changes.

In a cloud environment, some activities that require change management include

• Buying, building, or deploying new hardware or software
• Upgrading or modifying existing hardware or software
• Decommissioning hardware or software
• Modifying the operating environment (for example, changing data center humidity levels)
• Modifying IT documentation (yup, this needs to be considered an extension of the system itself and properly controlled)

What does an IT change management process look like?, you ask. Well… I’m glad you asked! ITIL, ISO, and other frameworks break change management down into a series of steps. These steps may vary from one framework to the next, but in general the process looks something like this:

1. Request a change.

   During this step, a necessary change is requested or somehow otherwise identified. The person or team requesting the change typically creates an RFC (request for change) that documents the details of the request, including such details as the requestor’s contact info, time requirements, business justification, and more.

2. Evaluate the requested change.

   The RFC is reviewed for completion, appropriateness, and feasibility. During this step, you should evaluate the change to assess benefits and risks associated with it. You want to leave this step with a clear understanding of all pros, cons, and impact to your systems and business if you make the requested change. Who evaluates an RFC depends on the size and scope of the particular change. For larger or more impactful changes, your organization may rely on a Change Advisory Board (CAB) or Change Control Board (CCB) to evaluate the RFC. A CAB usually consists of stakeholders throughout the organization, while CCBs are most often limited to project-level stakeholders. Having an information security representative (like a CCSP) on both the CAB and CCB are important and often overlooked by organizations.

3. Approve the change.

   Once the RFC has been thoroughly evaluated, a recommendation to authorize the change is sent to the appropriate authority, depending on the request. Approval can be anything from getting a Senior Sys Admin to sign off on replacing a hard drive to requiring a VP to approve a data center expansion.

4. Plan the change.

   Planning the change again depends on the size and scope of the effort. Smaller changes may require a quick writeup, whereas larger changes call for full project plans. Identify any resources you need and the steps you must follow to complete the change.

5. Implement the change.

   With a plan in hand, go forth and make it happen!

6. Review the change.

   During this final step, test that your change was implemented successfully and validate that no unintended consequences have occurred. For larger changes, a post-implementation review (PIR) should be developed to document the implementation results and any lessons learned.

Continuity management

Continuity management helps ensure that a CSP is able to recover and continue providing service to its customers, even amidst security incidents or during times of crisis.

Continuity management involves conducting a business impact analysis (BIA) to prioritize resources, evaluating the threats and risks to each of those resources, identifying mitigating controls for each risk, and developing a contingency plan that outlines how to address potential scenarios. See Chapter 3 for full coverage of business continuity planning (BCP).

Information security management

Information security management codifies the protection of your environment’s confidentiality, integrity, and availability as part of your overall IT management objectives. Information security management basically includes everything covered in Chapter 2 and in many places throughout this book being made an official part of your IT service management plan. This practice involves planning, building, and managing security controls that protect your systems and data against security risks. Having information security specifically called out as a management objective ensures that it’s treated as an integral part of all IT decisions.

ISO/IEC 27001, mentioned a couple times in this book, is one of the leading standards for information security management.

Continual service improvement management

Continual service improvement management is borrowed from ISO 20000-1, and is a lifecycle of constantly improving the performance and effectiveness of IT services by collecting data and learning from the past. The goal of this process is to perpetually search for ways to make your systems and services better than they currently are.

Incident management

Incident management is the process of monitoring for, responding to, and minimizing the impact of incidents. In this case, an incident is any event that can lead to a disruption in a service provider’s ability to provide its services to users or customers. I introduce incident handling (the tactical part of incident management) in Chapter 2.

Problem management

Problem management is the process of managing any and all problems that happen or could happen to your IT service. The objective here is to identify potential issues and put processes and systems in place to prevent them from ever occurring. Achieving this objective requires analyzing historical issues and using that insight to predict potential future problems. Problem management does not always succeed at preventing issues, and so the process also involves putting processes and systems in place to minimize the impact of unavoidable problems.

Release and deployment management

The objective of release and deployment management is to plan, schedule, and manage software releases through different phases, including testing in development environments and deployment to a production environment, while maintaining the integrity and security of the production environment. Successful release and deployment management requires collaboration between developers, project managers, the release team, and those responsible for testing. A release management team is generally constructed during the early planning stages and oversees the release through development, testing, troubleshooting, and deployment.

Configuration management

I discuss application configuration management in Chapter 6, but I’m going to take a broader view for a second. Configuration management is the process of tracking and controlling configuration changes to systems and software. Configurations include information about all physical and logical components within the cloud environment, and proper configuration management encompasses all settings, versions, and patch levels for your hardware and software assets. Your organization should have a configuration management plan that identifies how you identify, plan, control, change, and maintain all configurations within your environment. Due to the sprawling and dynamic nature of cloud environments, cloud providers and their customers should seek to use automated tools and techniques to streamline the configuration management process.

Service level management

There are few acronyms I hear more than SLA when talking to cloud customers. It’s discussed all over this book, and for good reason — service level agreements are contracts between a CSP and cloud customer that set the customer’s expectations for the minimum level of service they’ll receive. As such, service level management is a huge part of cloud business, and it involves negotiating, developing, and managing all CSP SLAs.

You can read more about SLAs in Chapter 3.

Availability management

Availability management is the process of ensuring that the appropriate people, processes, and systems are in place in order to sustain sufficient service availability. Availability management involves establishing your system’s availability objectives (for example, SLAs) as well as monitoring, measuring, and evaluating your performance against those objectives. An underrated objective of an availability manager (unless you’re a cloud provider) is achieving all these goals as cost-effectively as possible.

Capacity management

Capacity management is the process of ensuring that the required resource capacity exists, at all times, to meet or exceed business and customer needs, as defined in SLAs. Similar to availability management, cost-efficiency is paramount here. While having insufficient capacity can lead to poor service performance and loss of business, overspending on capacity can lead to less profit, lower margins, and potentially unsustainable business. It’s certainly a fine line between provisioning too little capacity and too much, but it’s a line your organization must spend time carefully defining.

Collecting, acquiring, and preserving digital evidence

Generally speaking, the core principles of digital forensics are the same in the cloud as they are in traditional data center environments — you still must collect digital evidence and conduct thorough analysis on it while maintaining its chain of custody. Due to the fundamental differences between cloud environments and traditional data centers, some forensic issues are unique to cloud computing. Among the most important concerns are data ownership and shared responsibility, virtualization, multitenancy, and data location. In the following sections, I cover how to address these concerns as you collect and manage forensic data in the cloud.

Evidence management

Managing chain of custody from evidence collection to trial is the most important part of any digital forensics investigation. You could have the best tools and the smartest analysts generate the most useful data, but it would all be for naught if you aren’t able to protect and prove the integrity of your evidence throughout its entire lifecycle. I cover chain of custody and non-repudiation in Chapter 4. If you haven’t already, you should really check it out for additional background.

Cloud providers must maintain well-documented policies and procedures for evidence management. Policies should establish what types of data to collect and how to properly engage with customers, authorities, and other stakeholders. It’s important that a provider understands how cloud-specific factors like multitenancy and virtualization impact their collection and preservation of evidence. In some cases, contractual obligations or jurisdictional requirements might mandate that a CSP disclose their collection activities and processes to third parties. In other situations, the investigation may be deemed confidential and require that evidence collection and management processes not be disclosed at all. For either scenario, requirements should be fully documented and understood prior to collecting or handling evidence.

Customers

As a cloud service provider, communicating with customers is among the top of your priorities. Anytime you provide a service to someone, it’s essential that you understand their needs and wants — an open dialogue between cloud provider and customer is the best way to achieve this goal. Customers are likely to directly engage CSP personnel most during the early stages of procurement, planning, and migration. Depending on the customer, a CSP may designate some combination of sales representatives, technical account managers, and solutions architects to learn a customer’s requirements and share the provider’s capabilities. Contract and SLA negotiations are pivotal during this time, and it’s important that the provider is fully transparent about what they can and cannot do.

Customers have less of a need to communicate directly with a CSP as their cloud journey progresses (at least they hope so!). The bulk of ongoing communications should be updates by the CSP related to service availability, system upgrades, and policy changes that have a customer impact.

Effective communication isn’t solely based on phone calls, meetings, and emails. In fact, both customers and providers benefit from self-service access to information. One great example of this is AWS’ Service Health Dashboard (https://status.aws.amazon.com) that shows the current status for all services in all of their regions. This dashboard is a great example of automated communication that helps providers scale as business grows.

Perhaps the most important ongoing communication between a CSP and its customers involves providing up-to-date documentation. User guides and other product documentation is essential for customers to know best practices when using their cloud services. Even more essential, CSPs must ensure that they accurately communicate what responsibilities they have versus the customer’s responsibility. This information is usually documented in a customer responsibility matrix, or similar. These documents are often associated with some sort of regulation or compliance framework and can be used to communicate what security functions a CSP performs and what functions must be performed by the customer.

Vendors

Vendors (or suppliers) are a major part of a CSP’s ecosystem; I don’t know of a single CSP that doesn’t rely on multiple vendors in some form or fashion. Examples include hardware manufacturers, software vendors, outsourced maintenance professionals, and more. Many of these services are mission critical for a CSP; as such, effective communication with vendors is of the utmost importance. Most important CSP-vendor communication is captured within various contracts and agreements; these agreements should detail a vendor’s commitments to the CSP from onboarding through termination.

Partners

The type of partners that cloud providers rely on is wide-ranging and can include anything from companies that support go-to-market to organizations that build their SaaS solutions on your IaaS infrastructure. The lines can sometimes blur between partners and vendors or customers, but it’s important to evaluate your partner relationships and determine the best method and frequency to communicate with each of them.

Regulators

Just about every cloud provider and cloud customer has regulations to comply with. As a CCSP, it’s your job to understand these regulations and help your organization craft ways to satisfy them. Communication with regulators should happen early and often. When a cloud provider is first planning to build their infrastructure or making significant changes to existing infrastructure (like constructing a new region), they should maintain communication with regulators to ensure that all requirements are fully understood. Further, cloud providers generally benefit by having security-minded personnel review and comment on upcoming regulations before they’re finalized. Regulatory bodies are often a step or two behind bleeding-edge technology. CSPs that understand the technology and its limitations better than anyone should communicate these factors to regulators in order to help shape realistic policies and requirements.

Other stakeholders

Aside from customers, vendors, partners, and regulators, you may find other stakeholders that need to be involved in your communication plans. This need may be based on a particular project or a request from one of the previously discussed parties. In any case, you must evaluate the communication needs of all stakeholders, and determine what, how, and when to communicate with them.

Security operations center (SOC)

A security operations center (SOC) is a centralized location where designated information security personnel continuously monitor and analyze an organization’s security posture. Rather than focusing on developing security strategies or implementing security controls, a SOC team is responsible for the ongoing, operational aspects of security. SOCs should be staffed 24/7, and its team members are responsible for detecting, reporting, and responding to security incidents using a combination of technology and well-established processes.

In the olden days, a SOC was strictly considered to be a large room with lots of computers, large monitors, and staff members. That definition still holds true today, but we’re seeing the emergence of virtual SOCs. A virtual SOC allows teams in different locations to share resources and communicate in real-time in order to monitor and respond to security issues. This concept is almost a requirement for globally dispersed cloud providers.

Your organization’s incident response (IR) team is likely different from your SOC team, though there may be overlap. Once the SOC identifies a potential incident, it should quickly trigger incident response procedures and work with the IR team to investigate and resolve the matter.

The scope of a cloud provider’s SOC should include all their physical and logical assets — all hypervisors, servers, networking devices, storage units, and any other assets under the CSP’s control. While tenant’s guest operating systems are not generally monitored by a CSP, the SOC should still monitor and identify any malicious activity between a tenant and the CSP or from one tenant to another.

Monitoring of security controls

On a more tactical level, monitoring should be in place to assess and validate the effectiveness of your security controls. If you’ve used a defense-in-depth approach (and I know you have), then you’ll need layers of monitoring in place to continuously ensure that your controls remain in place, unmodified, and fully functional.

Monitoring your security controls should begin with documentation that defines the intent of each control and how it is implemented. You should also have documentation that identifies how to monitor each security control, either manually or by automated means. In some cases, vendors provide best practices on how to monitor their security controls. Other scenarios require that your information security team, led by their fearless CCSP, generates the necessary guidance. Make sure that you also maintain complete documentation of all security configuration baselines. I talk about documenting baselines earlier in this chapter, and it becomes especially important when it’s time to monitor them.

Conducting vulnerability assessments and penetration tests are a great way to indirectly assess the effectiveness of your security controls. These tests expose weaknesses in your environment, and penetration tests can even show you the impact of those weaknesses being compromised. Performing these tests can highlight weak areas in your security architecture and help you identify needs for new or modified security controls.