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 [1], whose well-constructed ReadMe file [2] 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.

The 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 later on, I point you toward a number of vanilla examples.

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 [3] or GitLab CI [4]), 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.

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" [6]; each plain text file ends with the .attack extension. Listing 1 shows the general 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.)

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, this excellent tool's output 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.

Trust
    Hostname Validation:             OK - Certificate matches www.devsecops.cc
    Android CA Store (8.1.0_r9):     OK - Certificate is trusted
    iOS CA Store (11):               OK - Certificate is trusted
    Java CA Store (jre-10.0.1):      OK - Certificate is trusted
    macOS CA Store (High Sierra):    OK - Certificate is trusted
    Mozilla CA Store (2018-04-12):   OK - Certificate is trusted
    Windows CA Store (2018-04-26):   OK - Certificate is trusted
    Symantec 2018 Deprecation:       OK - Not a Symantec-issued certificate
    Received Chain:                  www.devsecops.cc --> Let's Encrypt Authority X3
    Verified Chain:                  www.devsecops.cc --> Let's Encrypt Authority X3 --> DST Root CA X3
    Received Chain Contains Anchor:  OK - Anchor certificate not sent
    Received Chain Order:            OK - Order is valid
    Verified Chain contains SHA1:    OK - No SHA1-signed certificate in the verified certificate chain
  Extensions
    OCSP Must-Staple:                NOT SUPPORTED - Extension not found
    Certificate Transparency:        WARNING - Only 2 SCTs included but Google recommends 3 or more
  OCSP Stapling
                                     NOT SUPPORTED - Server did not send back an OCSP response
* OpenSSL Heartbleed:
                                     OK - Not vulnerable to Heartbleed
* ROBOT Attack:
                                     OK - Not vulnerable
SCAN COMPLETED IN 9.97 S

The end of Listing 3 shows how long the query took to run – a smidgen under 10 seconds, in this case.

For the curious, according to the SSLyze docs, the Trust Stores Observatory [7], which "… monitors the content of the major platforms' root certificate stores," contributes to the SSLyze trust certificates.

A weekly check of various vendors and for the certificates used on their devices means you can be confident you are dealing with current information.