Showing results for 
Search instead for 
Did you mean: 
Create Post

How To Not Be A Bad Network Security Engineer

Level 11

A week ago Leon Adato shared a fine post titled What “Old” Network Engineers Need To Remember.  I enjoyed reading his post and agreed with every point.  And so I thought I’d make my own list this week and share my thoughts on how “Not” to be a bad network security engineer.

So let’s get right two it shall we?

  1. Don’t assume bad motives.  Too often we assume that users are doing something they shouldn’t be and when we get the call that their computer has malware or we find something funny in the logs we treat them pretty bad.  Sure, some people are jerks and try to get around the rules.  But most people just want to get work done with as little friction as possible.
  2. Don’t assume that everyone knows the latest malware or ransomware delivery methods.  I have a friend that works for an autoparts distributor.  He deals with shipments all the time.  One of the emails he received was a failed shipping notification.  He opened it and boom!  Cryptolocker.  It encrypted everything on the shared drives he was connected to and left the business limping along for a few hours while they restored the previous nights backups.  He had no idea.  Malware  and Ransomware isnt in his job description.
  3. Educate your users in a way that isn’t demeaning to them.  I know the old “Nick Burns” videos are humorous.  But again, if you take the time to train your users and your not a jerk about it, they’re more apt to respond in a positive manner.
  4. Now for the technical stuff.  If you’re using a ton of ACL statements to control traffic, please add remarks.  By adding remarks to your ACL statementns those who come after you will think you’re a pretty nice guy.  I’ve inherited ACLs with thousands of lines and no clue what any of the entries were for.  Not cool!
  5. Use Event Logging and Correlation to your benefit.  Too many network security professionals try to get by without a solid logging and correlation strategy.  So instead of having all the info, they tend to tread water trying to keep up with what’s going on in the network.  There are a number of SIEM solutions today that offer event correlation and really good filtering on the logs.  If you don’t have one, build a case for one and present it to upper management.

It’s true that we’re in a very tough spot some times.  We manage systems that have a lot of power in terms of network connectivity.   It’s good for us to be transparent to users but at the same time we don’t want our users activity to be transparent to us.  It’s quite a balance we have to strike, but it’s worth it when we can.  And using some of the more advanced tools made available today can help give us the visibility we need.  Here’s a good example of how you can use Solarwinds LEM to create rules for real-time correlation and response..  This is just one example of how we can use today technology to provide security services while being somewhat transparent to users.  And as far as the five points mentioned above, these are but a few point I’ve learned over the years that have proven to be useful.  There are many more of course.  If you have one perhaps you’d share it below.  Iron sharpens iron after all!


Remarks to ACL statements are similar to comments in descriptive and make them 3AM friendly.  Don't assume that everybody that is going to look at them is going to understand your intent or a underlying reason something is set up a particular way.

Testify, Brother Brandon!!!!!

Educating your users as you go and helping them protect themselves saves you time in the long run.

I like the fact that you mentioned "remarks" in ACLs.  I use remarks all over the place and probably more than I should, but in a high turnover industry the corporate knowledge falls away with change in contacts or promotions.  So to make it easier on the new personnel, I use a lot of remarks.


Remarks are common courtesy. But are unfortunately not always used.

Level 12

"Don’t assume bad motives.  Too often we assume that users are doing something they shouldn’t be and when we get the call that their computer has malware or we find something funny in the logs we treat them pretty bad.  Sure, some people are jerks and try to get around the rules.  But most people just want to get work done with as little friction as possible."

the story of my life man, somehow this is always my first assumption that is about 75% right most times

"He had no idea.  Malware  and Ransomware isnt in his job description". - no its ours, but with the rate at which exploits are changing and becoming more intuitive, can we really educate the masses to stay those critical 1-2 steps ahead?

Good article

Level 8

These days IT staff at levels need to realize the importance of having a good working relationship with end users. The us against them mentality is old and antiquated and really needs to be left in the past.

There will always be those end users that want to make your life difficult or don't want to listen or take your advice but in my experience they are the minority if you approach them with compassion and respect. It really is more important than ever that you develop a good working relationship with end users.

The point about educating end users is so important these days. Done correctly they feel empowered and will actually want to help you keep the network and resources safe.

Great article.

Somewhere between 1 and 2--maybe 1a:

Don't assume the customer / vendor is lazy or stupid!  Just because it is not the way you think it should be configured, coded or implemented does not mean the developer did not have an intelligent reason to do so.

And probably rule 0:

Just because you have Pen testing software, if you don't understand what it is returning you can't just hand a report to the customer and say fix it.  Every time, SW products have been pen tested in our environment, it has failed.  Every time we are sent a report we ask when we can schedule a meeting with a SW Engineer to discuss the findings, the Pen Testers always back down.

Level 14

Great read all the way through. 

1.  I usually assume system misconfiguration until I find evidence to the contrary.

2. End users need continual updating about current exploits.  It's my job to kn ow these, not theirs.

3. Treat people the way you would want to b e treated.

4.  Always, always, always, remark your ACLs so others can understand your thinking.  They may serve to help you as well when you haven't visited an ACL in a while.

5.  Event correlation is a must.

Level 17

So true, user education is everything. Even with having mock breaches and phishing attempts not all users learn the importance.

  * sometimes it's just a hard lesson learned. I am sure those folks who lost their paycheck a few years back by clinking that link from an email and then 'logged in' more than likely remembered to be over scrupulous of those emails stating you need to click here and log in *

Overall I am sure there is still at least one who wont look at the FROM: field before clicking another email open.

Don't get me started on a massive ACL with no Comments......smh

Level 8

We probably can't ever get them a step or two ahead, best we can do is keep them vigilante. I liken a PC and it's software to something like a drop saw, I tell them a carpenter needs to use a drop saw each to do his job and make money, just the same as you need a computer and software each day to do your job. I get them to think of it as tool like any other and encourage them to be aware that while malware may not take off your hand like a drop saw it can do damage. They seem to think about that for a while and then take an interest in what to look out for. Hopefully doing this will lessen how often I hear "I hate computers!" well I live in hope!

Level 11

Good article.  I would like to add one perspective.  As I am sure "everyone" has realized when a customer has a problem it is always the networks fault, I see it time and time again.  However nine times out of ten it is not the network.  In our shop we have adopted the policy of "clean in house first".  We thoroughly investigate a problem within our own shop before we go to an outside source.  This prevents us from doing to other shops what they continually do to us.  Maybe one day they will realize it and start "cleaning in house first".  If you haven't adopted a policy like this maybe you should.  Any thoughts network defendergoodzheresteven.goodenhkelley

Level 14

Always clean in house first is a solid rule to live by.  Unfortunately, when non network administrators can't isolate their problems, many will automatically blame the network.  I have seen the flip side of this as well.  I maintain a unique server VLAN ACL that provides some isolation between that VLAN and the rest of the network.  I have had users troubleshoot for a couple of days only to find out their system didn't have access through the ACL.

Level 14

I totally agree. If you are not clean how can you expect anyone else to be.

My motivation used to be " And I built this like it is supposed to be". When I worked within a consultancy I used my environment as a showcase with numerous sales on the back of it - more than enough to pay for me, my kit and process. It works & now it's habit.

Level 11

ACL and code remarks: We have one of those non documenting workers. Never documents a thing because he can remember it all... Documentation is so valuable.

Level 14

This person doesn't understand the value of letting others know what eh\she has done?

I love it.  All good ideas.  May I also add "Don't be a Cowboy Network Analyst (reference Star Trek's "Cowboy Diplomacy") by making changes that are not reviewed, not approved, not notified to the affected sites/clients/customers, and not within a maintenance window approved by the team/company/customer(s).

  1. The older a company is when you join it, the more you appreciate the remarks or comments of others.
  2. The longer you stay with a company, the more you appreciate your own comments and remarks.
  3. The longer the company lasts after you leave, the more your comments are appreciated by others.
Level 14

Amen!!! rschroeder

Level 14

Outstanding article....

Being trained as a teacher (way... way... back) I know people learn differently....

Documents.... notes.... annotations are key...

Yes, educating users is like herding cats.... but you can't give up....  It can pay off...

Question to all: How many of you have been spared the pain of a virus outbreak or much worse (ransomware) because a user (whom you have trained) has come to you and said... " Hey is this ok to open" OR " this doesn't look right to me!" ????

All very good stuff. I like to remind my fellow IT brethren from time to time. We got into this field to help other people do their stuff. We have to have some patience with them.

Level 14

Well said.

Level 14

Not many work users, but quite often I get family call me asking whether they should click on something.

Level 14

Oh yes, the family computer guy.

Level 15

Good colaboration. We need to study for not To Not Be A Bad Network Security Engineer


The network here gets blamed far too often for problems and 9 out of 10 times, it's an application issue. But we always have to prove the network is fine. Even when we show where the bottleneck is, they'll still try and blame the network. It's a never ending battle.


True that!


Luckily I don't deal with users very often, we have a service desk for that! But I have been in that role in the past. Guess it's always better safe than sorry. My dad rings me quite often with all of his computer related questions. Luckily no other family member does this (other than wife and kids).



Lucky you, superfly99​! I'm acting tech support for my family and now my wifes!

Good post! The comment on remarks in your ACLs is something that training needs to highlight as good practice. For example, if Cisco and affiliated trainers added this as a good practice in their courses, then we'd find more helpful; configs down the line, and less "WTF is this for?!" moments at 3am!

I'm learning networking right now, and I'll be sure to add clear comments in my ACL statements for just this reason

Level 14

I like your idea of including this in formal training.  Train them up right and they will not stray from the path.

Thanks network defender​! I have my moments, not many, but I do have them!

(bonus points if you get the reference)

Level 14

Good post.  I agree with you on these.  And I'd like to add to the remarks in ACL statements.  These remarks are only good if they are done correctly.  Adding lines in the wrong places in ACLs can really mess up the remarks and then you just have a bunch of useless remarks.  You can add lines and resequence and get the lines to stay in the right places.  Also group rules with like rules and use object groups for fewer remarks.  There is not need for excessively long ACLs for no reason...unless you are trying to tick people off that have to go through it and adjust/fix it.  This only shows that you don't know what they are doing. 

Level 10

Well said.

Level 15

I like, good post.

Level 20

Lol... for some reason this cracked me up!!!  Sometimes I hate some sequences of both f/w rules and/or ACL's.

Level 15


Level 21

In addition to Log & Event Correlation I would also encourage people to take some time to check out some of the more cutting edge security solutions on the market that are moving away from the classic definition based Anti-Virus model and moving more toward a machine learning threat analytics platform.  I recently reviewed two different solutions of this type and they are pretty awesome!

About the Author
Brandon Carroll, CCIE #23837 is the CEO of California based Global Config Technology Solutions, Inc, Tech Blogger, and Cisco Press Author. With over 15 years in IT, a few certifications, and a love for technical education you'll find him at Cisco Live, on the Packet Pushers Podcast, Twitter, and Google+.