Security Mistakes That Leave You Vulnerable To Compromise #1: Failure To Monitor Your Network.

Here is my list of the top ten security mistakes that IT staff makes.  These mistakes leave your network vulnerable to attack and compromise. Mistake #1: Failure to monitor your network.

OK, you’ve bought all that fancy security gear.  You’ve established logging for all your devices.  And you’ve eliminated a lot of the attack vectors from your network.  Many organizations stop here and pat themselves on the back for “checking off all the boxes.”

Security-wise, this is a big mistake.

Despite all the equipment, policies and configurations you may have, a small percentage of attacks will penetrate your defenses.  Phishing attacks are now very sophisticated, and even your most savvy users can be fooled.  Malware is being written faster than antivirus software can keep up.  Attackers continually probe your defenses, looking for any vulnerability in any of your systems that might allow them to get a foothold.  And don’t forget, that in any organization, there are unhappy people who might be tempted to copy, divulge, modify or destroy information for revenge or profit.

The number one security mistake that organizations make is that they don’t actually monitor their network for attacks.  Many organizations I consult to tell me that they have not had a network attack. When I ask them, “how do you know?” most of the time I get a blank stare as an answer.  Some companies believe that an attack will be obvious, like an armed robbery or a building fire. But in fact, most cyber attacks are silent and nearly invisible.  Remember, your attackers are trying hard not to be detected, so don’t expect them to announce their presence.  You will need to find them in spite of their efforts to hide.

Studies of security breaches consistently report that when a breach is discovered, most often from an outside source (e.g., law enforcement), the initial attack and compromise happened months before.  How do they know?  By examining log data and other information, they can piece together a timeline of attack — information that you could have pieced together at the time had you been watching.

That means in order to detect attacks before your data is stolen or your bank accounts raided, you need to actively monitor your network for signs (“indicators”) of attack. A sign might be probing of your internet hosts, or a user’s computer attempting to log into servers it shouldn’t or making odd connections to hosts on the Internet.  But you won’t see these signs if you aren’t looking for them.

If your firewall, say, blocks a user from directly sending DNS requests to the Internet on port 53, or it stops your database server from “browsing” to a Chinese website, don’t think you have succeeded in stopping an attack. If it wasn’t simply a misconfigured device, then you should assume a few things:

1. The computer is compromised, and it will need to be cleaned up or re-imaged.
2. The attackers have gotten past all your other security controls designed to prevent PCs from getting compromised.  You should probably figure out how.
3. The attacker is going to try something else.  If port 53 isn’t open, they may try port 80 or others. Having established a foothold in your network, they will continue to expand their presence.
4. The attacker rarely stops at one machine.   Other users’ computers are likely compromised.  You just haven’t detected them yet.

My point is that you have to actively look for indications that attackers are in your network.  Your attackers are trying to hide, so you need to find them. Follow this basic rule:  If you’ve implemented a control to stop some kind of activity, for example with an access list or web content filters, you should be alerted every time the filters block activity.

So, if you don’t allow user workstations to RDP to production servers, and have an ACL to prevent it, you should receive an alert  whenever the ACL denies a packet.   If your access lists are denying packets, that’s a sign of a compromised machines.  If your systems disable accounts after too many failed login attempts, you should receive an alert when that happens as well.

If you’re only allowing whitelisted domains (see my blog post about DNS whitelists), you should generate an alert when a domain has been blocked.  Then you can track down which of your users generated the query and determine if their PC is compromised.
Monitoring alerts will tell you about things you know,  but you will need to spend some time looking for things you don’t know. It is necessary to spend some time analyzing your security data for patterns that may indicate an attack.  As I said earlier, your attackers are trying to hide, and you must look for things that give their presence away.  Essentially, you are looking for abnormal behavior in your network.  This is hard to do, simply because most networks are complex that determining what is “normal” behaviour is difficult.  You will have a lot of false alerts in the beginning, but you will eventually learn to tell what is important and what is not.  When you get to the point where you can spot a particular attack with ease, you can automate and create a rule to alert on the pattern.

You will need investigative tools to look for and analyze anomalies.   Many times you will get an alert (or a user complaint) that may mean a compromise, or it may not.  You may get an IDS alert that a user downloaded a back-door trojan, but the reliability of the signature is only 60%.  That means that out of 10 alerts, four will be false alarms.  In a large network, you probably don’t have the resources to forensically examine every PC that generates an alert, nor will you be able to interrupt users’ work to re-image the PC.  So, in order to determine if the alert was due to a real threat, you will have to gather other data.  We call this “context.”  The more context you have, the better decisions you can make.  For example, if all you know is host A may have downloaded a trojan from host B, it’s hard to tell if it’s a real alert or a false alarm.  If you have context data, you might learn that

• Host B is in a foreign country
• Host A is a domain controller
• After the alert, host A began scanning the network, or made several failed logins to another server
• Host B’s domain name appears to be random letters and numbers
• Host A is trying to open connections to the Internet on unusual ports

Taken together, this kind of  information can tell you if you need to act.

You may get sporadic user complaints that their PCs are running slow (so what else is new?).  Wouldn’t it be interesting to find out that they all visit the same website, or they all try to scan for other devices on the network? Again, context will help you determine if you’re dealing with a real threat.

Monitoring your network for security problems takes time.  That’s why most organizations don’t like to do it.  But even occasional monitoring will go a long way to protecting your network and your data.  Security monitoring must be an essential part of your network security.