AlgoBuzz Blog

Everything you ever wanted to know about security policy management, and much more.

Search
Generic filters
Exact matches only
Search in title
Search in content
Search in excerpt
Search in comments
Filter by Custom Post Type
Posts

5 Assumptions Security Admins Should Never Make

by
[addtoany]

When you assume…. well you know the rest. It happens to all of us. We make assumptions on a daily basis that end up screwing us in the end. They’re usually small things, things that we think won’t make a difference. We put things off, we misjudge situations and a lot of times we end up regretting it. In this blog post, we’re going to look at 5 assumptions that are often made by security admins, but can end up being the beginning of the end for your network security.

Assumption 1: My security team is smarter than most hackers out there.

As good as your security team may be, there’s always someone smarter out there.  There’s no such thing as 100% secure and if someone wants to get into your network, they’re going to find a way. In addition, your security team has an entire network to secure. Hackers can focus their time and energy on a single server that they want access to. You also have to take into consideration that hackers often times work in groups, therefore able to get specific people that have hacking skills in specialty areas like databases, web servers, etc. Bottom line, you don’t have the smartest security team out there!

Assumption 2: There’s nothing of interest to hackers on my network.

This is simply not true no matter what. Simple things like reused usernames/passwords are of interest to hackers. Confidential information, salary spreadsheets, personal HR information, on and on. In another life I used to do independent security assessments. I never saw a network that didn’t have something interesting flowing across it!

Assumption 3: My security devices are good enough to keep hackers out.

Any security vendor that tells you their security device or service will make you “hacker proof” is lying to you. I work for a security vendor that will help you secure your network tremendously, but not 100%. Yes, you should always keep your security devices and servers up to date with patches and security fixes, yes you should deploy security devices in your network and yes you should follow best security practices, but that still won’t make you unbreakable. Never sit back and just assume that someone can’t get into your network because you have security devices.

Assumption 4: Nothing bad is going to happen today.

Why do today what you can put off until tomorrow, right? We all do it. Need to get the oil changed in your car? Ehh, I’ll do it tomorrow. Need to pay that late insurance bill? Yeah, I’ll do it this weekend. Everyone does it. That’s all fine and well until your engine seizes up because there’s no oil or you get in an accident with no insurance. The same goes for getting your network hacked. I can’t tell you how often I see incredibly permissive firewall rules that were put into place “temporarily”, never to be fixed. I’ve seen Domain Controllers with no admin password stuffed underneath someone’s desk, only to be forgotten about. When it comes to your network security, deal with it today and don’t put it off.

Assumption 5: I don’t need to secure my test/development network.

It’s easy to assume that there’s nothing of interest on your dev network and therefore it doesn’t need to be very secure. Trust me, there are things of interest on your dev network. If your dev network has access to your production network, that right there is a great jumping off point. If it doesn’t have access, kudos to you. Keeping it totally separate is a great practice. Still, your dev and test networks need to be secured. These networks are a great place to snoop passwords, learn more about how your production network is setup and plant bots that will do hackers dirty work for them.

Please share any other security assumptions that you think should never be made!

Subscribe to Blog

Receive notifications of new posts by email.