SIEMs like ArcSight continue to be some of the most valuable components of a security program. However, as we all know, it’s incredibly hard to maintain SIEMs and realize their value. Many organizations are getting maybe 25 percent of the value that SIEMs like ArcSight should be delivering, as outlined in the Security Effectiveness Report. This is awful because SIEMs also happen to be one of the most expensive security components within most organizations to both acquire and maintain.
The majority of correlation rules and notable event searches in a SIEM are simply never going to fire. This means that alerts, reports, dashboards, and other content is also broken. This sad truth is because the content was created based on assumptions regarding the devices that are reporting into the SIEM, the events those devices create, and all the underlying infrastructure.
Often, there is even an assumption that a rule written several years ago will still work today. But then you discover that the device the rule was based on was replaced, or the vendor implemented a major taxonomy change thus changing the parsing, etc., a common upgrade, patch headache all SIEM administrators have suffered through.
Unfortunately, assumption-based security never ends well. Risk isn’t reduced. Value isn’t achieved. And, the SIEM is analyzing events against correlation rules and notable event searches while eating up SIEM resources and requiring security analysts to maintain them, even though they will never work. It’s like spending time, money, and resources maintaining a gun even though you have the wrong caliber bullets, thus making it useless by not providing the protection you needed.
These challenges inspired me to write a blog titled “SIEMs Sometimes Suck,” in which I explored many of the issues that sap time, money, and resources—all while not effectively mitigating risk. But SIEMs don’t have to “suck” and there is a lot we can do to get more value out of SIEMs like ArcSight through security instrumentation.
I spent about seven years at ArcSight. I was the Chief Security Officer and was there pre-revenue all the way through the ArcSight IPO. I know ArcSight (now part of Micro Focus) to be a solid SIEM solution with a massive customer footprint. But I also know that, like any SIEM (or any enterprise security solution for that matter), the kind of security instrumentation that the Verodin Security Instrumentation (SIP) offers is urgently needed to both effectively mitigate risk and realize value.
This piece is focused, specifically, on how Verodin SIP can help improve ArcSight through security instrumentation. We’ve written similar pieces in the past that talk about instrumenting tools like…
What you’re looking at below is the Verodin SIP Director, which is part of the overall Verodin Security Instrumentation Platform. This is a management and integration interface that allows you to safely execute behavioral tests within your production environment to better manage, measure, improve, and communicate security effectiveness. Essentially, you are validating how your security tools (across endpoint, network, email, and cloud) as well as your management stack (with solutions like SIEMs) are working. All this is done with a highly automated platform that identifies the issue, prescriptively helps you fix it, validates that the fix was applied correctly, and monitors in perpetuity to ensure it stays working.
We want to make sure ArcSight is getting logs from your devices. We want to ensure that the time is correct, and logs are parsed correctly. Most critically, we want to know if ArcSight is generating metadata, a correlated event, when something of note happens. And if it’s not working, we want help fixing it.
In the image of the Verodin SIP Director above we’ve selected a specific test behavior in the form of Pony Loader. The Pony malware is generally used to steal sensitive information. This test will be safely executed between Verodin SIP Actors, which are self-contained virtual machines, HW, RPMs, ISOs, cloud-based, or other assets that have the sole job of acting like an attacker or a target in order to measure the effectiveness of your security tools. You can learn more about the Verodin SIP architecture here.
Pictured below is the Verodin SIP Actor selection. We’ll be running Pony Loader from one source to one destination actor.
We can see the results of the Pony Loader attack in the image below. The attack was not blocked, as indicated by the red box reading “No.” The means that the source Actor was able to route its malicious traffic to the destination Actor without it being blocked by any preventative tools such as a firewall or IPS.
You’ll notice, in the green box beside it, that three events were created. Unlike the other box which illustrates prevention, this box shows us if the attack was detected.
Upon selecting the green event box, we can see the underlying events. As shown below, ArcSight did in fact receive log files related to the events, and the formatting, parsing, time and the like look correct as displayed in the raw data. However, the events did not trigger an ArcSight correlation rule, which is why it says “Events That Didn’t Match a Rule” near the top left.
It is also worth noting that nothing in the events mention anything remotely related to Pony Loader. This isn’t unusual, as the device that detected the attack might not have been exactly sure what the attack was, but at least it picked up on the fact that the behavior was nefarious and reported something to ArcSight.
So, let’s see if we can get ArcSight to fire a correlation rule based on what Pony Loader looks like on this network and with these security tools and configurations, which will vary across every environment.
As seen in the image above, Verodin SIP provides the exact events needed to build a Pony Loader correlation based on the security tools we have running. As you can see below, we’ve now switched out of Verodin SIP to use ArcSight. We are in the conditions editor and are building a rule.
- The first event name contains “ET Trojan EXE Download Request to WordPress Folder Likely Malicious”
- The second event name contains “ET CURRENT_EVENTS Terse alphanumeric executable download high likelihood of being hostile”
These event conditions are highlighted in red below on the right-most column. The actual rule, called Pony Downloader, is highlighted in red on the left.
Now that we’ve created the ArcSight rule based on the prescriptive details provided by Verodin SIP, we can enable and apply the rule within ArcSight and switch back to Verodin SIP to validate that the rule is working as desired. We’ve shown how to do this below. Simply select “Run Again” as highlighted in the red box.
As shown in this next image, instead of the three events we received the first time we safely executed Pony Loader, we now have four events. We’re still not blocking, but that’s because we didn’t make any changes to preventative tools—we just created an ArcSight rule.
In the illustration below, you can see that we were successful. We have successfully created and validated an ArcSight rule for Pony Loader specifically based on the prescriptive results of Verodin SIP within your production network.
The red box at the top left here shows that the events did match a rule, which generally means that someone will actually look at this instead of the events simply being background noise. We see the name of the ArcSight rule that we created being displayed in the red box reading “Pony Downloader.” Finally, in the bottom box we see the actual events that were processed to generate the rule.
These quick, simple, and intuitive steps save massive amounts of time and money while greatly reducing risk. For the first time, there is actually a solution to help you instrument your ArcSight SIEM as well as your other security tools. Best of all is that once you’ve validated that the ArcSight rule is working how you want, you can have Verodin SIP automatically test for environmental drift to ensure that what was working stays working. If, for some reason, Pony Loader is executed and this ArcSight rule doesn’t catch it because of some type of network change, patch, rule adjustment, etc., you’ll be notified by Verodin SIP.
ArcSight can be an awesome SIEM providing a ton of value if you can validate that it’s doing what you want, optimize it, and make sure it keeps on delivering. To learn more about Verodin SIP and how it can help you instrument ArcSight as well as your other security tools, check out our website and request a demo.
*** This is a Security Bloggers Network syndicated blog from Verodin Blog authored by Verodin Blog. Read the original post at: https://www.verodin.com/post/instrumenting-arcsight-with-verodin-sip