Packetsled UDP and TCP fallback analyzers

Home » Sled Meta Blog » Incident Response » Packetsled UDP and TCP fallback analyzers
There are hundreds of protocols that we need to see in detail to have a clear picture of our customers’ networks, and we have developed a suite of proprietary analyzers to address these. There are hundreds — or even thousands — more relevant protocols and services which we need to identify, but which are not significant enough on their own to warrant their own custom protocol analyzers. Added together, however, these protocols become major obstacles to network visibility and security.

Interestingly enough, this problem is not unique to networking — it’s a statistical phenomenon with numerous socioeconomic implications. For example, the disease advocacy group Global Genes has estimated that more than 300 million people worldwide are living with one of the 7,000 diseases they define as rare in the United States. That’s almost 5% of the world population living with a “rare” disease. And yet, treatment for each is wildly different, so it’s less productive and less lucrative to investigate each of these rare diseases.

Unfortunately, there isn’t a universal ‘rare disease treatment,’ but at Packetsled, we *have* developed a ‘universal treatment’ for unidentified UDP/TCP protocols and services. For flows in which we haven’t associated a high level of metadata, we capture key excerpts from the exchange to allow for analysis by Bro scripts or our platform, which, if interesting, can be used to pull the rest of the flow from our network data recorder.

The entries we find are frequently plaintext, or provide protocol preambles that make their nature obvious, such as the potential WinRM vulnerabilities discussed here: https://packetsled.com/analyzing-unknown-protocols-finding-a-piece-of-hay-in-a-hay-stack/

Here’s an example of a UDP log showing a JSON protocol header (note that excerpt sizes are variable, and we could capture the entire JSON object here):
#fields ts      uid     id.orig_h       id.orig_p       id.resp_h       id.resp_p       excerpt excerpt_size    payload_size
#types  time    string  addr    port    addr    port    string  count   count
1486600189.506264       589bb7fd0000000000000003        172.16.0.118    17500   255.255.255.255 17500   {"host_int": 59724991715298692108921997512624305849, "version":         64      365
This is especially useful for IoT protocols, many of which we have fleshed out into more detailed, dedicated analyzers and many of which are facilitated in healthcare. Recent announcements from leading healthcare device manufacturers indicate that IoT is now being used with fetal monitors, electrocardiograms, glucose monitors, and tracking vital health information. We’ve even heard of pressure sensors being used to determine the ratio of empty hospital beds during disasters, such as floods and fires.

However, the thing to remember is IoT is still in a sort of infancy. Some established standards have been developed, but are not widely adopted. This includes communication protocols and methods of properly handling sensitive data. As personally identifiable data could be transferred using protocols such as HL7, it is highly recommended that a close eye be kept on these valuable data streams.

An example shown below:
MSH|^~\&|PIEDMONT||PriorityHealth||||ORU^R01|Q479004375T431430612|P|2.3|
PID|||001677980||SMITH^JOHN||19680219|M||||||||||929645156318|123456789|
PD1||||1234567890^LAST^FIRST^M^^^^^NPI|
OBR|1|341856649^HNAM_ORDERID|000002006326002362|648088^Basic                            Metabolic Panel|||20061122151600|||||||||1620^Hooker^Robert^L||||||20061122154733|||F|||||||||||20061122140000|
OBX|1|NM|GLU^Glucose Lvl|59|mg/dL|65-99^65^99|L|||F|||20061122154733|
As IoT breaks away from traditional data networks, and ways of engaging patients, organizations will find value in how PacketSled dissects these streams of data. This will aid in understanding the risk the organization is accepting with the adoption and implementation of IoT initiatives.

IoT, like Cloud, is extremely disruptive and often noisy and misunderstood. This makes it even tougher to be a Security Professional and unfortunately, executives and board members generally care very little about that. We do.

With the PacketSled platform, it is our goal to perform the following:
  • Reduce the efforts associated with non-contextual, traditional logs by applying Machine Learning and well-researched attack models.
  • Detect multi-staged attacks within ordinary-looking data flows, regardless of protocol type. As most advanced attackers aren’t facilitating 0-days, you need modeling and adaptive baselines that can spot attacks in YOUR network. “One Size Fits All” doesn’t really fit anyone, any longer.
  • Enable you to perform Incident Response at scale. Finding the piece of hay in the haystack is a tough grind and we’re here to help, with event correlation and applied threat data.
It’s time for us to break out of the same problematically applied daily grind, where you are attacked, then respond, then mop up the disaster, then you start all over again.

It’s time to talk to PacketSled.



Co-written by Leo Linsky and Patrick Kelley
in Incident Response by Leo Linsky Comments are off

© 2017 PacketSled, Inc.