Get My Score


AWS suffers outage

With increasing reliance on the cloud, and in many cases on a single cloud service provider, the probability for a widespread (though infrequent) outage grows.  On Tuesday, AWS S3 storage experienced a major outage, taking down the back-ends of many sites that include Netflix, Slack, and HubSpot, two of which we use at Cavirin.  For enterprises that were single threaded, they just had to wait it out, and though the actual outage lasted only 4 hours, it took the remainder of the day for many to recover.  To give you an idea of the magnitude of the impact, AWS S3 supports over 150K sites and upwards of three trillion data elements.  Thousands of tweets were questioning if the Internet went down, just like last October with the Mirai outage.  Compounding the problem is that the storage service is shared across multiple AWS zones, and though an enterprise may distribute compute across geographies, due to practical or cost reasons they may depend upon a single storage instance. 


This week yet another Linux vulnerability was discovered - CVE-2017-6074 – that could be exploited to gain kernel code execution from an unprivileged processes. The vulnerability is associated with the DCCP protocol.

The DCCP protocol is recommended by the security benchmarks to be disabled to reduce the attack surface. 

DISA RHEL 6 STIG reads “Disabling DCCP protects the system against exploitation of any flaws in its implementation.

The CIS Security Benchmark for Debian 8 reads “The Datagram Congestion Control Protocol (DCCP) is a transport layer protocol that supports streaming media and telephony. DCCP provides a way to gain access to congestion control, without having to do it at the application layer, but does not provide in-sequence delivery. If the protocol is not required, it is recommended that the drivers not be installed to reduce the potential attack surface.

Cavirin’s solution automates the assessment of these security baselines in your hybrid cloud. It continuously protects you from vulnerabilities arising out of misconfiguration and such zero-day vulnerabilities arising out of default attack surface. Vulnerabilities such as these do not really bother you if you used the solution to detect the presence of such uncommon network protocols and already reduced the attack surface by disabling them all together if not in use. You cannot really protect what you don’t see and Cavirin’s solution helps you with security evidence, audit reports, and operational procedures instead of verbal security assurances and recommendations.


Last night I had the pleasure to attend a panel hosted by the EC Council on insider threats.  Panelists included the CISO from San Francisco, the VP of Systems from Macy’s, and most interestingly, Eric Snowden’s former boss at Booz Allen Hamilton.   All three were covering various aspects of the STRIDE model.   For example, the crisis that SF ran into about 8 years back, where a single employee held the city network hostage by collecting router passwords, was a combination of disclosure and elevation.   It took the mayor, at the time, to diffuse the situation.

The NSA suffered the same, with Snowden, in the first week of his new assignment in Hawaii, requesting passwords from colleagues and spending off hours on-site.   More damaging, it is rumored but not confirmed that his credentials from his former IT role were not revoked.   This, married up with his new access to higher levels of classification, created an opportunity.    And it is never a single issue.   His CIA HR records, if shared with the NSA, which they were not at the time, would have raised additional flags, and at the time, employees were not subject to daily exit searches, providing him with the opportunity to exit with his USB dongles.

Left to Right - 

Steven Bay, former boss of Eric Snowden

Joe Voje, CISO, City of San Francisco

Brian Phillips, VP, Macy’s Systems and Technology

And, Macy’s was the first to admit that their procedures in place to address insider capture of PCI data were not up to snuff.   They are now, and just recently the company has taken a very aggressive approach on limiting data access as part of their announced store closures, since there is an interim period where employees have been notified but are still employed.

Net-net, the last decade has been a learning experience, across both commercial and government, but with increased focus, awareness, and sharing of best practices, we’re making progress.



The CISO is under immense pressure, expected to manage a dozen or more vendors across perimeter, endpoint, network, application, and data security, not to mention having to be an expert on policy and operations.  Hackers in many cases have the upper hand, and the human element is still the weak link. 

Because of this, more and more enterprises are realizing that what we offer to automate some of this is no longer a nice-to-have…. It is a must-have!   At the same time, we’re able to clearly show our differentiation from the vulnerability assessment vendors, and we are more versatile than the cloud-only solutions.  Look at it this way, best articulated by one of our customers, Cepheid.  VA will tell you how many windows and doors you have, and which are open.   We take the next step, and tell you how to close them.  And, if you are so inclined, we’ll do the closing.  

The API-first architecture of our new Pulsar platform was also top of discussion, with potential ecosystem partners realizing the need for a unified view of overall security compliance, be it server, endpoint, identity, or vulnerability, and across all clouds and containers.  If you missed it, check out our Pulsar General Availability PR.  In all, a more than successful first day for Cavirin’s first RSA presence, based on both the quantity, and more importantly, the quality of discussions and demos. 

(Breaches photo from SS8 shirt at RSA - thanks!)








First of a multi-part series on the CIS benchmarking process, by Pravin Goyal.


What are CIS Benchmarks?

The CIS Security Benchmarks program provides well-defined, un-biased and consensus-based industry best practices to help organizations assess and improve their security. The Security Benchmarks program is recognized as a trusted, independent authority that facilitates the collaboration of public and private industry experts to achieve consensus on practical and actionable solutions. Because of the reputation, these benchmarks are recommended as industry-accepted system hardening standards and are used by organizations in meeting various compliance requirements such as PCI and HIPAA.

What is the typical CIS benchmark development process?

CIS Benchmarks are created using a consensus review process comprised of subject matter experts. Consensus participants provide perspective from a diverse set of backgrounds such as consulting, software development, audit and compliance, security research, operations, government, and legal. Each CIS benchmark undergoes two phases of consensus review. The first phase occurs during initial benchmark development. During this phase, subject matter experts convene to discuss, create, and test working drafts of the benchmark. This discussion occurs until consensus has been reached on benchmark recommendations. The second phase begins after the benchmark has been published. During this phase, all feedback provided by the Internet community is reviewed by the consensus team for incorporation in the future versions of the benchmark.

What does it take to develop a new benchmark?

It is easy to contribute to CIS benchmarks. Just write to the CIS community program managers with your proposal for addition. The respective program manager will respond to you followed by a call to understand your proposition and discuss timelines, project announcement and project marketing to attract community participants. With some internal approvals, the project is created in around two weeks of time.

How long does it usually takes to develop a new benchmark?

It usually takes around 12-24 weeks based on the number of participants in the community and the size of the project.

Who else is providing security benchmarks like CIS does?

I would say none. CIS provides the broadest set of benchmarks covering both software and hardware. These include databases, operating systems, applications, mobile operating systems, firewalls, browsers, office applications and almost anything else that touches IT. The only other agency that provides a subset of the benchmarks is DISA. Also, sometimes vendors provide security documentation in the benchmark format. For example, VMware provides a VMware vSphere hardening guide for securing vSphere deployments.

How can we contribute?

Join the existing CIS communities. It is exciting and challenging, and you will get to work with amazing people.

How do we implement CIS benchmarks in our product?

You have two ways to implement CIS benchmarks. The first one leverages the content directly from CIS. The second method is to develop your own proprietary content to implement the benchmark.

Tell us a bit about CIS Docker and CIS Android benchmarks?

Both CIS Docker and CIS Android benchmarks have fascinating community members. I had the privilege to work on both as an author. One thing interesting to note is that CIS Docker benchmark exists from Docker version 1.6.  At that time not many people knew Docker or Docker security. But, the community did an amazing job by documenting 84 security recommendations! That is the power of community.  I'll cover Docker and Android in more detail in a future segment.



Docker yesterday released Version 1.13 and today, we are announcing the release of CIS Docker 1.13 Benchmark, with Cavirin as a key contributor. The CIS Docker community has worked extremely hard to ensure that the time lag between the software availability and security recommendations is almost zero, a leading example of the concurrent availability of security guidance with implementations.

Download your copy from the CIS website.

The changelog between CIS Docker 1.12 benchmark and CIS Docker 1.13 benchmark is as follows:

Rules added with the Docker 1.13 benchmark

  • 2.19 Encrypt data exchanged between containers on different nodes on the overlay network
  • 2.20 Apply a daemon-wide custom seccomp profile, if needed
  • 2.21 Avoid experimental features in production
  • 2.22 Use Docker's secret management commands for managing secrets in a Swarm cluster
  • 2.23 Run swarm manager in auto-lock mode
  • 2.24 Rotate swarm manager auto-lock key periodically

Rules modified from Docker 1.12 benchmark

  • 2.8 Enable user namespace support - Updated Audit Procedure
  • 2.5 Avoid container sprawl - Updated Remediation and Audit Procedure
  • 2.3 Keep Docker up to date - Re-worded

Rules deleted in the Docker 1.13 benchmark

  • 1.2 Use the updated Linux Kernel
  • 1.3 Remove all non-essential services from the host

It is easy to understand new additions to the benchmark given the pace of innovation at Docker and the energetic community behind it. But, you might be curious to know why we deleted a couple of rules above?

CIS benchmark development is community-consensus driven. Every change to the benchmark is vetted for consistency, technical accuracy and alignment with current requirements in production.

Rule 1.2 has become obsolete given that most of the Linux distributions are now shipped with the updated kernel that fulfils Docker install kernel requirements. When Docker began, that was really an important thing to check for to run production workloads to ensure reliability.

Rule 1.3 is typically addressed in their respective CIS Linux benchmarks. Hence, this was a duplicate from other benchmarks and got deleted as well. CIS Docker benchmark provides core security guidance for Docker deployments and eliminates obsolete recommendations.

Cavirin Systems automatically scans container workloads against the CIS benchmark. Its agentless discovery mechanism quickly builds inventory of your Docker host instances and containers and runs a deep inspection against the entire CIS benchmark.

Check us out!


© 2018 Cavirin Systems, Inc. All rights reserved.