What's that mean? I'm betting that some of you are very familiar with DGA domains. The presence of DGA domains could mean that someone is attempting to perform command and control into the IP address. And it means that someones going to have to find out.
Why do you care? The companies we've been talking to are Aerospace supply chain companies between 50 and 1500 employees and they don't have the ability to defend themselves. They make things for the US Government --DoD, NASA, probably others, and a new regulation requires them to report these incidents through their prime contractor and to the government. That's good right?
Here's the rub: Very small companies generally have a part timer, or at best, one person handling IT. Mid sized companies, well, some at least some mid sized companies have a problem making the jump from being a larger small company to a small enterprise, and rarely have dedicated security people. And even in bigger companies, full visibility on the network, protecting from those who really want access into these Aerospace suppliers is really really hard. The biggest companies --the primes, have invested millions in creating processes to fix themselves. The smaller companies simply haven't built that into prior cost models, and as a result suffer the fate of the hamster on a wheel. They can't build new security until revenue supports it. And if revenue supports it, the staff is busy fulfilling the contract.
So, in an attempt to help some of the really small guys (50-1500) we partnered with a couple of Managed Security Providers to be able to drop sensors/protections in the network --basically, outsourced security. But most companies look for the low cost options first. They won't go to an MSSP. They go to open source. So... we experimented with some of the open source stuff out there.
For the last few weeks I've been running one popular security package in an offsite office... pfSense is a great little suite of tools --very powerful, but even in our very simple environment, pfSense (I tested with Suricata and Snort packages), running default rule sets (like most new security folks will) killed off the ability to visit key locations because we research and talk about bad things happening on networks. The string matching automatically assumes the site to be bad, and the sessions are killed off. So in these small companies (some are using Suricata and/or Snort), when they need customization of those rules because a CNC machine can't reach back to it's licensing library because the oddball port is blocked by a default rule. How long do you think that device will stay on the network when a machining operation is stopped because the CNC can't communicate over the network. Here's a hint... not long. And that IT guy that put it there? He just lost a whole bunch of credibility, and is going to have a heck of hard time convincing his boss to try it again next time.
But these suppliers MUST be able to detect bad things in their network. Many can not do it alone. Is there an answer? Of course. but some of these companies are asking for help in places that promise not to talk to their primes. Others are looking for DFAR assessments as an attestation that they're doing the right thing (the assessment is, at least a step in the right direction). Others are ignoring it, hoping it'll go away.
We have a solution. It's patent pending and being beta tested, but I'm doing demos at RSA next week. We've partnered with a cool little company called H2L to provide DFAR 800-171 and 800-53 assessments with companies in the Huntsville area.
As an output of this DFAR assessment, We recommend fixes as part of their get-well plan. We're can show the prime what risks to supply chain actually look like --in near real time. Contract officials have the ability to monitor threats to their suppliers. Suppliers have the ability to know the threats they face, and the IT folks or MSSP has the ability to react to current threats before they occur.
Have a great weekend.
See you in San Francisco!
Jeff
