Approach for converting threat detection reports from other products (eg. Splunk, Sentinal, etc) to NetWitness

[Anonymous]

I'd be interested to hear how other people approach taking online threat reports that have detection rules for other products like Splunk and apply them to NetWitness.

There is a lot of content for other tooling but not a lot for Netwitness so I'd like to learn how to essentially convert those type of reports into something actionable and usuable in NW, I'm sure the folks at NetWitness themselves are quite adept at doing this, I think this would be most valuable to other customers as well.

An example or two of how that is done would be most welcome as well to help me grasp the concepts.

[JohnKisner]

@Anonymous 

Do you have an example of one of these reports from another product that we can take as an example? I'm in Support and can potentially provide a possible example but I am unfamiliar with these other tools and the reports you are referring to.

[Anonymous]

@JohnKisner 

Something like this would be an example Outbound Network Connection from Java Using Default Ports - Splunk Security Content 

What would be good is to see the thought process of converting this to NetWitness that way I could reproduce it for anything non netwitness related.

[JohnKisner · Accepted solution]

@Anonymous 

Ok I think I have something for you. Please remember that this isn't my area of expertise and the example I'm about to provide may be pretty rudimentary but hopefully it will provide you with some direction for NetWitness. It is also possible that one of our Incident Response or Professional Services people will see this post and provide a more detailed example and correct issues they see.

If I understand the example provided correctly it sounds like that this vulnerability is due to JAVA attempting to send compromised traffic from an internal server to an external server using the LDAP port. I suspect I'm probably missing some of the nuance of the vulnerability but hopefully my understand will be enough. 

One of the simplest ways I can think of potentially detecting this when using only a Network decoder would be to write a application rule that says the following:

ip.dstport = 389 && service != 389 && ip.dst != <internal IP address in CIDR notation>

<internal IP address in CIDR notation> ex. ip.dst != 10.1.25.0/24 or ip.dst! = 10.1.3.21,10.2.14.22,172.168.12.1

The above rule says, look for any traffic that is using a destination port of 389, that is not actual LDAP traffic and it is not destined for an internal IP address. Given the vulnerability is trying to send compromised "LDAP" traffic to the internet this should work.  As long as all of your servers are only sending LDAP traffic to internal LDAP servers this should allow you to detect when this kind of traffic is outbound. 

As I said this is an over simplification, but the idea is to build up from something small using what you know to fully cover the situation you are looking to detect. For instance you could use a Feed to create a list of all internal LDAP servers, if you have a lot of them. You could then set the Feed to detect if the ip.dst is one of the LDAP servers and create a new meta called LDAP_servers and place that meta on the key called alert. If you did that then you would rewrite the rule to look like:

ip.dstport = 389 && service != 389 && alert != LDAP_servers. 

Remember this is only using input from a Network Decoder. If you also had Log Decoders and Endpoint in your environment you could then use Event Stream Analysis (ESA) servers to correlate similar application rules from these different input sources to give your detection rule more context to work with for less false positives. What it really comes down to is understanding your meta: where it comes from and how it is produced. You need to break down a vulnerability into its most basic indicators of compromise and then build up your different pieces of NetWitness.

For instance, using the above vulnerability again, think of it this way.

- How does the traffic attempt to hide itself from detection? 

- Does it attempt to piggy back on any common ports?

- Does it attempt to force a known service on a system to do something unexpected, and what does that look like?

- Etc.

Now the vulnerability in question seems to have the ability to manipulate logs, so that means you can't always rely on a system log to be truthful for detection. That means you have to use other parts of NetWitness to pull together a complete picture. Using meta from Endpoint collected data of abnormal behavior of JAVA. So in your environment there should only be certain servers that require JAVA to be installed for your business systems. You can put their IP addresses into a Feed so they are easy to reference, not unlike my LDAP_Servers example above. Using this feed you can look for any outbound JAVA activity that isn't on one of these servers. That should be at least a medium level alert for you to investigate on. We know that this vulnerability can piggy back on the LDAP port. So now you add any traffic outbound on the LDAP port from any server that shouldn't be actively using JAVA. As you can see you start to build up the context around the vulnerability based on what you know. In the end you will end up with a possible Feed, several app rules, and even an ESA rule that will create an alert once all these items are seen regardless of what source NetWitness received the information from.

I know the above is still a little vague. I wish I could be more specific but as I mentioned this isn't my area of expertise, but I do hope this helps some to point you in the correct direction. If you have questions about anything above, I'll do my best to answer them.

[Anonymous]

Thanks @JohnKisner , I appreciate you taking the time to write out a detailed response. I don't think your response if vague at all, it does give me a mental model of how to break down a detection rule (either splunk, sigma, blog post, etc) and apply it to netwitness.

If I had to summarise to make sure I understand would the following be accurate.

1. Extract the atomic indicators from the source material (blog post, etc) and the constituent logic of the rule.

2. determine what event source are required (log, packet, endpoint)

3. create application rules from step 1 that match the source data

4. If correlation between different event source is required, use ESA rules to essentially join the detection rules together, using your example above and ESA rule like "alert != LDAP_servers AND filename.src='x-javaw.exe'" and then maybe add a time context in there like "x number of events within x minutes".

[JohnKisner]

@Anonymous 

That would sound about correct. Whenever you are looking to create complex rules always try to break them down into smaller manageable chunks and use either the existing meta that NetWitness is producing directly or create more complex meta based off what NetWitness is producing. Using this technique you build up ever more complex meta until it covers the scenario you are looking for. The important thing is to remember that you have all the different parts of NetWitness that you can use to create these scenarios. Our Incident Response team, to help them find some of the most difficult nasties, will use a combination of application rules, feeds, parsers, and ESA rules to find what they are looking for. 

With your new found understanding of the process I'm sure you'll be able to retro fit just about any other detection scenario you can think of. It does take time to understand all the nuances of NetWitness but it is a very powerful tool.