A quick forward with some background on this before I begin; a few days ago, one of the mods of the r/cybersecurity subreddit (which I highly recommend) reached out and asked if I would be interested in answering a few questions to help people looking at how to break into this field. I was happy to help, so here we are.
About your first job
What was your First Job in cybersecurity? When was that, and what were your responsibilities?
My first job in cyber security was about ten years ago, doing threat intelligence for a security operations center (SOC). I spent most of my time reading, reporting about different compromises, pulling out the compromise indicators (IOCs), and searching for them in our system information and event management solution (SIEM). If we found an indicator of compromise, we’d generate a quick report with the indicator and a description of what it was. We’d cite where we found the indicator and what search syntax we put into the SIEM to pull up our results, then send that over to the SOC, who would validate it and open an incident category (CAT) if necessary.
When I first started, I was simply someone who read reports and did searches, but my boss put me in charge of a small team of about six people who answered me within a year. In that role, my responsibilities were essentially doing sanity checks on the network traffic they were looking for and providing grammar and clarity insights to the reporting we were producing.
What were the most important technical skills that allowed you to succeed in that role?
Wireshark usage was a significant factor. You had to be able to use Wireshark at a basic level. More specifically, you needed to know how to follow the TCP stream and some basic syntax for filtering. Learning how to read a packet capture (PCAP) was also important. Which side is the client, which side is the server, what does a 200 OK mean, what is a 503 mean? What does a file download look like, what does a structured query language injection (SQLi) looks like?
It was important for people to have a basic understanding of how networking works. If a PCAP begins with a packet with a source port of 80, am I likely looking at a client initiating contact or a server replying to contact? (The answer is a Server responding). What does it mean when I see many SYN packets going to ephemeral ports in quick succession? (Likely a port scan). It was important for my analysts to be able to see these things and draw the correct conclusions.
Analysts should also learn to think about things that shouldn’t be normal. Should your company be making outbound FTP communications? (Probably not). Should you be accepting inbound Telnet communications? (Also, probably not).
What were the most important attributes and personality traits that allowed you to succeed in that role?
Being a universal translator. I learned quickly that the people I worked for weren’t half as technical as the people working for me. So, a large part of my job became trying to take all the nuts and bolts of what my analysts were saying and turning it into something our management team would understand. More so than that, however, I learned that I needed to translate the cyber-speak into something that money-making folks understood. What kinds of risks were they accepting by not dealing with whatever threat my team discovered on the network?
The skills that made me a better analyst were pattern recognition. I had an excellent ability to spot oddities in traffic—things like phishing campaigns sent to only outdated distro lists, patterns in traffic across weeks or months. An unusual activity like PowerShell remote scripting is coming from the HR subnet.
One other skill I think helped me a lot was my ability to make connections. I took a personality test a few years ago, and one of my dominant traits was “Connector.” According to the test, a Connector always knows someone who knows someone or knows something. The Connector is always reaching out to others and building bridges between groups. When I’m at work, this describes me well. I made many connections and leaned on those heavily when I would have problems.
What did you like about that job? Is there anything you didn’t like?
(I’m not in the habit of bashing people or policies, so if you’re reading that expecting me to air dirty laundry, you’ll be disappointed. )
What I liked:
As a starting point, this type of threat intelligence is a suitable location. You spend much time learning about diverse ways that hackers operate, so when you move into SOC work, you know how to defend against them better.
The environment in a threat intelligence center is usually more relaxed as well. Since we weren’t managing and dealing with alerts, there was never a queue of things that needed to be closed. We had some daily watch list items for high priority and high-risk threats, but overall, it was nothing like the stress you deal with when a compromise comes up on a Friday afternoon. Most of my managers knew that it could be weeks or longer between finding IOCs in the network.
I did genuinely enjoy my time in Threat Intelligence, but the concept of how we did it had many problems.
What I didn’t like:
Ten years ago, my job was novel, even critical. Having a team of people constantly checking your network for indicators that weren’t alerting on my anti-virus was necessary, and my team found significant compromises that would else wise have never been discovered. In today’s age, this job is mainly irrelevant.
I spoke about this in my retrospective on security lessons I’ve learned, but it’s worth repeating here. Your SIEM should be ingesting a feed of IOCs automatically. Ideally, your SIEM should ingest all your network and host-based logs and then check those logs against the list of IOCs. The SIEM should then categorize these detections and presenting them to you on a dashboard showing exactly how many of each IOC are present.
Nothing stopped the C-Suite leadership from closing my shop entirely and just having someone in the SOC doing what we did. Nothing we were doing was all that unique; it could have been done by the SOC as well, and from what I understand, the SOC does that job now.
The final issue I had with this work center was the redundancy of work. At our highest point, we had forty-two employees checking for IOCs on the network. When my team was six people, it was easy to keep track of what each was doing and make sure multiple people weren’t checking for the same IOCs. With forty-two employees trying to keep track was an effort in futility. We had a massive amount of overlap where people searched the same IOCs pulled out of the same reports. I had built a database in Access to record IOCs, but it was still a manual process of logging what analysts searched.
About how you broke in:
What degrees, certifications, boot camps, or field experience did you have at that time?
None. My undergraduate degree was in Criminal Justice. I got hired on because of Military Service. After college, I joined the military as an Intelligence Analyst. I spent my time in the military looking at data and analyzing threats, so when I applied to be a threat analyst, they accepted me because of my military history studying threats.
What mattered the most for obtaining your role out of degrees, certifications, boot camps, and field experience?
While I may not have had any relevant “enhancers” (for lack of a better term), I have several of them now, and leadership consulted me in the hiring process for many of the company’s current employees. Out of the listed options, experience is unequivocally the most important. Talking about a subject is essential, but doing what you’re talking about is infinitely more important. This is where experience comes into play.
I know that getting experience before you have a job in the field is challenging, but there are little things that you can do which demonstrate experience without having worked in the industry. Blogs like this one are a great way to showcase how you’re growing and learning as an analyst. My blog isn’t a fantastic example because I don’t have the time to discover malware and analyze compromises. I’ve done this a few times, but some other blogs that do this better are Dynamoo’s blog and Malware Traffic Analysis. While not as frequently, Dynamo posts frequently with the author’s analysis of IPs and Spam email campaigns. SANS Internet Storm Center (ICS) podcast commonly features Malware Traffic Analysis. Both of these blogs showcase the author’s mindset and skills. You are probably doing much training on your own, but it is hard for me (as a hiring manager) to know that if you’re not documenting anything.
On the subject of degrees
After the experience, I would say degrees are the second most important, with some caveats.
When I started my career, cybersecurity degrees didn’t exist, or if they did, they were so far and few between that I never saw them. Back then, the “golden standard” was a Computer Science degree, and to some extent, it still gets treated that way. Even though Computer Science gets treated as a “golden standard,” I don’t consider it as highly as a cybersecurity degree. I’m sure I just lost half of the readers right now, but I’m standing my ground. I think cybersecurity degrees are more critical for SOC work than computer science degrees are.
A few years ago, I was involved in hiring a new senior analyst. Our HR had coded the backend system only to consider computer science degrees, so the only applications we got were people who had computer science listed on their resumes. We interviewed nine people before eventually going back to HR and telling them to open the coding to more degrees. The problem we ran into was that none of the computer science degrees we interviewed (I’m purposely referring to them that way not to disclose any private information about the individuals) had any idea about security appliances.
We asked applicants to take some time and design a secure network. They didn’t need to factor in usability vs. security, costs, scalability, etc. (although it would have been nice if they did). We just wanted them to draw out a simple network and place security appliances into it. Where would you put an intrusion prevention system (IPS)? Would they use a caching proxy? What about a Domain Name Service (DNS) blockhole? Endpoint Detection and Response (EDR)? This question served two points; first, it gave us a quick look at what technologies the applicant had experience with, and second, it gave me an insight into their understanding of what these technologies do.
Out of all nine computer science applicants, only one person attempted to answer this question, and their only answer was to put anti-virus (AV) on every computer. While AV is important, and while I appreciate the other applicants saying they’d need to research it and get back to me (something none of them bothered doing, which would have given them massive credibility), AV is not the only thing you focus on. When we interviewed different computer security degree applicants, each one provided different takes on a secure network. Some went to name specific products like Snort vs. Suricata for the IDS, Endgame for the EDR, Splunk vs. Elk for the SIEM, etc. With the Computer Science degrees, the conversation about enterprise security died there; the exchange went into greater depth with the Cyber Security degrees.
Cyber Security degrees also have the benefits of providing experience to students during their schooling. In recent years I’ve had applicants who had experience reversing malware, analyzing PCAPs, and placing defensive measures to stop botnets.
What about Certs?
Certifications are almost a dime a dozen at this point, and unfortunately, they’re expanding at a rapid pace. I’ve seen certifications I’ve never heard of from companies I’ve never heard of. I have no idea how intense the training is or if the test is difficult. I don’t know what they teach or what concepts the applicant learned in this certification program. Furthermore, certs-only show me one thing; you’ve memorized enough abstract information to pass a test. Did you do the labs? Did you practice beyond that? Did you understand the material or memorize it?
Another common problem I see with certs is when people have too many. I once got an application from someone who had the following certs: CISSP, ISSAP, ISSEP, ISSMP, CAP, SSCP, CISA, CISM, CRISC, CWTS, Sec+, Mobility+, Cloud+, Linux+, Net+, Server+, CFCP, C|EH, E|CSA, C|NDA, SUSE CLA, LPIC-1, CCSK, CASP, ITIL Foundation. This was problematic because I didn’t know what half of those were and because it doesn’t tell me anything about you. What did you specialize in? Did you specialize in anything? How much do you remember from any of those?
I’ve said this a lot; certs get you interviews, the experience gets you jobs.
Honestly, I’ve never seen an applicant with a Bootcamp only experience. We’ve sent some analysts to boot camps and have been less than impressed.
Would you recommend the path you took to get into cybersecurity? Are there cases where you wouldn’t recommend it?
It’s challenging to recommend my path for the general population since my time with the military is how I got hired. I know many folks would never join the military, and that’s OK; the military isn’t for everyone. For the folks who don’t mind the military concept, then yes, I would highly recommend this path. Much like the civilian world, the military is in desperate need of cyber professionals. If you score well enough on the ASVAB and have enough patience, you can almost guarantee a job performing cyber. After four years, getting out and hired by a SOC is relatively easy because you now have experience.
What are the top three things you think people considering cybersecurity careers should know about the field?
I wrote a bit about this in a different blog post. I think those lessons are important, but if I had to summarize them into three things, they would be; humble, approachable, credible. If you want to go far in cyber security, you should be humble, approachable, and credible.
If coding was a big part of your role: What coding languages would you recommend people learn to be best-prepared for [your first role]?
Coding was not a big part of my role, but I found a few scripting languages particularly useful. Much work that I did was with the Bourne Again Shell (BASH) on a Linux machine. Grep is a fantastic tool for parsing through lots of data, although now you can do that in PowerShell with the Select-String commandlet.
Regular Expressions (REGEX) was another “not quite language” language that I found particularly useful. With Grep and REGEX, I was able to extract all the IPs out of massive log files and set up filters to alert on Personally Identifiable Information (PII). In addition, most IPS use REGEX in their ruleset, so learning how to read it is vital to understanding what alerts are happening on the network and understanding what the IPS are looking for.
Python is also a handy language to learn as you can automate many things to speed up processes. We have a phrase in cybersecurity that goes like this: “If I have to do something once, that sucks; if I have to do something twice, that sucks twice if I have to do something three times, I’m scripting it.” Python is excellent for automating those tasks that you have to repeat multiple times.
What projects would you recommend for people trying to figure out if [your first role] could be proper for them?
There’s not a ton of great projects to try out cyber threat intelligence. Several different CTFs are all built around open source. Cyberdefenders.org hosts several CTFs on its website. They didn’t create most of the CTFs, but they are hosting the files and a scoring board for many of them. You can try out some open-source Intelligence (OSINT) ones to see how you like them. I would also recommend taking a quick look over my old blog, as this type of work was more in line with the kind of work you might do at a threat intelligence division.
What do you think readers should take away from this series?
The most significant takeaway people can get from a series like this is a simple exposure to the variety of different jobs in cybersecurity and how many different paths people went on to get where they are. My path through cyber is only one of many.
About the author:
Free space. Talk about the cool stuff you do now.
Most of what I do now is managerial in nature. I spend much time focusing on the care and feeding of my analysts. I write their performance reports, perform quality control on reports, and handle other things like approving time-off requests and the like.
When I get a chance to perform technical work, it’s primarily teaching new incident responders how to conduct hunt operations more effectively. The analysts broke into two teams then the teams plan to compromise a brand new network I created. They have no prior knowledge of the network. The training uses the MITRE ATT&CK framework to plan the steps to breach a network. The
From there, the teams plan using the MITRE ATT&CK matrix to try and discover the other team’s compromise. I ingest all the network traffic and system logs into the SIEM. I’ve found this training to be pretty effective because it forces the analysts to think like an attacker since they are first conducting a breach themselves, and then it gives them an actual breach to try and discover. Sometimes I’ll provide PCAP, and other times I’ll provide a memory file. I’ve built pieces of training where analysts investigate Cobalt Strike beacons, Eternal Blue, Ransomware, and a few other things.
I occasionally still get to participate in actual hunt operations. I’m considered a senior team lead and lead analyst, but I spend most of my time doing forensics instead of hunting because we don’t have enough forensic analysts.
I want to thank the mods of r/cybersecurity for the opportunity to share some of my histories with the community. I also want to thank the actual r/cybersecurity community themselves. When I posted my ten lessons blog, I wasn’t expecting the response that I got. That post blew up, and the community gave me such a tremendous amount of support and valuable critical feedback on some of my verbiage.