Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
The cloud is a complex environment, with different groups managing different cloud services and environments. The most basic division is between the cloud provider, who provides the core infrastructure, and the customer, who leverages services or builds their applications using resources leased from the provider. Within larger organizations, different cloud resources, data and applications may be owned by various lines of business, each with their own budget and development resources.
From a security perspective, this sort of divided ownership of the cloud can create severe challenges in terms of end-to-end visibility, control and compliance. Of course, the cloud is a shared infrastructure, and when it comes to security events, there will likely always be some shared responsibility. But the lack of a centralized security strategy and inconsistent security policies and standards leading to potential grey areas of responsibility can create serious security gaps, and put critical data and other digital resources at risk.
Cloud Provider vs. Customer Responsibility
When respondents to a recent survey by IHS Markit were asked, “who is truly responsible when there is a vulnerability or security event in their cloud deployment?” the answer reflected a lack of understanding of the basic division of responsibility. Even in the best-case scenario, where it should be clear as to who is responsible for a security event (such as a vulnerability in the cloud platform), only about half of respondents were able to identify the root cause and responsibility.
Complicating things further, there is yet another set of tools as to which responsibility should be clear. The list of security vendors available as add-ons through a cloud provider’s marketplace is exhaustive. The cloud providers themselves also offer a range of security solutions (built into their platforms as services). And many of the cloud management platforms, hypervisors, orchestration tools and other bits of cloud infrastructure have various levels of security available.
However, the truth is adhering to the shared responsibility model, whenever the customer applies any configuration to these tools, they become his responsibility. Nonetheless, divisions of responsibilities are not always clear for different events.
The best course of action is to identify and apply best practices to any resource and service consumed in the cloud. A root cause analysis (RCA) playbook should identify possible threats and plot actions where possible, and plot strategies for determining the root cause of an event. This includes identifying all key stakeholders, determining which investigation tools are available for threat analysis, establishing processes for orchestrating responses and resources between all parties and digitize and map those details to actual cloud technologies. Further, any response should be automated as much as possible.
Security Responsibilities Within the Customer Domain
Once the primary divisions of responsibility for a dealing with a security event is worked out between providers, vendors and customers–such as determining if a security breach is the result of a corrupted service or a misconfigured system–most cloud customers still have to address the divisions of responsibility within their own organization.
The challenge is, when it comes to cloud security, too many companies don’t have a good handle on who is responsible for what. Part of the challenge is many organizations have taken an ad hoc approach to cloud development. As a result, today’s organizations, with an average of five different cloud environments in place and two or more in development, may be hamstrung by the challenge that each cloud instance might be owned by different lines of business.
For many reasons, these groups may be reluctant to turn over the security of their individual cloud environment to the central security team. For example, speed is a critical component of DevOps efforts, so any security implementation that interferes with their primary objective of delivering applications is going to be a problem.
Part of the reason is traditional IT security teams rarely know much about cloud environments, and the security tools they recommend often bottleneck development. However, handing over to the DevOps teams building out cloud applications and environments is problematic as they have little to no expertise when it comes to security.
For example, one of the biggest challenges of many cloud-based security tools is the time and skill required to properly configure and manage them, let alone adjusting those configurations to eliminate false positives, or to ensure they don’t miss critical events or drop legitimate traffic. All that requires expertise most DevOps teams don’t have.
Shifting from DevOps to DevSecOps
Resolving this challenge can be as simple as adding a cybersecurity specialist to each of the various DevOps teams. Once integrated, DevSecOps can help navigate the fine line of the shared responsibility model to ensure both development and security requirements are met. They can negotiate between the customer/vendor/provider responsibility model, provide strategies for ensuring consistent security across and between cloud instances, and balance protection with performance.
Part of that is achieved through the selection, deployment and management of tools designed to meet the twin challenges of speed and security. For example, many SaaS-based security solutions, such as web application firewalls, are self-scalable, allowing web applications to grow as needed without compromising protection. Choosing the right tool can also ensure it can be easily stitched into an application transaction with minimal effort. Some of them even have the advantage of having already included deployment, maintenance, scaling and fine-tuning functions.
The proper application of automation plays an equally critical role in this process. Checking configurations and scanning objects for malware are time-consuming activities that can get pushed to the side when other issues arise. Automated cloud security solution selected and designed by the DevSecOps team can provide comprehensive configuration assessments, dynamically secure stored data, automatically scan for public cloud vulnerabilities, identify misconfigurations that put data at risk, scan files stored in the cloud and prevent the unauthorized downloading of sensitive information.
Building a DevSecOps Team Requires Executive Support
DevOps has become part of C-suite and board-level discussions, attesting to the growing critical value of web applications and digital transformation as part of the broader business strategy. However, if the frequency of breaches and the growing concerns of CISOs are any indication, executives aggressively pushing for cloud solutions often have a mistaken understanding of the nature of the security risks that cloud adoption and careless DevOps programs can introduce into their organization.
Therefore, it is critical executive leadership is educated on the risks associated with expanding an organization’s digital footprint, and as a result, its new potential attack surface. Expanding DevOps to DevSecOps enables the integration of security into new cloud environments on day one. It can also ensure RCA cloud security playbooks are developed and followed, and help introduce and manage security solutions designed to protect critical digital resources without introducing unreasonable risks. Finally, it can provide a much-needed buffer against fines and penalties associated with regulatory requirement violations should their cloud deployment become a conduit for a severe system breach.
