A CREWS Q&A with NuHarbor Security CEO Justin Fimlaid
A central finding of our work on this year’s SLED CPR is the widespread shift towards increased collaboration and information sharing among the SLED community.
NuHarbor Security founder and CEO Justin Fimlaid has been working with multiple SLED organizations on developing a structured approach to information sharing, particularly focused on threat intelligence and defensive recommendations. He’s calling it CREWS, short for Cyber Resilience Early Warning System, and its intent is to provide a consistent means of sharing visibility into new threats with the added benefit of a common language: protection. More than a reactive tool for threat hunters searching out IOCs, CREWS is built to deliver both the identifiable characteristics of a threat in action and specific recommendations for how to avoid becoming a victim of that new threat in the first place.
We sat down with Justin shortly before publication.
In your work over the last several years, you noticed the need for a style of early warning system that doesn’t exist in the security market today. Can you tell us what the discovery process was like for you and what led you to think something more was needed?
I see it as an evolution of need. Hearing clients talk about their different concerns, I realized that many of those pain points could be addressed with the tools that are already available to us but repurposing them to create a different outcome. The concept of CREWS evolved from the realization that simply reacting to threat intelligence isn’t enough. Clients told me they wanted to know about the risk from these threats before an incident occurred, before they could create the effects that would allow them to be detected. They didn’t want to be in the position of detecting threats after they had already gone to work.
Looking at the data, we had all the information we’d need to predict if or when a security event might occur.
So, your premise was that you could put another lens on existing data to draw conclusions that would prevent attacks that hadn’t yet occurred?
My theory was that we could use our data to perform a function more like an early warning system for tornados, and less like FEMA cleaning up after an event. We could use threat intelligence to be proactive instead of just reacting to the information. We need warnings that give us the heads up that something’s about to happen so we can preserve assets.
The way that you position threat intel in describing CREWS, it sounds as though it’s more than just a warning that something’s coming. It’s a warning that something’s coming and specific guidance based on what you’ve learned. Help me understand how you see that information-getting developed so that it arrives as more than just a siren going off.
With the early warning comes recommendations for how subscribers can strengthen their position. Because they can’t run away from the threat – it’s out there, it’s going to happen. So, with those recommendations comes the signature of the attack and the list of indicators of compromise. Many possible proactive steps exist to disrupt a threat that may be coming. Knowing that these threats exist and what events can happen accordingly, we can be proactive in our use of the technology we already have in place to prevent damage from occurring.
Early warning evokes a sense that these threats are new, being seen for the first time. How do you envision being able to separate a breach or known attacker from something brand new that’s just happening?
It’s a function of threat intel and how it’s used. Sure, there’s information sharing that exists, but it hasn’t been used to identify brand-new attacks or make new recommendations. No one’s taken that direction, mainly because no individual organization has the motivation to care that much.
CREWS enumerates all the reasons you should care. Now there are emotional reasons to share and prevent events from happening. CREWS proposes a fundamental change in information sharing that drives these specific outcomes to actually help people.
Download the full report for more on leveraging CREWS to communicate urgency around threat protection.
Many sources of threat intelligence provide updates. But you suggest that with CREWS, threat analysts are far better off. Can you help me understand why CREWS is a better idea than trying to orchestrate these other sources independently?
Sure. We live in a security environment where threat intelligence is stale and outdated after 36 hours. Threat intel is circulated extensively; it’s shared, but that doesn’t make it good. In the new model, there’s a combination of understanding wide-scale security monitoring and attack simulation competency. Here’s an example:
Let’s say an organization is the first to see a new credential stuffing attack on a web or edge application. For anybody unversed in attack simulation, clearly translating the characteristics and path of that event to others is somewhere between challenging and impossible. Once the attack succeeds and there are obvious signs, it’s much easier; any trained observer will know how to detect it, but that isn’t what organizations need. They want a recommendation for how to block it from occurring in the first place. Someone with simulation experience can do that and suggest means of closing gaps going forward.
This is how CREWS improves detection, but more importantly, how to block the attack so you won’t have to worry about detecting it. That’s the shift that needs to occur. CREWS empowers subscribers to move from a reactive position to a proactive, preventative position that will preserve their assets and their integrity.
For organizations that are first hearing of CREWS through the CPR, what are the concrete benefits you’d expect a participant to receive that would justify joining?
They’ll get timely, expert intelligence on threats that have a proven likelihood of occurring. They’ll gain situational awareness so they can protect themselves. There will be fewer surprises and less blindsiding. They’ll also get a type of continuous, threat-based, contextualized risk assessment. With CREWS, you see risks that are meaningful to you; your assessment doesn’t change when new attacks evolve that can’t affect you. Subscribers get the recommendations we’ve been talking about. This won’t be something they can create themselves, even if they were staffed and trained for it.
The SLED CPR is the first place where CREWS is being discussed at this level and in a very public way. What’s next in the development and delivery of CREWS to fulfill your vision?
The more participants that contribute to CREWS, the smarter it becomes. It’s an intelligent system, and the machine learning that exists within that system only gets smarter with more data that we feed it. In my vision, if we had the entire country participating – every state, city, county, and college – we’d have unprecedented visibility for malicious activity nationwide. That’s a pretty high bar, though. In the meantime, there’s an emerging version of CREWS for state and local municipalities that are short-staffed, organizations that aren’t equipped to understand and make changes even if they receive the recommendations. We’re also developing an appliance that will sit on the edge, or within an organization, and tell you exactly how an incoming CREWS message or recommendation applies to you. This device will run benign versions of CREWS campaigns so that organizations can see exactly what would happen, allowing them to find the support and resources that they need. For the first time, they will be informed of the newest threats, made aware of the potential impact, and empowered to go and tell that story to drive change.
For a look at the full interview, and more on how CREWS will empower advanced threat protection, download the full report.