Security Professionals — What Do We Do All Day?
What do security teams do when they’re not dealing with security incidents?
Today, I had the opportunity to talk to undergraduate Computer Science students about a Master’s degree in Cybersecurity. After talking a bit about how I got where I am today, someone asked me, “can you talk a bit about what you do from day to day in your role?”
Boy was that a loaded question! A great one, but nonetheless loaded.
I could’ve talked for hours about what I do in my role as a Security Engineer, but I only had a few minutes so I tried to keep it short. It’s not easy to sum up what I do in a minute or two, especially while trying not to bore computer science students and prospective Cybersecurity students.
Well, there’s so much I could’ve said and although I feel I answered the question well, my response really only grazed the surface of what I do from day to day and what many security professionals do in their roles.
So what did I decide to do? Write about it.
What I’ve realized today is that even IT students/professionals don’t always know all the moving parts of a security program. And while technology professionals outside of cybersecurity don’t need to know the ins and outs of a security program, it’s important that they know we’re not just there to respond to phishing and malware incidents.
I’m writing this article not only to do my role justice but to help spread awareness of what is actually involved in being a security professional. Because how can we attract talented professionals without sharing what we do to pique their interest in the first place?
While I don’t remember everything I said, I do recall wrapping up my long-winded response with, “essentially my job is to ensure our security program does what we say it’s doing.”
To further expand on that, security operations programs are driven from the top down. Company policy drives security policy and security policy drives the security operations program.
An example I gave was:
If our security policy states that all computers are encrypted, part of my responsibility is that we have the technology, processes, and procedures in place to ensure all computers are encrypted.
If our policy states that we assess all server infrastructure for vulnerabilities on a weekly basis, again, it’s my responsibility to ensure we have the required assessments in place and processes around making sure those scans are in fact running weekly on all servers.
There’s one problem with this explanation though…it doesn’t do the job justice. There’s so much more to Security Engineering than making sure our program does what our policies state.
For starters, security programs’ overarching goal is to protect an organization’s infrastructure, the infrastructure being any system and information that supports the successful operations of the company. So, part of my job responsibility is ensuring our team employs tools and technologies to protect those systems from known threats.
Well, what are known threats?
Known threats are events that can negatively impact an organization. This can be anything from someone breaking into an office location and stealing computers, to an employee opening a phishing link that downloads malware, to a malicious actor exploiting a vulnerability (known weakness) on a system.
While this might sound pretty straightforward, an overwhelming amount of effort goes into protecting an organization against known threats. For one, many companies have what we tech people refer to as technical debt: the result of hardware, systems, and applications not being properly maintained and updated. In turn, organizations end up with a plethora of old hardware and systems that pose very high risk to the company.
In security, outdated anything equals high risk. Windows XP, Window 7, Server 2003, Server 2008, Java 5 and 6: all examples of outdated and unsupported operating systems and software.
Having any of these in the technology environment puts an organization at risk in two ways:
- If the system or applications crashes or stops working, there is no vendor support to assist in getting it working again. This obviously poses a risk to an organization, especially if business-critical processes rely on those deprecated systems/software.
- Old technology is a recipe for disaster. These unsupported systems and applications are riddled with weaknesses that have known exploits and no security updates to resolve them. While there are ways to reduce the risk those systems pose, the best approach is to mitigate the risk by getting rid of them altogether.
So, long story short: part of security professionals’ responsibilities is to assess the infrastructure, determine what systems are vulnerable to known threats, and then prioritize the mitigation of those threats or at least reduce the risk to an acceptable level.
Check out these articles for more information on Risk Management and Threat Analysis:
But wait, we’re not done. Protecting an organization from known threats doesn’t just mean ensuring our systems are up to date and fully patched. We also need to protect against threats that originate via email and the internet. We employ email security, internet security, and antivirus solutions to help us block known threats from making it to our end-user devices.
Email security products leverage threat intelligence feeds to intercept all inbound and outbound mail flow and scan them for known indicators of compromise (IOCs). This includes sender addresses, embedded URLs, and attachments, among other things.
Similarly, internet protection tools are what allow us to send user traffic through a proxy that can block users from visiting known malicious websites or communicating with known compromised IPs.
Finally, as you probably already know, antivirus works at the computer level to block any malicious files that may make it onto a user’s devices. Traditional antivirus products provide what’s called signature-based detection, which means that antivirus can block a file with a known bad signature. However, this leaves a gap in coverage because when new malware is created it’s not yet known, so how do we protect ourselves from that situation?
Next-gen antivirus is the way of the future because it helps us solve that problem. Next-gen antivirus builds on the signature-based model by adding in detection rulesets. Instead of only blocking files that are known to be malicious, next-gen antivirus also has the ability to detect and block behavior that can indicate a potential security issue.
The capability goes hand in hand with EDR, Endpoint Detection and Response. EDR products help in detecting suspicious or malicious activities on a device and automatically blocking said activity if it matches a rule for known malicious activity. EDR tools also provide the ability to isolate a computer in the event it becomes compromised. Computer isolation capabilities are critical in containing a potential security threat from the rest of the systems on the network.
Why did I just go on a tangent about security products? Because how can I explain what I do if you don’t understand how and why it needs to be done!
In a nutshell, the above are the ways we protect our organization against known threats, and as security professionals, it’s our job to continuously monitor these security tools for alerts and anomalies so we can detect issues before they become a full-blown incident.
Monitoring these tools is only half the battle though. As an engineer, it’s my job to ensure these products are doing what we need them to do and fit our environment. To do this, I design and implement various solutions to help us achieve our security objectives, and if an existing tool doesn’t have the capability or isn’t doing the job well enough, it’s time to look for a product that can.
This is one of the main differences between security analysts and security engineers. While it varies from organization to organization, for the most part, analysts are the ones conducting assessments, assessing risk, prioritizing vulnerabilities, and responding to various security alerts. Engineers are the individuals responsible for designing and implementing the security solutions that help to protect the organization. We’re also responsible for the continuous improvement of the solutions that support our security program, which includes streamlining the processes for each, optimizing the implementation, and automating as much as possible.
I’ve been in both roles so let me provide a few examples to help hammer home the difference.
As an analyst, I did things like:
- Perform daily checks on all of our security solutions to ensure there was nothing out of the ordinary to be concerned about. When there was an activity that seemed anomalous I spent an hour, sometimes more, doing a deep-dive into the activity to determine the root cause and if action should be taken.
- Whitelist and quarantine files in our antivirus product in the event that a file needed to be allowed or blocked.
- Respond to many incidents involving end-users that had clicked on phishing links. The response process for that sort of activity involves reviewing the email in question, identifying the sender email and malicious URL and blocking those IOCs, and of course, ensuring the end user’s password got reset.
- Perform vulnerability assessments on systems and work with the respective IT team to resolve discovered vulnerabilities.
- Weekly reporting on Key Performance Indicators (KPIs) for our security solutions.
As an engineer, I still do a lot of the above because I work on a small team, as do many security professionals. But on top of what I just mentioned, I now have the pleasure of working on doing things like:
- Implementing a privilege access management solution to secure privileged accounts (administrators, root credentials, etc.)
- Designing a technical solution to enforce least privilege on end-user workstations
- Configuring antivirus policies that best suit the organization’s needs while also protecting our systems
- Assessing various products to determine which one can best achieve security goals in my company’s environment
- Optimizing internet protection configuration to increase the effectiveness of the solution
- Finding opportunities for automation to alleviate the workload on the security operations team
So, to the person that asked me what my day-to-day looks like, it’s everything written above. Oh, and many long days and late nights, which is a common theme in most IT and security roles. If you go into IT or Cybersecurity, don’t expect to breeze through a nine-to-five shift five days a week. You’ll have your share of 10 and 12 hour days, and you’ll most definitely work a weekend here and there. It comes with the territory.
While I didn’t cover every role within cybersecurity, I hope this article helped to do the role of Security Engineer a bit more justice while also shedding light on what we security people do all day.
If you have any specific questions, please don’t hesitate to leave a comment here or message me on LinkedIn.
For more from me, be sure to subscribe to my weekly newsletter to get my latest articles straight to your inbox!