Skip to main content

Pets vs cattle: How to get cloud and DevOps security right

(Image credit: Pixabay)

In a world as nebulous as cloud computing and DevOps, analogies can sometimes help us to think more clearly. The idea of “pets versus cattle” was first used nearly a decade ago to help delineate the difference between traditional on-premises IT and the cloud, and has become a firm favorite in the DevOps community ever since. But there are also lessons here for cybersecurity teams, as long as they’re able to see through the limits of the analogy and understand where the main challenges are.

Journey to the cloud

First coined by cloud pioneer Randy Bias back around 2011, this particular metaphor helps us to understand how the cloud world is different from that of legacy IT. It might not be as familiar to folks working in cybersecurity as it is to DevOps teams, but if you’re in charge of securing these new computing environments, it pays to understand the thought processes behind those who made it.

This isn’t about one side – the pets or the cattle – being intrinsically superior to the other. It’s about how they are different. Pets are precious animals we name and care for and spend a great deal of time and money on keeping healthy. Cattle are more numerous, but anonymous. If they are diseased we are more likely to get rid of them and start again than spend significant resources patching them up.

In this context, most of IT started out as pets. These are the business-critical servers manually built and managed (or “hand-fed”). They could handle a variety of tasks, from transaction processing mainframes to databases or web servers. However, with the cloud came the idea of computing resources we treat more like cattle. To host those critical applications, organizations are now just as likely to rent a herd of virtual machines from a third-party provider as hand-build and manage them in-house. CFOs love the fact that, not only can they be scaled up to cope with surges in demand, but they can also be scaled down at quiet times, saving significant cost.

What this means

As per the analogy, we also treat these machines differently. Cattle don’t have specific names but a string of non-descript numbers and letters. As Bias says, they are “designed for failure, where no one, two, or even three servers are irreplaceable” and “no human intervention is required” to restart servers or replicate data. It’s all about ensuring that every server could fail without bringing the system down.

In a security context this means treating cloud servers like cattle. If there is a problem, dispatch and replace the animal (i.e., spin up a new container image) rather than personally take it to see the vet (apply a patch). It’s important to remember, however, that this isn’t about transitioning to a new world where all IT operates under this “cattle” model. There will always be a few machines that are so precious to the business that they should be treated as pets, both by DevOps and by security. That makes knowing which resources are the pets, where they are, and their condition are still vitally important.

Herding problems

In this new world of pets and cattle, there are challenges for security teams everywhere. The first is the extra complexity this bifurcation of IT brings about — and complexity is usually the enemy of security. This means you need to learn the language of DevOps to provide an effective service to internal stakeholders today. Industry skills shortages now top more than four million positions globally, including 561,000 in North America alone — putting extra pressure on existing teams to broaden their skills sets.

This is easier said than done. On training days, security professionals are confronted with a barrage of new terminology, and ways of doing things that, counter-intuitively, may seem far from the seamless or “modern” experiences promised by DevOps. They don’t run DevOps CI/CD pipelines every day and find it challenging to understand the concept of herding anonymous servers round someone else’s virtual ranch. The learning curve is made that much steeper thanks to cultural resistance in many organizations: institutional memory built on decades of processes and procedures that work in the old way. Colleagues on the physical networking side may want to stay completely out of the whole cloud conversation.

Security teams may also find that the benefits of a “cattle” approach are predicated on their ability to correctly configure each and every farm holding these resources. Unfortunately, doing so for all the thousands of VPCs, clusters and namespaces an organization may be running is anything but straightforward. One report out recently claims that cloud misconfigurations cost global companies an estimated $5 trillion in 2018 and 2019. Without the right tools, there’s plenty of room for error, especially among mature organizations with a mix of pets and cattle, and large farms to manage.

Going further

Security teams may also be challenged by the new architectures that the cloud world ushers in. Anyone with a new pet at home knows to put up a baby gate to contain the mess that comes along with new-born animals.  But when the traditional IT “pets” move out to the cloud, now where do you put the baby gates – the firewalls, IDS/IPS sensors, DLP detectors, etc? When you don’t control the network fabric, it’s harder to build network segmentation. This is where micro-segmentation can help to monitor east-west threats, and “SaaS-y” cloud-based identity services can put controls between users and sensitive data.

Things move pretty fast in tech. Although DevOps teams have been talking about pets and cattle for some time, the analogy has expanded even further to include chickens (containers), insects (serverless architectures) and even snowflakes (servers requiring individual configuration). The good news is that, in the nascent serverless era, where location is held to be irrelevant, there may be benefits you can leverage to enhance protection. In traditional systems you would need a dedicated server and comms in and out, which presents a significant attack surface for an attacker. But in serverless, you break a small part of compute off, hand it to a provider and if you don’t need admin access and don’t know the location then it also becomes difficult for the bad guy to find it.  All you do is say “run this job, reading data from this store, and writing to that one”.  Now the security team can focus just on the data – which is generally what we want to protect – and can pay less attention to where and how the compute happens, because that is now moved out of sight for everyone, friend or foe alike.

Just remember: in the DevOps world, “shifting left” is important, but it won’t solve all your security problems. It will ensure the house is built from higher quality bricks, but that’s not all it takes to get a high-quality house. Only holistic visibility into the network will check for structural integrity, and ensure that if something goes wrong, you’re alerted straightaway.

Dr Mike Lloyd, CTO, RedSeal