Interview with Developer: Adam Swan

[post-views]
December 10, 2019 · 8 min read

We continue our series of interviews with participants of the Developer Program (https://my.socprime.com/en/tdm-developers), threat hunters and cybersecurity enthusiasts to introduce you to these wonderful people who are searching the web for relevant threats and create unique content for their detection. Meet SOC Prime’s Senior Threat Hunting Engineer – Adam Swan.

Adam, tell us a bit about yourself and about your Threat Hunting experience.

As a kid when AOL chatrooms were hip, I remember being fascinated by a trick I encountered that allowed me to trick others into changing their away message by accessing a crafted link. These sort of glimpses into ‘hacking’ lit a spark that sent me down this eventual career path somewhat un-purposefully. I ended up taking all the available coding classes in high school (to be honest the only classes I cared about) and then learned that I could make cyber security a career path while looking at college programs. I ended up entering an Information Assurance program at Pennsylvania College of Technology. The program was a mix of technical and policy and certainly opened a door that eventually led to threat hunting. 

After college I immediately began collecting certifications to become compliant with the U.S. Department of Defense’s 8570 hoping that they would open more technical opportunities where I was working. However, even after passing several certifications including the CISSP to ‘check all the boxes’ I felt I didn’t really *know* anything. That’s when a malware analysis position opened, and the manager said I needed to obtain the GREM certification to be eligible. Without any prior knowledge of malware analysis, I tackled the certification after a few weeks of intense studying. I really enjoyed the material and finally felt a path cleared into highly technical work. I was accepted into a junior position and spent a few years honing my skills at malware analysis, incident response, and dead-box forensics. 

However, it wasn’t until Nate (@neu5ron) asked me to join his team that I really got into threat hunting. He introduced me to Elastic, and we were hooked on the power of centralizing and searching against Window’s event logs. This culminated in us going on a bit of a speaking tour evangelizing the power of Window’s logs. This period is when I became a hunter and never really looked back. I’ve been practicing for about two and a half years now. So, compared to maybe some of the other analysts SOC Prime has interviewed, I am still new.

How do you think, what are the most important threat-hunting trends in the industry now?

There are three trends I would like to address. 

First, more organizations are starting threat hunting programs or are taking core threat hunting concepts and adding them to their existing SOC Function. This is huge as the fundamentals of threat hunting are in my opinion highly effective at improving security programs.

Second, another trend in threat hunting is the reliance on Endpoint Detection and Response (EDR). I prefer those which provide access to rich passive data regarding important events on systems that analysts can write detection logic or perform manual analysis against.  Leadership should be cautious of any vendor who claims to completely simplify or automate the entirety of threat detection. Adversaries are aware of and can bypass these tools.

Finally, the threat hunting community wouldn’t exist or be where it is without sharing. Projects like SIGMA that enable sharing in threat hunting have set a solid groundwork for future successes.  

Adam, what about Sigma, what was your first experience with Sigma, when you started to use it. 

SIGMA has been in my conscious since its announcement, but my first use of it in production was in early 2018 when a customer collected windows logs going back many months but didn’t have many detections / alerts other than out-of-the-box vendor detections. With the help of the SIEM engineer I deployed the relevant public SIGMA rules. 

And how do you think, what are the main benefits of Sigma as a threat-hunting tool? Can Sigma change the way how organizations build their cyber defense?

First, SIGMA enables the sharing of detection logic between organizations with dissimilar architectures but familiar data sources and threats. So, if I have Splunk and you have Elastic and we are both collecting Windows Logs, we can use SIGMA as a common language to share detection logic against our common threats like ransomware.

Second, SIGMA enables us to write detection logic and surround it with juicy metadata that may not be (easily) integrated into the alerting of your SIEM. For instance, if you are tracking your coverage of MITRE ATT&CK in some SIEMs it isn’t obvious or easy to tie these rules back to their associated technique. With the SIGMA YAML file you are empowered to tag rules however you want.

Third, if you keep your detection logic written in SIGMA you are setting yourself up for success in the inevitable adoption of a new SIEM. If your SOC is suddenly responsible for adopting a new SIEM (let’s say during an acquisition) or your leadership decides to switch to a new SIEM with SIGMA you are enabling the agile transition or adoption of the new technology. This is especially important if you are offering SOC/threat hunting as a service (MSSP).

What do you think is the most complicated and time-consuming part of writing new Sigma rules and how much time on average it takes you to write a new Sigma rule? Is it convenient for you to use Sigma as a tool to write new rules? And how do you make a decision what rule to create?

The more immediately actionable rules are based off direct observations. However, rules based on an educated hypothesis about adversary behavior or how adversary behavior affects a given system are equally valid. The most time-consuming part of writing a SIGMA rule is the research and verification that the logic you write is going to detect the intended technique/tool/threat. Writing a rule in SIGMA shouldn’t take much more time than writing a query against any SIEM. This is because SIGMA doesn’t get in your way, it isn’t picky, and the syntax becomes familiar quickly.  

To ensure quality, I highly recommend anyone writing SIGMA alerts take to heart Daniel Bohannon’s talk on resilient signatures (https://www.slideshare.net/DanielBohannon2/signaturesaredead-long-live-resilient-signatures). 

What about your experience with Sigma UI, Adam? Do you have any ideas on how to make it more useful/convenient for developers?

The SIGMA UI is great, I use uncoder.io to verify that my sigma rule will convert as copying and pasting a rule is very simple. It would be nice if the SIGMA UI made suggestions / recommendations for compatibility with different backends. For instance, relying heavily on wildcards can get you in trouble with Elastic compatibility.

Adam, as a content writer, you probably have a lab. How do you test your rules and which log sources do you prefer to work with?

Having a lab to simulate attacks and confirm / test the resilience of your signatures is very important. I prefer to work with logs that your average organization has access to. Today, writing a rule for native endpoint logging is the widest possible net to cast. 

Which types of cyber threats do you think will pose the greatest risks to organizations in the upcoming year? Any suggestions on how to improve the detection capabilities against such threats?

Threats vary significantly across organizations. I would say the greatest threat to the average organization is the adoption of wormable exploits/techniques into wormable ransomware (or any type of destructive malware). The days of Schrodinger’s intrusion are behind the average organization, most organizations will know they’ve been hacked when their data are taken hostage. Luckily, the methods behind preventing and detecting these types of attacks are relatively mature. The execution of these methods can range from being relatively simple to massively complex depending on the scope and complexity of the networks/systems someone is defending. So, my recommendation is really for leadership. Whenever possible, move towards simplicity. 

At SOC Prime we have launched the Threat Bounty Program that encourages content-sharing between cybersecurity professionals. Adam, Do you like the idea of rewarding developers for sharing Sigma rules and other threat-detection content?

Yes. If you are doing any kind of security research. Please think about how you can share the detection. All it takes is to increase the verbosity of the logging in your lab and then reviewing the logs for possible detections after running a proof-of-concept. If you don’t know how to get started, reach out to me @acalarch and I promise you it’s incredibly simple.

Adam, what would be your recommendation to young cybersecurity specialists who are just deciding which path to choose?

Here are the things I wish I would’ve done:

  1. Take advantage of the training you can obtain by attending conferences. It’s cheaper and you will be surrounded by peers and potential mentors.
  2. Be your own advocate and be skeptical/realistic. Make your career path intentions clear to your management, be a squeaky wheel about your intentions, seek mentors and don’t be afraid to move on.  

Was this article helpful?

Like and share it with your peers.
Join SOC Prime's Detection as Code platform to improve visibility into threats most relevant to your business. To help you get started and drive immediate value, book a meeting now with SOC Prime experts.

Related Posts