What if Tomorrow Was the Day?

Published: 2012-12-13
Last Updated: 2012-12-13 18:35:04 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)


[guest diary submitted by Russell Eubanks]


If you knew your network was going to be attacked tomorrow, what specific actions would you take today? Treat yourself to lunch at your desk as you consider the following suggestions.


Look for opportunities to improve your detection capabilities. In your security lab, try changing operating system and application configurations to see if your current policies are able to detect and alert on these actions. If not, create new alerts that are labeled with the action you used to generate these events. This a great foundation to actively seek the activity that you are currently missing. 


Update the contact information for everyone on your Incident Response Team. Be certain that everyone you have listed knows they are a part of the team and understands their role when an incident occurs. When was the last time you held an exercise to make sure that everyone listed on the team can be reached in an acceptable amount of time? Schedule an update for the team today. Consider providing them with lunch or an another appropriate token of your appreciation for serving on the team.


Leverage data from the Top 100 Source IP addresses as seen by the SANS Internet Storm Center at http://isc.sans.edu/ipsascii.html. Consider a daily report that shows the traffic between your hosts and those found on this list. Traffic to and from these hosts may not indicate an attack, but may very well prove worthy of your investigative efforts.


Create new alerts based on information found in your logs. These alerts can be scheduled to run every few minutes and configured to notify you if more than zero occur. Pay particular attention to trends that stand out over time. Can you determine the normal usage patterns over a given time period? How would you know if something outside of this baseline started to occur or stopped occurring? How quickly would you know if a critical system stopped sending logs to you? 


Schedule and perform regular security architecture reviews. Start with a copy of your network diagram and assume the role of your attacker. Determine how its current defensive and monitoring capabilities could be defeated. Make sure you can detect this type of attack going forward. Implement changes based on that review session today to prevent that type of attack from succeeding. As a final step in this exercise, update your network diagram to reflect any changes you made.


Become familiar with the 20 Security Controls http://www.sans.org/critical-security-controls as a means to implement or enhance your continuous monitoring capabilities. Spend some time on the website to learn about the controls and how they can be applied in your network. Focus specifically on the Quick Wins section on each control to get a better sense of the intent behind each objective. If starting fresh, Controls 1 and 2 could very well be a good place to start.


Finally, use the following suggestions as a means to be intentional about network security monitoring. Conduct recurring IRT peer reviews to solicit their suggestions for improvements. Publish regular reports to the IRT, noting specific items that would be useful to the team. Invite the IRT to subscribe to the SANS Internet Storm Center Daily Podcast  at https://itunes.apple.com/us/podcast/sans-internet-storm-center/id304863991. Make a recurring calendar appointment to do this activity with your IRT over and over again.


What additional suggestions do you have that support intentionally monitoring the security of your network?

3 comment(s)


A quick one-liner to search a Bro IDS connection log for traffic containing any of the top 100 source IPs:

curl -s 'http://isc.sans.edu/ipsascii.html' | sed '/^#/d' | awk '{print $1}' | sed 's/^0*//; s/\.0*/\\./g' | zgrep -f - conn.00:00:00-00:00:00.log.gz
that should be a double backslash before ./g in the last sed command.
Well, these are good thoughts and ideas. However, unless I read over it, the simple stuff was not said.

I understand this is a venue where doctors should not be told how or when to tie their shoelaces, and then check them, but it is the small stuff that adds up very quickly...

I have worked in NOCs before and the simple stuff is what kills you and your intranet.

1. Are your routers and firewalls updated and to date?

2. I am sure you have had employee turnover, have you turned off accounts, and changed passwords on admin controls? Even every 90 days?

3. Are the O/S's in your shop updated, to some extent?

4. You probably paid for a "Intrusion Penetration Analysis". Have you truly visited those suggestions? I hear time and time again every year the same issues come up in those reports, that were not addressed from the last two or three consultations. Those issues may still be there, ready to be exploited.

These sound like simpleton infosec ideas, but they are FAR overlooked. Time and Time again. I have seen these be root cause analysis factors, in the after incident meetings.

For what it is worth. Stuff that goes on automatic is rarely rechecked. Check, patch, update, then recheck twice. Then check at a higher one time level. This might sound paranoid, but it is amazing what it turns up.


Diary Archives