I have been involved in cybersecurity for 10+ years and have been in computers since the Epson days. Before I joined ThreatQ I was a Technical Solutions Architect at Cisco and spent most of my time there working internally on security education and supporting commercial markets.

Let me explain why this information is important (besides helping you guess at my age). During my time in cybersecurity I have seen A LOT of different installations and architectures.  I have seen all the horror stories, and most of the strangeness that is out there (can’t ever say you’ve seen it all). And with that time and experience, I’ve come to a realization: You cannot group security capabilities or maturity in a sizing model. Saying that X Fortune 500 or Fortune 50 company is more secure that Y Mom and Pop down the street is a complete fallacy. We have seen the evidence of this in the news for a very, very long time.

That’s because they each have a unique set of challenges that make security complex.

Large company positives:

More resources, usually more tools, and the name recognition to go and recruit the people they feel that they need.

Large company negatives:

A corporate identity and history, an expectation of how things get done that is easier broken then it is bent and most importantly resources or valuables that other people may want.

Small company negatives:

Fewer resources, usually fewer tools at their disposal and generally more difficulty getting top-tier talent.

Small company positives: A smaller footprint or perimeter to protect, an ability to be specific in their controls to protect what an outsider may be looking for, policies can usually be easily bent to handle scenarios when they come up and a single user focus can help on policy changes and updates with fewer processes to go through from a security stance.

How does this apply to “Simpler, not Simple”?

Whether a company is large or small, it is my belief that security can never be considered to be simple.

Well there is always this option:

Architectures 

If you look at any large security vendor today, they are all discussing one common theme.  A secured architecture speaking the same language, using the information from disparate security devices to update or augment the inherent protections found in each individual tool.

Sounds fantastic. That should really work well. If I rip and replace and buy all new of everything from a single vendor because I need the new shiny feature, I can get things that all play nice together. Sometimes.

But what if you could create your own architecture?  What if you could communicate through context and a common vernacular about what is occurring security-wise in your network to other users or other teams directly? It would allow Incident Response, Vulnerability Scan, Threat Intel, Endpoint, and Network Ops to speak the same language, to understand what is knocking on the door and how that is related to the call out seen on the endpoint, or even how it got in over an email attachment. Most importantly what if you could do all this with the tool set you already have?

There are certainly best of breed security products out there, usually several for the same task. The ultimate goal would be to select the right tool for the job at the right time.

In my previous post I spoke about to how we need to work a bit more to see the forest for the trees. I also promised to discuss ways to get simpler security concepts off the ground and how to implement them in existing infrastructure.

The ultimate answer is to create your own architecture so that you can find and use the tools that you can get the most measurable value from and use them to their full potential inside your security space.

The question becomes, how do you go about building that architecture?

The first holistic piece to be handled is a simple dictionary.

I’m from the South East of America, and was culturally imprinted with the inability to answer a simple question: “Do you want a coke?” You see to me, a coke is a whole variety of things, it’s a Pepsi, a Sprite, a Dr. Pepper, an actual Coca-Cola, etc. In fact, I am not alone.

I love this graph as it drives home a central point.  One of the most heavily advertised and distributed items out there, soft drinks, are still name dependent on the innate bias of the person speaking, or being spoken too.  To extrapolate this to our security industry may seem outlandish but think for a moment on the number of times you have spoken in an acronym, or inside joke or used a code word for a project or an adversary/campaign that your company is monitoring.  Does the person(s) you are speaking to really understand what you are talking about with some shared reference or dictionary?

This is a central problem, and value that ThreatQ’s Threat Library can bring to your organization. It provides the dictionary, the context and internal reference information for a simple request. This allows every one that interacts with the system to understand the language and the context of the language being used – even C-level executives. What used to take weeks, compiling information and questioning multiple groups, can now be queried directly from the system.

Here’s an example:

I’m in financials and I have a C-Level briefing due on our exposure to SWIFT. With ThreatQ in use by multiple groups, from Vulnerability, to Threat, to SOC, and even to Risk and Fraud, we can all use the same language and tool to present up a C-Level overview of:

• The current knowledge base on SWIFT
• Our level of exposure to SWIFT
• How we are tracking and identifying SWIFT
• How often have we encountered it internally
• Where we encountered it and how are we handling it
• Even down to which tool has been the most effective in detecting or fixing SWIFT related issues

Using a tool that allows for easy communication of standards from a naming convention, and allows for multiple systems to report in or get information from it through an Open Exchange, is the lynch pin around presenting a detailed and accurate brief.

The second holistic piece has already been hinted at — an information exchange.

This is a system built to create and provide referential data to multiple systems in ways that natively make sense to the consumer.  Being able to reduce the Time to Detection (TTD) of an issue is critical in security  For me, TTD also means measuring Time to Decision.

For example: You just ran into something that your gut doesn’t have a standard answer for. You need more information to make a decision. Where do you go? Generally, the answer is Google. But what if that answer can be found somewhere locally? What if there were references for an observable already built into the system? With ThreatQ that decision can be made using Open Exchange and Threat Library. And the context for all of those references is only a click away through an Analyst Workbench. My Time to False Positive or True Positive Determination goes down precipitously, and that decision is now repeatable and explainable. Attributes that “gut level” decisions rarely have.

The third holistic piece is a simple curation of data.

We need to be able to quickly determine what alert is valid, what tool has valid results, and if the information that has been received externally has valid elements for my internal needs. Having pre-built or automated curation of data within a Threat Library allows a user to focus on the analytics side of the house and allow for the systems in place to get new data, enrich that data, even score or prioritize it for transmission to other teams or systems in a standardized way.

Your architecture of disparate parts and pieces of tools starts to gel through common I/O processes and references. You are no longer dependent on competing vendors to work to a common standard. (We’ve seen how many standards and communities get created and slowly walk away from each other.) You can now force tools under your control to answer to each other in a common reference-able interface that allows for the enrichment of each tool it touches.

You are now the analyst doing analyst work, not the data dictation, translation and communication mechanism.

Let’s face it, since Henry Ford gave us the assembly line we have been looking for systems or pieces to make our life simpler. In security however we don’t have interchangeable parts. We have to find ways to automate what we can and to present a combined, reference-able and context laced data set so that humans can make a final decision.

Security is not simple enough to automate it away successfully. But it can be simpler by making the human smarter, by enriching your analysts to move through events and logs and analysis in a faster and more repeatable manner.

This is how you get to simpler security.

You understand what you have: risks, vulnerabilities and valuables.

You understand how you are defending those things, with a custom architecture meant to reenforce your security strengths and help compensate for your weaknesses.

You can quickly sift through the noise to point out issues based on real time intelligence.

And you can bring all three of those pieces together so you can start to understand who may be after your system or your data and, more importantly, why they may be doing so.

Once you have those answers – the what, who, how and why – then security becomes a game of “keep away.” One of the simpler games we’ve all been playing since we were kids.