By: Cybrary Staff
July 7, 2022
A Deep Dive into the Cybersecurity Network Engineer Role
By: Cybrary Staff
July 7, 2022
Cybersecurity jobs have seen a lot of growth in the past few years. With so many career paths to choose from, we've decided to create a monthly “Role Dive” series, where each month we'll examine a particular job on a security team. This month we chatted with Mike Benjamin from Fastly to understand what it's like to be a Network Engineer.
View the recording here!
Q: How did you come across network engineering and what does that role look like?
The era in which I got interested in that initial bit of technology, cybersecurity wasn't really a field that you went and worked in. The first job that I got I came in, with an understanding of Unix, some C programming, and the security of computers. What I ended up walking into was a telecommunications company that offered Internet services. I joined from a relative entry-level position and as I walked in, I went through the team pretty quickly. I understood how everything worked and looked for which team I was going to move to next.
There were three teams I called them, I called them the Unix administration team, the information security team, and the network folks. I started helping customers repair outages, worked my way up through engineering, and ultimately became one of the architects designing the overall network at the organization I was that.
Q: What skills are needed for a network engineering role?
Networks are just another piece of technology. At their most basic, it's putting IP space on a network and the computers knowing where to send packets. I think a lot of people can start with something that's very approachable.
The skills, I would say, are the same skills that lend themselves towards system administration or being an SRE or even many security roles, which is the ability to ask questions, to learn from those answers, learn from hands-on, and have the drive to want to understand how it works.
Q: Is there any coding knowledge that you need to know? If so, what kind of language are we talking here?
Many years ago the common discussion in the network engineering circles was some lightweight scripting would be helpful. And I'd say today that has changed pretty drastically, even in the time period that I was working in network engineering, I was able to do my job better by extracting information from all these distributed systems.
If you think about a network, we're not talking about one or two computers in the case of the network I worked at it was thousands of 10s of thousands of devices and being able to ask questions, parse data, make decisions, push configurations back, to be able to control that many systems in a distributed way, you can see how some decent development knowledge is going to be needed in order to do that at scale.
Q: What are some skills that you found most difficult and why?
When you enter a technology field, you need to learn how it works and you need to understand how it's put together and maybe the configuration language. When you then think about how would I design entirely new systems or entirely new constructs out of the pieces, you need to understand the technology in a different way. For me, that was the biggest leap from thinking about how do I repair or return things to a functioning state or returning things to the desired state, and then shifting my mind to oh, this is exactly what those pieces of technology are capable of, and therefore I can now create something new. Being able to do that, especially in the service provider market where I worked, is something that requires a lot of time and energy. Thinking about lab testing, thinking about how do you test resiliency, how do you test functionality, how do you find bugs in the environment is something that could be transiting you know, millions of people across it those things take time to learn.
The engineering mindset, I would say, was the biggest leap that I had to overcome, and seeing networks more as a distributed system rather than some router with configurations running BGP or OSPF or whatever routing protocols was the point at which I could start to think about Oh, this is what I can make this overall machine do and that's true of big Unix environments it's true of big application runtime environments and it's true of networks.
Q: What would you say is the daily routine that you have as a network engineer?
What I saw were what we call more sustaining engineers. The people that were worried more about how do I get a code upgrade in, how do I test the new feature to make sure it doesn't break any configuration standards, how do I build a network location, how do I increase capacity, etc. A lot of things which are to sustain the machine, we have already built and keep it going. That was one focus and so those individuals tend to have somewhat short-term projects but they're still project-oriented. They get up, they work on whatever that project needs to be delivered by, they do their lab testing, and they schedule their maintenance or whatever they need to do to maintain that equipment.
The second group of people are more focused on engineering and building the new features, the new capabilities. They're given say product requirements or feature requirements from someone to say "how do I make this device, or this version of the software, or this component of network gear build a new thing." That could be creating private encrypted overlay tunnels for customers, it could be just making sure new line cards can support the next hundred-gigabit throughput or whatever it may be, or it could be being able to squeak more efficiency out of the existing network with changes to routing protocols or Traffic Management. So those folks are thinking more about how do you make the network do something new. And those tend to be longer-term, those tend to not be very simple questions they tend to be things that will take time and energy. They have to tend to collaborate more with the vendors themselves, or if they're running their own overlay controllers for networks their internal Dev teams that may have developed those things.
The last individuals are focused more on how does the overall system work. How do all the various components work together and how do we think about the next new things we could create. Some of those individuals tend to work more closely with a product manager about what the next version of the entire system might look like and what it can deliver to customers or the internal company if it's an internal network, etc.
Q: Say, for example, you're someone who has gone through all the courses on Cybrary for network engineering and you want to land your first job ever - what are some things you should include on your resume to stand out from the crowd?
The things that I've always looked for as a hiring manager is to describe the outcomes of what you haven't done. Rather than "I know a thing" it's "my knowledge of the thing allowed me to achieve something." So, "I built this complex thing in a lab successfully" or if you were able to actually have some background in network engineering "I completed a project that did something." So talking more about the impact and the outcome, rather than just the raw knowledge and skill.
The second item is, and this is important for all technology, especially security, ask why. So you take a course, you read a book, you go through something, and you understand that the routing Protocol should work in a certain way, you understand that the router works in a certain environment. Being able to question "why" or "what else can I do with it", or "why was it even designed that way" will give you such a stronger understanding of it. Continue to ask why and continue to think about tearing it apart.
And those are the people that can do that naturally tend to be very good in the security field because we all as infosec people tend to want to tear things apart, think about their vulnerabilities, and think about the risks. That's another suggestion I give to people, is if you're ultimately interested in a career in security, that same attribute will help you down that avenue.
Q: What are some other pointers that you have when it comes to interviewing?
Be comfortable, be yourself, share what you know, act excited if you're excited about something. One of the ways that I prepare is thinking about how would I teach someone this topic? So if somebody wants to ask me a question about how something functions, can I really turn around and teach it? If I can, then I should be able to discuss them in an interview with relative ease, but if I'm nervous and I don't really understand why this certain subset of things work the way they do or why a certain configuration is required - that's what I need to learn, that's what I need to go study.
Q: When it comes to looking at jobs, what are some red flags?
One of the things I like to ask in that sort of discussion, and I love when people ask me as a hiring manager, is what problems does this role try to solve? It really gives you an idea of what is the thing that's going to get you out of bed in the morning and get you excited about your job. If the thing you're trying to solve doesn't sound interesting, that may not be the job for you. So look for something that you believe you can find passion in that answer.
View this session to hear more about becoming a Network Engineer!
Interested in becoming a network engineer?
We got you covered with our Network Engineering Career Path, which will guide you through curated courses, interactive virtual labs, and practice tests that will help you build the knowledge and skills you need to succeed in your next career move. Begin your career journey today!