Over the last few months, technology and people have been thrown together like never before. The challenges of the COVID-19 crisis have put a spotlight on our relationship with the devices and services we rely on day to day. But, as with most crises, people have also demonstrated how resilient and adaptable they can be. With more devices connected to the Cloud, it does alter the rules of engagement in a pre-COVID world. Innovation often emerges.
While the Cloud does certainly alter the rules of engagement for protecting an organization’s information resources, it just as certainly does not eliminate the need for an information security function. I would like to make the case that the movement of those resources into the Cloud makes the chief information security officer (CISO) and her or his minions even more critical.
What CISOs Do
In my consulting career for over the past 25 years, I have not encountered two CISOs who see the job exactly the same way. There is too much variation depending on the industry, organizational scale, technology, and, to an extent, not usually recognized, the personality and political skill of the individual CISO. That said, there are some commonalities that I believe most CISOs would recognize.
Most CISOs are responsible for issuing and enforcing information security policies and standards. They conduct risk assessments and, on that basis, set short- and long-term strategies. They keep their antennae raised to detect emerging threats and communicate them both to senior management and throughout their organizations.
Most, if not all, CISOs also have tactical responsibilities. Monitoring information system usage for attacks and misuse is, as I see it, the most common component of all CISOs' roles. And then, if and when there is a breach, they manage the response to security incidents.
It is even more difficult to state definitively how organizations are currently using cloud services. Some do little more than acquire a few Software as a Service (SaaS) products. Others use the Cloud only minimally for archival storage or data backups. Some are in a transitional period, having lifted and shifted their data centers to those of Cloud Service Providers ‘CSPs’. For them, the need for security of their information resources is little changed except at the physical layer. Finally, some have re-engineered the way they manage and use information.
To make the case of Cloud (IaaS, PaaS, or SaaS), let me introduce to you the concept of Pets vs. Cattle in the context of Cloud as coined by Randy Bias in late 2016.
In the old way of doing things, we treat our servers like pets, for example, Bob, the mail server. If Bob goes down, it is all hands on deck. The CEO cannot get his email, and it is the end of the world. In a new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it is taken out back, shot, and replaced on the line.
Pets Service Model
In the pets’ service model, each pet server is given a loving names like zeus, ares, hades, poseidon, and athena. They are “unique, lovingly hand-raised, and cared for, and when they get sick, you nurse them back to health”. You scale these up by making them bigger, and when they are unavailable, everyone notices.
Examples of pet servers include mainframes, solitary servers, load balancers and firewalls, database systems, and so on.
Cattle Service Model
In the cattle service model, the servers are given identification numbers like web01, web02, web03, web04, and web05, much the same way cattle are given numbers tagged to their ear. Each server is “almost identical to each other” and “when one gets sick, you replace it with another one”. You scale these by creating more of them, and when one is unavailable, no one notices.
Examples of cattle servers include web server arrays, no-sql clusters, queuing cluster, search cluster, caching reverse proxy cluster, multi-master datastores like Cassandra, big-data cluster solutions, and so on.
Evolution of Cattle
The cattle service model has evolved from Iron Age (bare metal racked-mounted servers) to the Cloud Age (virtualized servers that are programmable through a web interface). This is a brief overview of the platforms and tools that have evolved in each of these eras.
The Iron Age
During The Iron Age of computing, it wasn’t until the introduction of hardware virtualization that gave rise to managing systems of cattle. Robust change configuration tools like Puppet (2005), CFEngine 3 (2008), and Chef (2009) allowed operations to configure fleets of systems using automation.
The First Cloud Age
In this initial era, virtualization was extended to offer IaaS (Infrastructure as a Service) that virtualized the entire infrastructure (networks, storage, memory, cpu) into programmable resources. Popular platforms offering IaaS are Amazon Web Services (2006), Microsoft Azure (2010), Google Cloud Platform (2011).
Such services gave rise to push-based orchestration tools like Salt Stack (2011), Ansible (2012), and Terraform (2014). These tools allowed you to coordinate state between the cloud provider and your application, and essentially allow you to program infrastructure, a pattern called Infrastructure as Code.
The Second Cloud Age
While automation was built to virtualize aspects of the infrastructure, there were early movements to virtualize or partition aspects of the operating system (processes, network, memory, file system). This allows applications to be segregated into their own isolated environment without the need to virtualize hardware, which in turn duplicates the operating system per application. Some of these technologies include OpenVZ (2005), Linux Containers or LXC (2008), and Docker (2015).
The introduction of containers became explosive with Docker becoming a ubiquitous ecosystem in and of itself. A new set of technologies evolved to allocate resources for containers and schedule these containers across a cluster of servers: Apache Mesos (2009), Kubernetes (2014), Nomad (2015), Swarm (2015).
These tools give rise to what is called Immutable Production, where disposable containers are configured at deployment.
The common element in all these uses of the Cloud is that they relate to services, which are achieved, in part, by transferring facilities and the equipment involved from a customer’s site to a CSP’s. So, if the movement to the Cloud (supposedly) reduces the role of a customer’s information security function, what security does the CSP provide?
Let a few of the major vendors explain:
“Security and Compliance is a shared responsibility between AWS and the customer.”
“Google is committed to doing its part in keeping your projects secure, but security is a shared responsibility.”
“As you consider and evaluate public cloud services, it’s critical to understand the shared responsibility model and which security tasks are handled by the cloud provider and which tasks are handled by you.”
So then, what exactly is the CSP’s share of the responsibility? The answer differs a little from vendor to vendor, but not much.
Amazon Web Services (AWS) says that it is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services. (An accompanying diagram on its web page places hardware and its global infrastructure, plus software for compute, storage, database, and networking, in Amazon’s zone of responsibility.)
Google states its case differently. Its web page on shared security commits the vendor to security over data center physical security, server and software stack security, trusted server boot, and data access and disposal.
Microsoft Azure takes full responsibility for physical hosts, the network, and the facilities. It agrees to some responsibility for identity and directory infrastructure, applications, network controls, and operating system(s), based on “service types.” The exact extent of Microsoft Azure’s responsibility is not spelled out in its literature, although I am quite sure that it is in their contracts.
Reduced to the essentials, these three companies, rather dominant in the marketplace, seem to me to be saying to their customers, “We will take care of what is ours. You take care of what is yours.” That is not really unfair, but it certainly does raise the stakes for those CISOs whose organizations in the Cloud.
What CISOs Must Do
CISOs are now called upon to keep their applications and information secure and to ensure that someone else is doing the same with their applications and infrastructure. I think it is fair to say that most CSPs offer little transparency into the details of their security measures. It is justifiable since they do not want to provide a road map to cyberattackers, and, so far, their defenses seem to be generally effective. While there is no shortage of Cassandras who tell of the potential for attacks on CSPs, the only significant case I know of was the incident involving the US’s Capital One Bank at AWS, and that case involved insider information.
“IF EVER THERE WAS A TIME THAT INFORMATION SECURITY HAS TO BE A FORETHOUGHT RATHER THAN TAKEN UP AFTER KEY DECISIONS ARE MADE, THIS IS IT.”
In addition to everything that CISOs had to do when all of their organizations’ information resources were on-premises (and, as I have written before, there will always be a residual data center), they must now take on additional duties. In particular, they must occupy key roles in vendor selection and management. If ever there was a time that information security has to be a forethought rather than taken up after key decisions are made, this is it. Selecting cloud vendors is less like a purchase and more like a marriage. The vendors make it easy to enter into a relationship, and oh, so hard to get out. The degree of commitment dictates early and ongoing attention to the security of applications, information, and infrastructure, both in the Cloud and in the building.
Cattle, Not Pets is a computing best practice and the CISOs in the Cloud with the rise of Security as Code which is equally critical in the current and post COVID world.
Comentarios