 While cloud services typically make available nearly unlimited log data, very few organizations make it a point to enable this capability fully—or they fail to adequately collect and protect it. Without closely monitoring the service or understanding the real nature of a deployment it is practically impossible to: Organizations need to plan how they intend to research, understand and respond to issues when they occur and put in place the capabilities to collect and store the appropriate data and logs. With the essence and nature of cloud offerings often being quite different from one cloud service to another, it is critically important for organizations to regularly rehearse and test end-to-end their planned approach to identifying and addressing issues. This will ensure that teams can minimize delays and that organizations have all the data they will need to support a response, even when a service changes unexpectedly. Attackers focus significant efforts to mask and erase their activities on systems and log stores are increasingly becoming a primary target to achieve this goal. While logging services may have good security in place such as advanced authentication, confidentiality and tamper resistant controls, this data is still vulnerable to attack. The least likely approach is a direct attack to break the encryption keys protecting the data. This requires significant effort and is proven to have a very low probability of success. A more likely approach is for attackers to compromise administrative accounts and scavenge for API keys used to secure the data. Phishing has always been one of the simplest and most effective ways to get into systems and this also applies to the cloud. Requests for access to something sensitive happen every day, and attackers require little technical sophistication to craft a convincing enough message to achieve that goal. Another regular target is the cloud development and test environments. API keys are routinely encoded or left behind unprotected within these environments. Organizations also rarely secure or monitor these environments with the same level of scrutiny as production environments, which makes them a high value and poorly protected target for attackers. As organizations migrate to the cloud, many do not follow the sound hygiene principles they had established in their on-premises environments. This is partially because it is so simple to spin up environments in the cloud without the need for protracted approvals and acquisition processes, especially when master agreements are established with providers that enable everything to be automatically generated. When on-premises environments required significant effort to requisition and maintain hardware and costs were directly accounted for by projects, there was an added sense of urgency to remove components that were no longer actively needed. Today, most cloud deployments maintain dozens of iterations of test and development environments with no real justification other than the possible future convenience of keeping it around in case of an unspecified need. Lastly, the simple idea of keeping track of what is actually deployed can save hours or even days of frustration in the context of regular business operations and can provide precious minutes during an incident. At a basic level, tags should be assigned to instances identifying who owns the instance and what it is used for. Tagging adds context that is necessary for security teams to respond to security events quickly by clearly identifying critical resources and dependencies so they can triage and prioritize their efforts. Think of it as a medical alert bracelet for your assets—it is the only way they will be able to speak when you need them to. Bottom line: Organizations must ensure they have the maximum visibility available from their cloud providers to properly support, monitor and secure their active, test and development environments. Far too many organizations are operating their cloud deployments with massive blind spots without realizing it. Full visibility is critical across all environments. Without it, organizations cannot truly report on their actual risk exposure or effectively address it.		While cloud services typically make available nearly unlimited log data, very few organizations make it a point to enable this capability fully—or they fail to adequately collect and protect it.Without closely monitoring the service or understanding the real nature of a deployment it is practically impossible to:Understand how the environment should operateDetermine that something is not functioning as it should or, in the worst case, that an instance of the service has been compromisedBuild enough awareness and understanding of the service to identify and establish meaningful security controls that adequately mitigate possible risksOrganizations need to plan how they intend to research, understand and respond to issues when they occur and put in place the capabilities to collect and store the appropriate data and logs.With the essence and nature of cloud offerings often being quite different from one cloud service to another, it is critically important for organizations to regularly rehearse and test end-to-end their planned approach to identifying and addressing issues. This will ensure that teams can minimize delays and that organizations have all the data they will need to support a response, even when a service changes unexpectedly.Attackers focus significant efforts to mask and erase their activities on systems and log stores are increasingly becoming a primary target to achieve this goal. While logging services may have good security in place such as advanced authentication, confidentiality and tamper resistant controls, this data is still vulnerable to attack.The least likely approach is a direct attack to break the encryption keys protecting the data. This requires significant effort and is proven to have a very low probability of success. A more likely approach is for attackers to compromise administrative accounts and scavenge for API keys used to secure the data.Phishing has always been one of the simplest and most effective ways to get into systems and this also applies to the cloud. Requests for access to something sensitive happen every day, and attackers require little technical sophistication to craft a convincing enough message to achieve that goal.Another regular target is the cloud development and test environments. API keys are routinely encoded or left behind unprotected within these environments. Organizations also rarely secure or monitor these environments with the same level of scrutiny as production environments, which makes them a high value and poorly protected target for attackers.As organizations migrate to the cloud, many do not follow the sound hygiene principles they had established in their on-premises environments. This is partially because it is so simple to spin up environments in the cloud without the need for protracted approvals and acquisition processes, especially when master agreements are established with providers that enable everything to be automatically generated.When on-premises environments required significant effort to requisition and maintain hardware and costs were directly accounted for by projects, there was an added sense of urgency to remove components that were no longer actively needed. Today, most cloud deployments maintain dozens of iterations of test and development environments with no real justification other than the possible future convenience of keeping it around in case of an unspecified need.Lastly, the simple idea of keeping track of what is actually deployed can save hours or even days of frustration in the context of regular business operations and can provide precious minutes during an incident. At a basic level, tags should be assigned to instances identifying who owns the instance and what it is used for. Tagging adds context that is necessary for security teams to respond to security events quickly by clearly identifying critical resources and dependencies so they can triage and prioritize their efforts. Think of it as a medical alert bracelet for your assets—it is the only way they will be able to speak when you need them to.Bottom line: Organizations must ensure they have the maximum visibility available from their cloud providers to properly support, monitor and secure their active, test and development environments. Far too many organizations are operating their cloud deployments with massive blind spots without realizing it. Full visibility is critical across all environments. Without it, organizations cannot truly report on their actual risk exposure or effectively address it.