4

I'm currently implementing some mechanisms to continuously monitor our network. Most of this is done through OSSIM but I also extended it by some self written monitoring scripts. Im currently doing the following:

  • Hourly host discovery scans of all subnets including the detection of common services (using nmap)
  • Permanent passive host discovery through broadcast monitoring (using tshark and packetfu)
  • Hourly scan of all hosts for nic's in promiscuous mode (using nmap)
  • Hourly scan of all hosts for activated ip forwarding (using nmap)
  • Daily "non destructive" vulnerability scans of all hosts (using OpenVAS)

Is this a reasonable concept or am I missing some major points?

// We did an initial validation of the found vulnerablities and did patch them if possible. Some of them weren't patchable in that cases we limited access heavily. We are now verifiying new vulnerablities on a daily basis. We also have HIDS on all Servers but I did leave that out here because it is not really related to the network.

  • I think you know about alienvault, right? It uses OSSIM as a base and pretty much does what you are trying to achieve. One thing your are missing (that I can see) is deploying HIDS agents which can get a lot more information about vulnerabilities that what you can achieve scanning from "outside" your hosts. – lepe May 13 '16 at 1:43
  • There is probably a huge difference in the kind of risks which need to be addressed between your private network at home and an industry network at a facility dealing with nuclear material. Thus while your approach might be adequate for the first it is probably not enough for the second. Also, just that you scan does not say anything about the quality of your scans and how you deal with any true and false positives you might find. The major point your are missing is that you should do a risk assessment first and only then decide how to deal with the risk. – Steffen Ullrich May 13 '16 at 4:42
  • See edit,... We are a small company and definitifly not dealing with nuclear material. Are there any additional technical mechanisms you might consider using? – davidb May 13 '16 at 10:21
5

The approaches you mention are a bit confusing, and I will explain why. In a properly designed infrastructure many of the bulletpoints you listed would be addressed:

Hourly host discovery scans - If you implement strong port security on your switches, and used NAC - PacketFence (since you mentioned open source, I did also) you wouldn't need to worry about what was plugged in. The counter would be someone commenting: "Well yea but MACs could be spoofed" I say: "If someone is on your PHYSICAL network spoofing MAC addresses you have bigger things to worry about. Network Address Control done properly minimizes someone just throwing something on the network.

Permanent passive host discovery through broadcast - This was addressed with the NAC comment, but even if it hadn't been, not all hosts respond to broadcast.

Hourly scan of all hosts for nic's in promiscuous mode - This is a permissions issue/system issue. A normal user cannot put an interface in promiscuous mode. Properly patched systems include updating software. Without a vulnerability, or permissions, a user would not be able to turn on promiscuous mode, with NAC, they wouldn't be able to put up their own machine.

Hourly scan of all hosts for activated ip forwarding - More overkill. Without permissions to both the system and the network, I don't see how forwarding would occur.

Daily "non destructive" vulnerability scans of all hosts (using OpenVAS) - This is a lot of noise.

Much of what you have written about aligns with the "castle" approach to security. This is where you keep building to block from coming in. In this case, instead of looking at what you have, and how to use it, you are adding more issues down the road. Account auditing (logging sudo commands, controlling who can do what as an admin) is a better approach than wondering whether or not someone is putting something into promiscuous mode. Implementing NAC keeps untrusted, untested systems off your network. It is a one two punch: "no random machines, and no machines in existence can be tampered with. There are not vulnerabilities." Is a quicker, more effective, and more scalable approach then what you mentioned.

  • Thank you for your answer! The problem I'm having is that we are in a university environment where its more than just complicated to implement the mechanisms that are absolutely normal in the industry. The option left is what some people refere as "hunting",.... – davidb May 13 '16 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.