Security As Code

Special Thanks: This article was made possible by support from  Linux Professional Institute

When you add features to your software frequently, each iteration needs to be checked meticulously to iron out wrinkles before they cause more headaches further upstream in production. It should go without saying that a critical part of that testing process relates to security, and initiating as many (useful) tests as possible to catch anomalies and potential security holes can only be of great benefit in both the long and the short term.

One of the most satisfying of these security tools is Gauntlt, whose well-constructed ReadMe file provides the following description: “Gauntlt is a ruggedization framework that enables security testing that is usable by devs, ops, and security.” The learning curve is not particularly steep, and once you have written your security requirements as code, you should find the results are easy to read and refactor when changes are necessary.

That Gauntlt website also offers welcome news that 2018 marks “re-launching development efforts and building a community of practice.” Further information also encourages volunteering for the worthwhile cause of improving Gauntlt.

In this article, I will be firing some shots at existing systems to provide some simple security testing examples, and I point you toward a number of vanilla examples later on.

Run The Gauntlt

The powerful Gauntlt’s raison d’etre is to write security as code into your test suites (e.g., the ever-popular Travis CI or GitLab CI), which integrates easily with tools you might normally use manually. These tools might be used for database hacking, penetration testing, open network port probing, or analysis of an SSL/TLS connection configuration. On Gauntlt’s homepage, a brief list of just some of these tools is available, some of which I list in Table 1.

Table 1: Some Useful Security Tools Gauntlt Can Use

Why Did I Come into This Room?

If you’ve been around the block a few times or used open source security tools before, you’ll see that Gauntlt’s chosen integration tools are unfathomably useful. The Gauntlt website refers to these tools as “attack adaptors.” By adding Gauntlt’s powerful scripting language, your security-as-code can provide a consistent and predictable security posture.

In addition to integrating these flexible tools into your continuous integration/continuous delivery (CI/CD) process, you can automate the monitoring of your systems, dependent on your scenario.

Gauntlt’s scripts come in the form of “attack files,” and each plain text file ends with the .attack extension. Listing 1 shows the general structure.

Listing 1: Attack File Structure

# my.attack
Feature: Description for all scenarios in this file
  Background: ...
    Given ...
  Scenario: Description of this scenario
    When ...
    Then ...
 
  Background: ...
    Given ...
  Scenario: ...
    When ...
    Then ...

The attack files are nice and logical and should be pretty self-explanatory, but a quick word about the Background section before I proceed: You can intertwine some variables in this section. You might replace <hostname> with your website’s DNS www A record (e.g., I might use my website www.devsecops.cc ). You can also list multiple variables. Look carefully because these are present a little later in other examples.

As an aside, you are advised to keep the number of scenarios in a single attack file to a minimum. In the interest of simplicity, you should also make sure that the contents of one file, which might contain potentially varied scenarios, are closely related.

Travel Adaptors

Because Gauntlt simply has too many areas to explore, I’ll look at a few specific examples to get you started on your journey and whet your appetite to explore the tool further.

To begin, I’ll look at the powerful SSLyze, but without using Gauntlt. Before I set up Gauntlt, I’ll run SSLyze on its own to see what to expect from its output. One reason to do this first is that you always need the tools (the attack adaptors) installed before running them through Gauntlt. The following commands will get you started:

$ apt install python-pip
$ pip install --upgrade setuptools
$ pip install --upgrade sslyze

Notice that for my examples I’m using a Debian derivative (Ubuntu 16.04, but via Linux Mint); however, pip commands should work with Red Hat derivatives equally well. I hope simply replacing apt with yum will work, but I haven’t tried it.

To run the excellent SSLyze, execute the command:

$ python -m sslyze --regular www.devsecops.cc:443

As you can see in Listing 2, the tool makes many checks, including for the older and insecure SSLv2 ciphers and other encryption-in-transit issues. (If my memory serves me, SSLv2 was around in the mid-1990s courtesy of Netscape.)

Listing 2: Abbreviated SSLyze Output

SCAN RESULTS FOR WWW.DEVSECOPS.CC:443
 ------------------------------------------------------
 
 * SSLV2 Cipher Suites:
      Server rejected all cipher suites.
 
 * TLSV1_3 Cipher Suites:
      Server rejected all cipher suites.
 
 * Resumption Support:
      With Session IDs:                  OK - Supported (5 successful, 0 failed, 0 errors, 5 total attempts).
      With TLS Tickets:                  OK - Supported
 
 * OpenSSL CCS Injection:
                                         OK - Not vulnerable to OpenSSL CCS injection
 
 * TLSV1_1 Cipher Suites:
       Forward Secrecy                   OK - Supported
       RC4                               OK - Not Supported
   
 * SSLV3 Cipher Suites:
      Server rejected all cipher suites.
 
 * Downgrade Attacks:
       TLS_FALLBACK_SCSV:                OK - Supported
 
 * Deflate Compression:
                                         OK - Compression disabled
 
 * TLSV1_2 Cipher Suites:
       Forward Secrecy                   OK - Supported
       RC4                               OK - Not Supported

Unfortunately, the output of this excellent tool is too comprehensive to display in its entirety, so apologies (to the authors) for splitting up the output. Moving on to Listing 3, you can see which “trusts” are checked. Those with eagle eyes will spot that my website uses Let’s Encrypt certificates.