NSGit and the Ransomware World

Introduction

I seriously doubt there is a self-aware business leader who does not know about Ransomware, but do we really know what it is and how it came about? Simply put, Ransomware takes your assets and encrypts them with keys that you do not know. Over time, it gradually, and without you knowing, turns all your information into unusable garbage. The thing is, if this happened immediately, the problem would be obvious and not insidious.

Today’s DevSecOps operations require a repository tool like git to protect from malicious behavior as part of change-stream, and as a forensic research and recovery enablement tool during, and after an attack.

Keith Moore, a Distinguished Technologist for HPE NonStop

Ransomware depends on people not noticing that their assets have become encrypted; the reason ransomware is so dangerous. If you noticed as soon as it happens, you would restore your computer to a previous backup, and done. Problem solved. Sadly, it does not work that way.

This plague on IT hits every type of company, from the glaringly obvious (software development groups), to manufacturing and engineering drawings, to legal documents. Once in and hiding, there is little hope to stop the encryption, without an outside pair of eyes to protect you. Fortunately, the world has an impressive set of glasses you can put on to let you see your stuff with amazing clarity:

The world of git-based Distributed Version Control Systems, or DVCS for short.

Wait. What? “I’m not a software developer,” you might be thinking, and possibly adding “Yuck” to that with a little humour. In today’s world of EXCEL, SAP, CAD, and RESTful data, I have news for you: Yes, you are. So much of what we all do day-to-day has become software that we have lived up to Ronald Reagan’s prophecy of needing forty-four million programmers (ok, he said by the year 2000, so maybe a little late). Still, what does this all have to do with you?

Well, here is the good part: NSGit and git – the system used to develop the LINUX-operating system and billions of lines of software worldwide – translates your assets from the form on your server or desktop to something slightly different – a set of changes. As you change your source code, releases, production scripts in operations, documents, files, drawings, spreadsheets, or other assets, NSGit and git will take those changes and put them into a different form that the git ecosystem can detect, review, sign, and check. It happens as soon as you make the change too – or in the case of the scourge that is Ransomware, as soon as that malware encrypts your files. What this means is that if you get infected with a Ransomware virus, and it changes a document, NSGit is going to see the change to the file and tell you that there is a difference whether inside or outside of your repository. With just a little more automation, every change can be automatically scanned by your DevOps infrastructure for Ransomware patterns using commercial off the shelf (COTS) scanners using git hooks on the client and server systems to catch a broader set of infiltrations even earlier than when you run your checks.

It is all about translation. Files on your local NonStop machine may be subject to Ransomware, but once git translates them into a repository in your private or public Cloud, the Ransomware cannot touch them without being a detected change. If it does not appear to change to NSGit, it is not a change. Or quoting Spock:

A difference which makes no difference is no difference.

NSGit is not just for developers. It is also not just for engineers. It protects any of your system assets from accidental or improper changes by anyone for any reason. And as a side benefit, NSGit allows you to track your changes over time.

The Details on Catching Problems Early

There are many Ransomware/Malware scanners available on many platforms. Some might run on NonStop, but that is not a requirement for NSGit. The basic mechanism of connecting NSGit to a scanner is to either use the native git hook mechanism, or to add an NSGit Workflow, or a server-side custom method, like GitHub Actions.

All the mechanisms for plugging in to a scanner operate on similar principles. An action happens, like an NSGit or git add or push. When the action happens, the service runs a script supplying the stream of bytes (whether source, object, document, or some other artifact) and its name. The script can then run the scanner directly – if on platform – or via SSH to a service that hosts the scanner. Since SSH protects itself from man-in-the-middle attacks, it is a good mechanism to go off platform. If the scanner reports a problem, the scanner reports its findings to the terminal, and the operation fails. This provides a method of early detection of a corrupt file going into your repository.

There are many integration points where you can hook in scanners in the NSGit/git ecosystem to give you immediate feedback on whether code, documents, objects, etc., have problematic contents.

The Details of Long-Term Stability

To keep your artifacts stable in the git ecosystem, the most important addition to your processes is to sign your work using a strong cryptographic cypher. Signing allows you to establish a fixed point in time where your contents are stable and known. Convenient points to do this in your history are when you finalize a release and place a tag on it indicating the release name and version.

What this gives you is a signed tag, using GPG or SSH, or another cryptographic mechanism, which verifies that the content of your release is correct. This not only applies to the commit of the release itself but all of history that went into the creation of the release, collectively known as ancestor commits, all the way back to the first commit in your history.

If anyone, including SUPER.SUPER or another user with escalated privileges, modifies a file in your repository where git stores file contents, the signature if your release tag becomes invalid, effectively detecting that a corruption has occurred. A verification like this should run periodically, at least daily. If the tag is valid, your repository is valid. This is ideal for a production setting because you can continuously check the integrity of your production environment and if a file changes in the installation area, you can quickly recover the file using NSGit restore.

Protecting Your Entire Repository

One of the powerful benefits of git is being able to mirror repositories automatically. This allows git to completely copy the repository to another server potentially on a different operating system from the server side. So, if your post-push hook (the one that gets executed on the server after a push happens) verifies your signed tags, you can safely mirror your repository to another server as an immediate backup – this is a fast operation as only new commit contents and branch names and tags are copied. A post copy verification of the signed tags verifies the integrity of the mirror. You now have multiple safe copies of your intellectual property and releases git protects from Ransomware.

The above diagram shows how multiple repositories can exist on multiple platforms to protect from any one or two systems being compromised. The mirror or remote repositories can be used to restore (with full history, signatures, and audit trails) other repositories that have been corrupted.

Recovering from a Complete Repository Corruption

Even if SUPER.SUPER or root or some user or malware corrupts a repository on one platform, once you detect the situation by running a tag verification, you can just delete the corrupt repository and restore it from a good mirror – after you have removed the malware.

The point of using this ecosystem to protect your assets is that you have copies on other operating systems with strong cryptographic protection, fast recovery, and secure knowledge that you do not have to pay a ransom to get your DevOps assets back.