Securing the Corelight Sensor

Have you ever considered how security tools can be a source of risk? They process untrusted data 24/7, have access to sensitive flows, and (like everything on the Internet) can be exploited if not patched regularly.  

At Corelight, we want our products to be a source of visibility and insight, not risk, and we’ve done a lot of thinking about how to secure them. In my first post, I’d like to take the opportunity to explain some of the techniques we use.

We work hard to limit the attack surface for each sensor.

Except for initial login over a physical connection, all access is disabled by default. Even after initial configuration, access is limited to SSH, HTTPS or the Corelight API (which uses TLS), according to the options you choose.  Each of these modes is password/key protected, and all disk volumes are encrypted.

Corelight’s user environment is sandboxed from the execution environment, and we use features in the Linux kernel to provide security isolation between major functional components. We don’t run Bro as root, a habit we’ve seen in many open-source deployments. Scripts run in a separate, security-isolated environment from Bro itself.  And we’ve implemented dozens of additional features for your protection, features we prefer to keep under the hood.

Third-party software requires special care, and we monitor and address vulnerabilities actively.  Fortunately, most CVEs don’t even apply to our products, because we strive to minimize the number of packages used.  In the spirit of transparency, we list resolved CVEs on the Corelight support site and announce high-profile CVEs on the public web site.  In addition, we call out high-profile but inapplicable CVEs on the customer support for extra assurance (i.e., the ones that hit the news, but we’re not vulnerable to).

Everyone knows that unpatched systems give rise to many breaches, and automatic updates are a real boon to operational security. The Corelight Sensor can of course help you find those unpatched systems on your network, but we’ve also made automatic updates simple and painless.  In fact, we default to automatically updating our software when new releases are available. Although we give customers configuration knobs to control when to apply updates, most of them choose to update immediately after each new release.  That’s good!

We also strive to be transparent.  It’s really disappointing when a partner you trust hides a potential problem from you. Responsible disclosure requires a careful balancing act, but it’s important for us to be as transparent as we can about risk – hence we will be posting to this blog and other customer-alerting mechanisms we employ including regular email updates / security bulletins.

Finally, we set high standards internally to protect our development environments and to shield you from third-party attacks or undesired leakage of information through your relationship with Corelight.  We’ll itemize those internal standards like code signing, peer review, security best practices for internal infrastructure, etc in an upcoming blog post. Stay tuned.

Please rest assured, we’re thinking about how to improve the security of our products constantly.