November 25, 2011 at 4:22 pm #7082
So, I just landed a new job this week and have about 2 weeks until I dive into it. This is my first job solely in the security field(finally!) and I’m probably in way over my head.
One of my duties will be to set up some sort of infrastructure to detect hacking attempts, what vectors they are using to get in, manage alerts and configs, tell when there has been a successful hack, and things like that.
I’ve fooled around with snort, ossim, and tripwire in the past but wanted to get everyone else’ advice on what you would put in place and other options out there. They don’t necessarily have to be open source options, those are just the ones I’ve dealt with. I know it’s a little hard to recommend too much without knowing the lay of the land, but anything you can suggest would be great!
November 25, 2011 at 6:15 pm #43975ElevenParticipant
Congrats on the job! Just so you know, I’m not speaking from experience, but here are some things to consider.
0. Has someone thought about who is going to be responsible for responding to the incident, and what they are supposed to do once an incident has been detected? It doesn’t help much if you have a million dollar infrastructure to detect attacks, if you don’t have any clear policies on how to respond. Things like policies and checklists are important.
1. What should be monitored? Should the assets that face the most/biggest threats be monitored? The assets with the most vulnerabilities? The assets with the most value?
2. What are the goals of the monitoring (i.e. what should be logged)?
3. Is the time synchronized on all the systems (e.g. NTP)?
4. Are the logs centralized?
5. I’ve heard people recommend starting out small. There usually isn’t a need to invest tons of money right away; unless you need to be in compliance with regulatory laws. Start out with what you have. Enable NetFlow on select routers and have them log to a syslog server where you can analyze the sessions. Install something like OSSEC on the syslog server to automate the monitoring of logs from other computers. WMIC can be used to sweep the network to retrieve startup locations, services, processes, etc. from Windows boxes so you can put the information in a database for analysis such as looking for the Least Frequency of Occurrence.
Those are just some possibilities of what can be done without spending a lot of money, and might be a good place to start.
November 26, 2011 at 3:34 pm #43976
Thanks for the advice, Eleven. I guess I didn’t subscribe to my own thread, so I didn’t see your response until now. I hadn’t thought about a few of those points, but will definitely work them into my plan. I don’t even really know the full infrastructure yet, so I can’t plan out too much of the technical details, but I did just remember I’ll be in charge of some web app security, so I’ll probably need to look at ways to monitor/detect events in those as well.
Thanks again for the advice, and anyone else feel free to chime in as well!
November 27, 2011 at 8:08 am #43977docriceParticipant
What you deploy initially and in the future will highly depend on business requirements / expectations / existing perceived risks, etc.. You’ll probably fine-tune this as you go along and get more acquainted with the organization’s security policy.
One thing that I’d definitely recommend doing is take a pulse of what’s currently going on in the network. In other words, baseline activity, traffic, etc. on systems and infrastructure devices. This provides a “norm” reference with a cautionary understanding that this baseline might include existing malicious activity.
Everything that can be practically used for alerting and response should be logged centrally with proper NTP synchronization. If you’re multi-site, you might want to consider setting everything to GMT. Snort, OSSEC, Splunk, syslog-ng, Ntop, etc. can provide visibility. Don’t forget vulnerability assessments to get a snapshot of the current state of the environment. As mentioned previously, definitely utilize NetFlow, diffing config backups, scripts to summarize daily events, etc.. Also consider an annual or quarterly audit plan against recommended practices guides from the NSA, CIS, etc.. If the org doesn’t have egress filtering in place, you could put in a number of outbound permit statements just to get hit counts and see what might be leaking out (assuming the filtering devices in question have enough resources).
The commercial tools can do some / a lot of this, but their price / manageability will ultimately also hinge on your budget and comfort levels.
November 27, 2011 at 6:45 pm #43978TribanParticipant
Since you are new to the environment, I would find out as much about the network as possible and ensure documentation is in place for everything that requires it. Can’t protect what you don’t know! If all that is in order and up-to-date. Then start looking at the risk points and like Doc mentioned, get some baselines and a vulnerability assessment in place. Again know what you are going to protect. Clear out the false positives and march on! Good luck!!
November 27, 2011 at 8:52 pm #43979
Great advice, everyone. Thanks a lot. I’ll keep all this in mind as I move into this new job. Looking forward to digging into security full time!
November 28, 2011 at 4:55 pm #43980pseud0Participant
All the above info is dandy but I’d recommend stepping back for second and taking time to get the big picture. As soon as you can find out what your new organization’s regulatory picture looks like. All of the above comments focus on technical points and doing security for the sake of security. The dirty little secret of most organizations is they do security for the sake of auditors and regulators. Find out if your security team mates have already put together a requirements document showing what you’re legally required to monitor and start with that before you start doing anything else. Keep yourself and your company out of legal/regulatory trouble first, then go after all of the other (probably very important) stuff next. If a requirements document like this doesn’t exist yet find out if you can talk to your internal audit/compliance folks to see if they have anything on hand to help out. The side benefit to taking this approach is that you can use it to justify budget for stuff you need to do more robust monitoring as management will react much differently to “we need to do this to be PCI/FFIEC/GLBA/[xyz] compliant” rather than “ZOMG haxxors are everywhere!”. Treat your work as being focused on keeping the company out of the regulatory penalty-box and you’ll be amazed how much more support and $ you can get.
November 28, 2011 at 5:02 pm #43981
You’ve definitely got a point. I know they are subject to quite a few regulations and compliance measures, but don’t know all of them yet. I do know that one of my first tasks will be to become familiar with all of the guidelines and regulations and make sure everything is conforming to those. I’m sure everything will be much clearer once I get in there and get a lay of the land, but it’s good to have some advice from you guys to keep in mind as I go into it.
- You must be logged in to reply to this topic.