Welcome back to my blogging adventure. In my Cybersecurity Architecture series, we’ve spent some time discussing the value an analytic approach to the incident response process. In the last article, Conceptual Cybersecurity Architecture for analytic response, we started to drill into the solution space by giving a high level architecture to drive our discussion. Let’s spend a moment reviewing that diagram so we understand the context behind today’s discussion – sensor networks.
Looks simple, right? A cybersecurity sensor collects data and sends it to the analytic grid for processing. Yes, but the details matter so let’s start at the basics and move forward.
Before we start, I get some confusion when I talk to folks regarding conceptual cybersecurity architecture. A conceptual architecture is way to visualize the roles and responsibilities each component plays in the overall whole. The typical technical implementation consolidates multiple components into a single software implementation.
The role of the sensor in our conceptual model is to detect things. To get to the next step, requirements, we need to determine:
Let’s face reality, a perimeter based approach to cyber security where we actually believe we have a digital perimeter is invalid. The fact that a digital perimeter ever existed was, at best, an illusion after our networks first connected to the Internet. Every host that talks to the Internet, regardless of where it physically resides is an Internet gateway into your network.
So if we can’t focus on watching the digital perimeter, where should we monitor? We need to monitor wherever our data resides or where we’ve automated our business processes – the places we can suffer a material loss. This means the meta trends impact IT also impact how we implement our security sensors as well. Let’s spend some time looking at the trends and how they influence our design requirements.
Security Analytics at its core is the process of detecting the unknown and making it the known. This invalidates the entire event/signature based concept that our log based paradigm has been built on. We need to have raw unfiltered visibility to what is actually happening. The good thing is this doesn’t require expensive intelligence to implement; simple passive sensors that just collects data and forwards it to an analytic grid will drive us from multiple agents to a single simple sensor that can be leveraged for all our needs.
Now, does this mean we don’t want to collect all the existing event based data feeds from our existing toolchain? Of course not; however, we want to enrich the raw activity data with the event feed instead of the belief that the event feed providing complete visibility.
Repeat after me, we aren’t monitoring; we are collecting evidence. Every bit of data may be reviewed by a jury of our peers. The first few seconds of a compromise may make or break our ability to recover loss through the courts. We need to collect the data – with full chain of custody – before the actions of our well meaning IT folks attempting to restore services or troubleshoot issues destroy the evidence.
Since we need our sensors to reside wherever or data and business processes are, we need to be able to get that data through potentiality untrusted networks, we need a robust and secure data bus to move that data.
Okay, that’s a lot of text, let’s summarize. A sensor senses, really that simple. No rules, no signatures, just passive collection of the raw activity in an evidentiary sound manner. This data is protected in a store and forward manner because the network may be unstable and untrusted. We need to realize that installing a massive appliance in the perimeter of our network to monitor traffic no longer works because our applications are cloud enabled and mobile. Our controls have to follow the data as a distributed mesh of sensors communicating across a secure data bus.
Fortunately, Apache Nifi exists to help us create this data bus – a topic of my next article. However, as Apache Nifi’s minifi is further developed we will be able to embed this core protective data collection right in our sensors and applications. Join me next time as we dive deep into the conceptual design of our security data bus.
Mike Schiebel is Hortonworks’ Cybersecurity Strategist where he leverages his over 15 years cybersecurity experience working in financial services and healthcare companies to help customers build cybersecurity analytic solutions. He has lead incident response and computer forensic teams, designed and built security solutions, and created security roadmaps and strategies; learning how to position security projects based on delivering bottom line value to the enterprise.
Hortonworks Cybersecurity Strategist