If you are reading this, you probably got sucked into watching Game of Thrones when it first aired on HBO in 2011. It is amazing how much has changed since the eight seasons of the original series. Now that the new prequel series House of the Dragon is out, I find myself revisiting the first series, as I’m sure many of you have. Say what you will about the finale, but as a developer and security guy, I find the Night’s Watch story to still feel relatable all these years later. And watching it now, I find there are some key parallels to the world of DevOps and cybersecurity.
For those that don’t remember, the series debuts with the men in black – a.k.a. the Night’s Watch – patrolling the wall. Soon we learn that, contrary to popular belief, there really are supernatural threats lurking in the darkness that put all of Westeros at risk.
The Wall that the Night’s Watch is guarding is the only thing standing between the country of Westeros and the deadly White Walkers. However, rather than immediately getting all the resources they need to tackle this danger, the people of the Night’s Watch spend the entire series convincing the rest of Westeros that these threats are real and that leaving the Wall woefully understaffed and poorly defended endangers everyone.
As the dramatic series unfolds, we see lots of lip service paid to how important the work of the men in black is, but we also learn that most people actually doubt the seriousness of the threats beyond the wall. They view joining the Night’s Watch as a punishment instead of an honor because the White Walkers haven’t attacked in a long time.
During my rewatch of Game of Thrones, I noticed an interesting correlation between the Night’s Watch and how DevOps security is perceived. I have worked in the cybersecurity space all of my career. During that time, no one has ever said that security isn’t important, but I have found that other concerns are often prioritized over security or that organizations try to get away with using only the minimum amount of security. Inevitably, this attitude changes once a breach occurs. Something I’ve noticed in recent years is how sparsely populated security-related technical advisory groups (TAGs, formerly called SIGs) are in relation to others. That is when I started to think about the Night’s Watch Oath and realized that sharing these parallels could help organizations commit more resources to protect themselves before the White Walkers are at the wall.
For those of you who didn’t watch the show or don’t remember, here is a recap of the oath.
The Night’s Watch Oath
“Night gathers, and now my watch begins. It shall not end until my death. I shall take no wife, hold no lands, father no children. I shall wear no crowns and win no glory. I shall live and die at my post. I am the sword in the darkness. I am the watcher on the walls. I am the shield that guards the realms of men. I pledge my life and honor to the Night’s Watch, for this night and all the nights to come.”
The essence of the oath is honor, duty and sacrifice, but not in the name of glory or monetary reward. For the brave men of the watch, protecting the realm is its own reward. If you’re a developer in the cybersecurity space you can almost certainly relate to this – without all the overly-dramatic sacrifice, of course. If you are a security developer, you’ve probably worked on several products that most people have never heard of, even though they have benefited indirectly from your labor. This work helps protect ATM transactions, bank transfers, credit cards and other sensitive information and secrets. If you are like me, you’ve stopped telling people exactly what product you’ve worked on during casual conversations and instead tell them how they benefit from the unseen sword in the darkness, the watcher on the wall of cybersecurity – whether that’s by protecting their personal data from being stolen or defending critical systems against ransomware attacks.
There isn’t as much glory or recognition in cybersecurity work as there is working on the newest Madden NFL game or an iPhone app, but people benefit just as much, if not more. Although, with all the ongoing stories of credit card breaches, stolen personal data, healthcare IT and city infrastructure held hostage to ransomware – we’re getting a lot more awareness.
Why DevOps Security Needs a New Oath
As with all things DevOps, the goal is velocity, but you still need to take into account protecting your realm (organization) from White Walkers (attackers). There is an unspoken understanding or oath between developers and cybersecurity teams, but it’s not widely adopted. This agreement between developers and security should facilitate understanding and increase productivity while mitigating risk. Let’s face it, a massive breach will set back velocity much more than working in developer-focused security policies at the start of the software development lifecycle (SDLC) – shifting security left. So let’s update the Night’s Watch oath for a modern DevOps organization.
The DevOps Security Oath
“Ransomware, phishing attacks, malware and security breaches gather, and now my watch begins. It shall not end until the realm is free from cybersecurity threats – never. I shall work with my developer and DevOps teams to understand their needs and work to adapt them to organization security policies. We will shift security policies to the left to work more efficiently and securely. Together, we shall win glory and beat back the threats to our realm. We are the sword in the darkness. We are the watchers on the walls. We pledge our lives and honor to the Night’s Cybersecurity Watch, for this night and all the nights to come.”
The White Walkers of DevOps – Threats
Now that developers and security teams have stopped warring like the inhabitants of Westeros during the War of the Five Kings, let’s focus on the threats to the DevOps realm, a.k.a. our own personal White Walkers. DevOps encourages integration and automation among software developers and IT operations (DevOps teams) to improve the speed and quality of software delivery. However, software automation requires secrets, lots of secrets.
Secrets in many different forms are necessary to allow autonomous processes to talk to each other, access code repositories, spin up virtual machines (VMs) and containers in cloud environments, etc. These secrets literally hold the keys to the kingdom, and they are often stored in GitHub, Jenkins, applications, configuration files and other insecure places. This can lead to an attacker gaining access to sensitive customer information, credit card information, proprietary information or more secrets – breaking through the Wall and spreading the breach. Take a look at the infographic below for more details on the attack flow, and we’ll walk through it more after the jump.
Looking at the infographic, you can see the DevOps realm is divided into two kingdoms – the Dev Kingdom and the Ops Kingdom – but a risk to one kingdom impacts both kingdoms.
A developer lord pushes code to Castle GIT that contains the keys (secrets) to Database (DB) Tower. This code, and the DB Tower secrets, is now accessible to everyone with access to Castle GIT, potentially exposing all of the knights’ credit card information.
Castle Supreme Jenkins is at the center of your DevOps pipeline, requiring a lot of secrets to access sensitive resources. By gaining control of Castle Supreme Jenkins, an attacker can gain access to other castles and towers within the realm, compromising everything within both kingdoms.
Protecting Your Realm
The good news is that there are open-source tools that can help you mitigate the risks to your realm and control who has access to the keys to your kingdom. As we saw in Game of Thrones, a giant wall isn’t the best means of defense, because walls get breached. The best way to stop the lateral spread of a White Walker attack or a security breach is to control who has access to the secrets and limit the amount of privilege to knights and lords (or ladies) with RBAC.
An open-source centralized secrets management solution like Conjur provides a holistic view of exactly who has access to what and keeps secrets out of code, configuration files and tools like Jenkins, Kubernetes, Ansible, Puppet, Terraform and so on. This makes it easier to enforce RBAC polices, provision or revoke access, audit access and authenticate requests.
Want to learn more? Check out these additional resources:
- Remove secrets from Jenkinsfiles and Jenkins with the Conjur plugin tutorial.
- Learn how to use Conjur to implement RBAC for secrets in Kubernetes clusters.
- New to using Conjur Open Source? Try our new quick start.
- Looking for an enterprise solution? Check out Conjur Secrets Manager Enterprise.
Throughout the Game of Thrones series, the Night’s Watch is both mocked and praised in a disingenuous tone for their important work. Don’t be fooled into thinking DevOps security isn’t important enough to prioritize or to invest the right resources from the start. Don’t wait until the White Walkers are at the Wall.
John Walsh has served the realm as a lord security developer, product manager and open source community manager for more than 15 years, working on cybersecurity products such as Conjur, LDAP, Firewall, JAVA Cyptography, SSH, and PrivX. He has a wife, two kids, and a small patch of land in the greater Boston area, which makes him ineligible to take the black and join the Knight’s Watch, but he’s still an experienced cybersecurity professional and developer.