Most security professionals are well-versed in understanding log files and their importance. Most organizations with a security program operate a SIEM (Security Incident and Event Management) so they can track events around their network. They may use Splunk, FireEye, SolarWinds, QRadar, LogRhythm or many others for a SIEM solution. A SIEM is a very important way to keep track of log files which, according to Wikipedia, track “events that occur on an operating system or other software, or messages between different users of a communication software platform.”
That said, there are challenges that arise around relying solely on log data from a SIEM: Logs can be changed, altered, or adjusted to stop sending information…not good.
As a security program matures, people start asking things like, “What happens if a bad actor gets into my system and modifies my logs so it looks like the “event” happened a year ago to try and escape detection?” For example, when a system like SWIFT gets hacked, it tends to make people nervous about relying solely on a logging system that records transactions.
It is at this point that a security team starts to think about complementing their log files / SIEM with wire data and behavior Identification.
Much like most Operational Technology systems SWIFT logs are defined by financial rules and compliance requirements. For example, “If transaction is greater than 10k, send alert,” or “if SWIFT ID doesn’t match, send log,” and so on. As with most fraud that is successful, the system isn’t under attack, it is being used within the parameters of design. So no bad logs, no bad alerts, nothing for the traditional SIEM to trigger. But what if you could easily see the pattern, the baseline of your operators? What does “normal” actually look like? What does a burst of transactions under the compliance or operational limit look like? Would you know looking at the current process or only catch it in a batch audit…when it’s too late?
How is wire data different?
Wire data is the immutable source of truth, as one of my colleagues used to say. In other words, it can’t be changed by a bad actor.
Wire data is the information that passes over computer and telecommunication networks defining communications between client and server devices. It is the result of decoding wire and transport protocols containing the bi-directional data payload. More precisely, wire data is the information that is communicated in each layer of the OSI model (Layer 1 not being included because those protocols are used to establish connections and do not communicate information).
Also, wire data analysis enables the collection of traffic information from devices that a SIEM would not normally have the ability to collect logs (rogue machines, BYOD, etc.). Log Data is also limited to the capabilities of the system. An OT system like a crash box or a SWIFT transactional log, may log only hex for each function being performed. The SIEM has no idea what that means, it doesn’t see a trigger, and they have to be built each time.
The biggest difference between wire data and a typical SIEM is that the SIEM collects logs of a limited set of data while wire data looks at all data and transactions on the network. Furthermore, a SIEM will never be completely configured as companies are constantly adding new devices, replacing old devices, etc. Oftentimes, companies rarely (or never) keep up on updating the configuration of the SIEM, further reducing their value.
In addition, it is very difficult to get logs to the SIEM from devices such as BYOD — and hackers also know that a SIEM is likely present and will stop logs from being sent or will alter logs.
Many companies who have SIEMs eventually evolve to add wire data to ensure nothing is missed. A network data platform based on wire data (and enriched with threat intel feeds, bad file information) enables organizations to complement the information they get from a SIEM and also see when that SIEM might be misconfigured or even compromised. In addition, some of these network data platforms can send their data and/or alerts into a SIEM or orchestration if that is a preferred path.
When companies decide they want to have access to wire data, they can consider a couple options:
- Access wire data from an open source solution like Security Onion, Zeek, Snort, or Suricata.
- Find a partner that leverages wire data and wraps this data in services like analytics, trends, AI-enabled alerts, etc. and can provide professional services and integrations when needed.
What are the considerations for an MSSP when relying only on a SIEM?
Log aggregation means slower time to value than with wire data. Time to deploy a SIEM is several days or weeks and must be constantly configured and managed. It could take hours or even days to correlate all the events to determine the path of attack or relational failure. Logs cost CPU and memory of the devices that generate them. When you install a SIEM as a primary point of information, you accept 10-20% cost of the resources you are wanting to monitor – with added risk of outages when saturation occurs.
Networks aren’t built to facilitate a debug on everything, but for visibility we take from the operations of an organization when we increase logging for security and compliance needs. You also accept a solution for post-mortem identification.
Final takeaway – when considering options for wire data, organizations need to consider the following:
- What areas of the network do you want to monitor? Wire data is a valuable source of truth and should be considered for both north-south as well as east-west traffic, given more than half of threats begin on the inside of an organization.
- Are you looking for on-premise deployment or are you ok putting your metadata in the cloud? Some providers offer only one or the other. Or the provider may try to push an appliance on the customer.
- Do you want to take the headache to “roll your own” with an open source platform where they have no analytics, no AI, lots of false positives, no ability to open tickets or leverage professional services? “Free” is not exactly free when you have teams of people managing this process, combing through false positives, building homegrown analytics, etc.
Michael-Paul Yelland is Principal Researcher, IoT at MixMode & Founder of AMCyber.
Learn more about MixMode’s approach to context-aware AI and how it dynamically establishes baselines of your network environment, identifies threats and sends immediate alerts, and helps prevent attacks on critical data systems.