Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

5/28/2019
10:30 AM
Andrew Williams
Andrew Williams
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

'Cattle, Not Pets' & the Rise of Security-as-Code

Nearly a decade in, the famous analogy has underpinned a sea change in enterprise IT, but still falls short of the security mark. More recent developments can help.

In 2011, Randy Bias, a prominent member of the cloud community, used the phrase "cattle, not pets" as an analogy for how DevOps engineers should think about the cloud and the benefits of managing infrastructure in a cloud-native environment. The phrase "cattle, not pets" (attributed originally to Bill Baker, a Microsoft distinguished engineer encouraging his DBA audience to think differently about their SQL Server deployments) has become pervasive within the DevOps community and is a useful way to think about the difference between a dynamically scalable cloud deployment and a more static on-premises server rack. Once the description was applied to the cloud, it was adopted across the IT community, showing up in sources as varied as Amazon webinars and CERN presentations.

Although the concept has contributed to the cloud design principles of thousands of DevOps engineers across the industry, the analogy is imperfect. Treating servers as "cattle, not pets" without broader strategies to implement security eliminates concerns about resiliency and initial server configuration, leaving the proverbial door wide open for unanticipated access issues, malicious intrusion vectors, and other security threats and vulnerabilities that have been prevalent since well before the cloud concept was mainstream.

Enter the many different flavors of infrastructure-as-code. There are many ideas about planning for DevOps, and the benefits of the overall infrastructure-as-code movement: numerous papers on the "cattle, not pets" approach; dissertations on the broader notion of replicability, rigor, scrutiny, as well as inherent security that come from code-based implementations of infrastructure; sales briefs on the benefits of being able to model infrastructure changes without time-consuming and costly mock-ups in a manually configured staging environment; and so on.

The concept of using code-based policies to impose consistent security on a broader IT environment is not new in IT or the cloud. However, minimizing security risks with comprehensive security-as-code in a way that almost entirely removes the need for any manual interaction is a relatively new practice — as is the prioritization of security principles when DevOps teams consider how to configure code-based policies to manage their own environments.

This doesn't mean the industry isn't addressing the practice. Companies including Puppet, Chef, Red Hat, AWS, IBM, and many others offer rich tool sets that are intended to ease the transition from traditional IT practices and DevOps approaches to security in favor of the DevSecOps approach to infrastructure management — and DevSecOps appears to be on its way to becoming the new normal.

Opportunity for Change
The broader implications of the DevSecOps mindset for the governance of security and compliance have been relatively underappreciated until recently. The industry now has an opportunity to shift the focus of security and compliance scrutiny from the live environment to a code repository, greatly increasing the assurance possible in any security review and simplifying the methodology required by any external auditor tasked with verifying the compliance posture of a given environment. Prominent cloud providers are releasing verified reference architectures that, if implemented without any security-impacting changes, provide compliance with any number of prominent security and regulatory frameworks their customers may encounter. An entire cottage industry has formed around the idea that security can be written instead of implemented. While not as prominent as the overall infrastructure-as-code movement, comprehensive security-as-code could be truly transformative for organizations building in the cloud.

If done carefully, true security-as-code has many benefits. Budget-conscious executives can mandate code-based security policies to minimize the large amounts of time, money, and effort traditionally required to properly deploy and vet a mature security posture. System owners can remove the human from the loop in all but the most esoteric of management actions — minimizing the risk of some of the most prominent malicious intrusion vectors seen today and virtually guaranteeing consistent implementation of security controls and policies. Architects can mock up their selected controls, service-level agreement obligations, and performance targets without delay and quickly iterate through options before allocating any resources to a test deployment.

Companies working to bring software products to market in heavily regulated industries can reduce their time to compliance — even across multiple frameworks at once — as they are only limited by the speed at which their developers can type, instead of the long lead times traditionally expected between development, assessment, and remediation. Undermanned DevOps teams can confidently reuse and recycle security policies and assets between environments without worry about customization or loss of fidelity, easing the pain of frequent requests for segregated resources or low-level tenant-by-tenant isolation.

And finally, interested reviewers and external auditors can be confident when assessing the security assurance provided by a heavily automated and code-based IT environment. Focusing such a review on a code-based architecture implemented throughout the scope of a given review reduces the chance that, somewhere, in some far-off closet, sits a critical server still being treated as a pet.

Related Content:

Andrew Williams is the Director of Program Development at Coalfire. In this role, he is responsible for working closely with Coalfire customers, industry bodies and regulatory authorities, and internal stakeholders to ensure Coalfire's services, delivery, and talent are ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Florida Town Pays $600K to Ransomware Operators
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/20/2019
Pledges to Not Pay Ransomware Hit Reality
Robert Lemos, Contributing Writer,  6/21/2019
AWS CISO Talks Risk Reduction, Development, Recruitment
Kelly Sheridan, Staff Editor, Dark Reading,  6/25/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-10164
PUBLISHED: 2019-06-26
PostgreSQL versions 10.x before 10.9 and versions 11.x before 11.4 are vulnerable to a stack-based buffer overflow. Any authenticated user can overflow a stack-based buffer by changing the user's own password to a purpose-crafted value. This often suffices to execute arbitrary code as the PostgreSQL...
CVE-2019-11583
PUBLISHED: 2019-06-26
The issue searching component in Jira before version 8.1.0 allows remote attackers to deny access to Jira service via denial of service vulnerability in issue search when ordering by "Epic Name".
CVE-2019-4234
PUBLISHED: 2019-06-26
IBM PureApplication System 2.2.3.0 through 2.2.5.3 weakness in the implementation of locking feature in pattern editor. An attacker by intercepting the subsequent requests can bypass business logic to modify the pattern to unlocked state. IBM X-Force ID: 159416.
CVE-2019-4235
PUBLISHED: 2019-06-26
IBM PureApplication System 2.2.3.0 through 2.2.5.3 does not require that users should have strong passwords by default, which makes it easier for attackers to compromise user accounts. IBM X-Force ID: 159417.
CVE-2019-4241
PUBLISHED: 2019-06-26
IBM PureApplication System 2.2.3.0 through 2.2.5.3 could allow an authenticated user with local access to bypass authentication and obtain administrative access. IBM X-Force ID: 159467.