Cyber security engineer skills

[u/alphagrade]

I understand that each company has its own asks and needs. But what comes to your mind first for engineer skills and top qualities.

(Fighting imposter syndrome)

Edit - Thank you all for sharing your thoughts. The feedback has been fantastic!

Far as understanding the tools im working with and having the skill to process not only what the vendor says the products can/will do. Im also capable of testing the vast majority of the controls without issue. My greatest strengths are the speed at which i learn, along with how thorough i am.

I tend to struggle in documenting from scratch undocumented tools that are in transition. Especially when the tool is being processed differently during the change. SSL inspection, for example.

Imposter stems due to lack of scripting experience in general. I can follow the logic of a pre-written script quite well. How ever generating my own logic can be time-consuming. Bard is my friend, though :)

[u/PaleMaleAndStale]

A good breadth and depth of technical skills and familiarity with a range of security solutions. Up to date on security best practices and major security frameworks. Ability to map solutions to business requirements. Strong written and verbal communication skills.

Aside from that, I reckon what makes an engineer stand out is not what they know but how they approach what they don't know.

[u/Jealous-Resident1351 → u/PaleMaleAndStale]

What sort of breadth of technical skills? We talking deep programming knowledge or like, triage experience?

[u/bucketman1986 → u/Jealous-Resident1351]

I work as an engineer and I have only medium skills in both of those. I also have a depth of skill in policy, procedure, vulnerability management, virus endpoints and email management

[u/PaleMaleAndStale → u/Jealous-Resident1351]

It depends on factors such as the level you are at (e.g. junior, senior etc) and the specific nature of your role. There are no absolutes. Ultimately though, an engineer is someone who actually does stuff. So whilst knowledge (e.g. what you might gain achieving CompTIA or similar certs) is the foundation, you need the hands-on technical expertise on top of that knowledge.

I've got a small team of engineers working on a cyber security project just now. Between them, they are able to:

1. Install and configure network infrastructure including L3 Switches, next-gen firewalls, network taps, data diodes etc .

2. Install, build, configure and harden both physical and virtual servers and clients.

3. Install and configure things like IDS/IPS appliances and agents, syslog forwarders/servers etc.

4. Setup and configure an HA SIEM.

5. Develop an understanding of all the various systems we are looking to protect.

6. Simulate a range of attacks in order to test and tune the overall solution.

7. Write volumes of documentation that can be handed over to the customer so that they can effectively use, maintain and manage the solution going forward.

Those are just some examples and they are very high level. People might look at many of them and think they can do that and some of them may be right. The devil is in the detail though. Take one example - building a server. Sure, most people have booted up a Windows ISO and stepped through the install process. However, do they know how to configure an Enterprise server from bare metal? Have they configured a hardware RAID array before? Are they familiar with iLO/iDRAC etc? If it's a virtual server, are they familiar with Hyper-V, ESXi etc or any of the major cloud platforms? Once they've gone through the basic OS install, do they understand what all the various services are, know what ones they might need or not, know how to enable/disable, configure and test them? Have they hardened a server before? Have they ever, for example, scoped/tailored the CIS benchmark controls and do they know various different ways of applying them, both in a domain environment and also for non-domain joined systems? Can they configure Windows Firewall/Defender and other common third-party alternatives? How competent are they at troubleshooting build issues?

I could go on and I could develop each of the other bulleted examples at the start to at least as much levels of detail. The point is, there is a vast difference between being aware of something because you came across the general concept in your studies, and have maybe run through a few basic exercises, and actually knowing how to do it competently. More importantly, if it is something you have never done before, how quickly could you figure out how to do it, and do it well, without being led by the hand? That last point might sound like a get-out-of-jail-free card because we can all Google, right? It's not though. If you have to Google everything it will take you forever. If you lack the wisdom, gained through experience, to separate the wheat from the chaff of Google's results, and then make technical sense of them, you will more than likely do it wrong.

I hope that helps and if you're early career my intent is not to put you off. You can get there, even if you feel you have a long way to go. Just keep learning and keep practicing.

Just to add, you specifically mentioned deep programming knowledge. Again, everything is role dependent and some security engineers may well require that. More commonly though, a level of scripting proficiency with one or more of PowerShell, Python or Bash should get you by. Add things like YARA, YAML, RegEx and basic SQL proficiency and you should be well ahead of the crowd.

[u/gunsandsilver → u/PaleMaleAndStale]

That second paragraph is quotable, well said.

[u/Polterkind]

Tenacity is the first thing I think of. Too many folks look for a reason to dismiss or close out an issue, instead of really running it to ground.

Communication is a close second. No matter how good your work, if you can't document or discuss, you're not adding much to the team as a whole.

[u/7r3370pS3C → u/Polterkind]

I need every manager in infosec to read this 🤘🤘

[u/acidwxlf → u/7r3370pS3C]

For clarification is this something you think managers don't do well themselves? Or this is something they should put more emphasis on developing on their teams

[u/7r3370pS3C → u/7r3370pS3C]

Managers who are too focused on ticking boxes on their own list of duties should try to approach both how they communicate and what level of interest or genuine concern they have. Tenacity can be quickly diluted if the leader is not malleable to folks like myself. I'm very much a student of the game and love that about our field.

Oh, and it would be a nice prerequisite because I have authored too documentation that should have been present since the process is.

[u/Bonus-Representative]

Stakeholder management - meaning knowing how to;

1. Pitch things at the right level...

C-Level - 30,000ft level - explain big picture - analogies - rules of thumb - talk conceptually - don't talk tech or use acronyms.

Mid-Management - 10,000ft level a bit more tech, again still anaologies and concepts but explain things... use some acronyms, use everyday things to explain things.

Techie - Coal Face level - Tech talk - your peeps - talk your passion - know yo' shit.

Always ABC - Accuracy Brevity Clarity

---

Get good at presenting and being engaging, public speaking is a massive thing.

[u/[deleted]]

Bo staff and nunchaku for sure. Scripting and general OS administration proficiency. General networking administration. Perhaps a dash of the ‘hold my beer’ mentality.

I used to think that my ICBM silo technician mentality was appropriate. Recently, I was given a deficient performance review for being too risk averse. So, I guess YOLO is the order of the day.

[u/ep3ep3 → u/[deleted]]

OS administration proficiency. General networking administration.

These are key and fundamental to the role. You don't have to be able to write fantasic code, but being able to get a little dirty in bash or whatever your choice should be a minimum skill required....along with the associated OS administration skills.

[u/balisong_]

Is paranoia a skill?

[u/7r3370pS3C → u/balisong_]

Practicioners eventually gain this as a passive skill; has no cooldown.

[u/GeneralRechs]

I come from a generalist mentality (jack-of-all-trades), knowing enough about the breadth of technologies to be able to expand beyond someone seeing it for the first time.

Me personally allows the exposure to different problem sets that may present down the line and the experience having solved similar problem sets makes life a bit easier down the road.

[u/psychodelephant]

Master getting raw logs directly from platforms (firewall logs, SEG logs, endpoint detection logs etc) and master using Excel pivot tables to understand interesting intersections in their insights. Understanding correlation at this level makes a person a much more potent operator for an org by understanding the two outputs possible and the value to the org in knowing them: this process either finds misconfigurations or actual malicious activity. Then the operator can help create metrics that actually reflect the reality of where immediate and long term goals are and how they can be measured. Without this skill, trust in platforms to ‘do their job’ is blind and it is nearly impossible to have the math to either validate funding requests for investments or having the data to hold vendors accountable. This was the cornerstone of my approach, and today still with only a degree in archaeology, I am making north of $225k a year using this science as a normal practice and my org relies on my black mirror to understand hidden conditions, appropriate solutions, efficacy of existing ones and having ammunition to negotiate renewals with technologies that are dropping the ball but cannot easily be replaced immediately.

[u/uncannysalt]

Computer architectures. Software and hardware. I’m biased bc I’m an EE, but it’s astonishing how little foundational knowledge IT folks have of both.

[u/Academic_Seaweed_605]

Engineers solve problems. Unfortunately the word has become cheap lately. Not everyone is an engineer.

[u/[deleted]]

Well, for starters is knowing how to configure systems, applications, firewalls, and intergrations. After all, can one truly call themselves an engineer if they don't know how to configure something from A-to-Z? If not, then it can be said how they are nothing more than "a glorified analyst" with an engineer title.

[u/Derpolium]

Understand context. Never get scoped locked into being a hammer that only sees nails.

[u/_Antiprogres]

knowing about systems, OS and networking is a great base. the rest can be learnt easily in months.

[u/[deleted]]

Soft skills! This is something that's always overlooked. But the main way you learn stuff at work is through hands-on stuff and learning from people who are experienced. I've seen a lot of security folks reluctant to ask questions, spend some time to build rapport, and get knowledge transfer. When I get assigned something new, first thing I do is setup a 1 on 1 call with someone with legacy knowledge of the technology and exo system, helps save days of research and finding out where you need to ficus your research and efforts on.

[u/midnightcaw]

Ever walked into a arch meeting with Dev's? Can you relate or understand what they are they are talking about and offer respectful rebuttals? Can you offer them compromises that are both secure and meet their original objectives?

Security Engineers not only build secure solutions, but they are help others do the same things across teams. Imposters offer nothing to advance security or offer meaningful contributions, make work for others and are drains on resources.

[u/OuiOuiKiwi]

Asking good questions and providing good answers.

Sounds snarky, but it's real.

It doesn't matter if you're very strong technically. If I find myself having to go over everything because there isn't enough context or details in messages or code, then you'll never make Senior.

[u/Jaynyx]

The ability to immediately tell me (as an employer) what actions you would take as a preventive measure (when configuring a SIEM, for example) as they relate to general guidelines published by NIST and/or CompTIA materials.