The Sword in the Darkness, the Watcher on the Wall
Join the DZone community and get the full member experience.Join For Free
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 during the eight seasons of the series, but, as a developer and security guy, I find the Night’s Watch story the most interesting. 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 guard 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 next seven seasons convincing the rest of Westeros that these threats are real and that leaving the Wall woefully understaffed and poorly defended endangers everyone. Hmm…sounds familiar?
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.
Watching Game of Thrones, I noticed an interesting correlation between the Night’s Watch and how DevOps security is perceived and found some potential lessons there. I have worked in the cybersecurity industry all of my career, and 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. I realized how similar this is to the plight of the heroes of Westeros, especially while I listened to Sarah Allen introduce the new CNCF cybersecurity SIG and saw how sparsely populated the room was. Sarah said that, while the security-related SIG isn’t as popular as others, it is still really important. 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.
You may also like: DevSecOps Trend Report.
For those of you who don’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. 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.
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.
If you drill down into the oath and take it more literally, you probably know a few cybersecurity nerds that have committed to “…take no wife, hold no lands, father no children.” I assure you that this is purely coincidental. Regardless, as with the crows (another name for the men of the Night’s Watch), we all benefit from their sword in the darkness. However, the oath and the Watch are a little too male-centric, so let’s agree that other genders and nerds are free to take no wives or husbands. Apologies on behalf of Westeros for being even further behind than George R.R. Martin’s next publication date.
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 risk (White Walkers). There is, at least, 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 on developer-focused security polices 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 polices 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 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, created by the CyberArk threat research team, 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 are now accessible to everyone with access to Castle GIT, potentially exposing all of a knights’ credit card information.
Castle Supreme Jenkins is at the center of your DevOps pipeline, requiring many 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 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.
- 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.
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.
Published at DZone with permission of John Walsh, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.