Recent figures show that there are over 100 million companies in the world, 99% of which are small and medium sized enterprises (SMEs). It is therefore concerning that a search on LinkedIn reveals only 3 million Information Security professionals globally. 33/1 is not a good ratio.
You may think that ratio is unfair because SMEs don't have the same need for security as large enterprises - this view is very common, although not necessarily accurate. Many SMEs supply products and services to large enterprises. If an enterprise is looking to apply the latest predictive retail algorithms to customer data or looking to run high speed trading algorithms on custom hardware, they'll often turn to an SME for assistance. In the case of Target who had invested millions in building a strong security monitoring capability, it was Fazio Mechanical Services, a supplier of theirs with less than 100 employees that was the initial point of compromise in the 2013 breach. If Fazio had access to better security technology then perhaps they'd have detected and responded to the threat.
Attackers will usually target the weakest link in the chain so if we are to rely on technologies to protect our networks then those technologies must be available and usable by everybody, regardless of their size and expertise. This was the key principle behind our product - ThreatSpike Wire.
We wanted our product to work for everybody and therefore we could not rely on other vendor technologies being available to provide data feeds and, as noted in my previous post, this often itself leads to data quality issues. We also couldn't rely on any in-house expertise to interpret the output of our analysis. We would need to collect the data, analyse it and present a complete story without any confusion or gaps.
To collect the necessary data, we decided to extract it directly from traffic on the network. Network protocols tend to be very standardised and common across different environments and their content is incredibly rich. This does however mean that there is a lot of work that needs to be done in order to get some meaningful information. If we consider a simple example where a user in a Windows environment copies a file from a file share and uploads it to a file sharing website, we encounter the following protocols:
In order to detect that something harmful has potentially happened in our example, we must parse each of the protocols listed to understand the discrete activities occurring (file being copied, website being accessed, file being uploaded). Each of these activities is not individually significant so they must be pieced together into a story and that story must itself be judged to determine whether it represents harmful behaviour. By piecing together the story, we take on the role of a security analyst, who on seeing a file being uploaded to the Internet might ask themselves questions such as:
In order to piece together the story we must remember what the user has done historically.
All of this analysis represents a significant amount of work that needs to be done and it must be done quick enough to keep up with constant network activity. Many vendor technologies will typically tackle only one of the tasks described - for example IDS analyses individual connections for suspicious indicators and SIEM correlates events from multiple sources to recognise multi-step attacks. By doing the analysis all together in one product however we get a high degree of accuracy and incredible simplicity in deployment. It may be the slowest analysis process, but we are still moving as fast as possible since there is no time spent plumbing together infrastructure, developing rules or carrying out manual investigations. There is a saying in the military: "Slow is smooth, smooth is fast".
In order to put this model to the test, we decided to see if we could install ThreatSpike Wire on a device and successfully detect our example scenario, all within 2 minutes. Watch the video below to see the outcome...
I left my consultancy job in 2012 to start ThreatSpike Labs because of SIEM.
With an extensive background in programming I was always looking for opportunities to code solutions to client problems, however this is rarely an option when consulting due to the inevitable maintenance issues that arise once the project finishes. Imagine my excitement on seeing SIEM for this first time - a tool which allowed the user to take their ideas and run them against a rich data set of web, firewall and intrusion detection logs to get immediate insight into threats on the network? I was hooked.
I worked mostly with financial industry clients to improve their security monitoring but it was during these projects that I came to realise that the technology is more vendor hype then reality. The types of problems I encountered included:
It was these issues that drove us to begin thinking about security monitoring from a new perspective in hope of realising the many benefits that SIEM advertises without the unfortunate drawbacks. In my next post I will discuss the approach we decided to take and its benefits over conventional technologies.
More in-depth information about our SIEM experience can be found here.