Day 17 - Containing a DNS Hijacking

Published: 2008-10-17. Last Updated: 2008-10-31 02:01:02 UTC
by Patrick Nolan (Version: 1)
0 comment(s)

Our 17th topic for our October Cyber Security Awareness Month effort is Containing a DNS Hijacking.

Containment, as a part of Incident Response during DNS hijacking, is going to involve taking action/s to limit the identified impacts of the incident to your site. Under ideal circumstances, detailed DNS Hijacking containment actions are just one part of a previously approved response plan, and the actions would be tailored for your site.

Of course, the plans containment actions will have been tested and prioritized for whatever automatic or manual mitigation actions are available at your site.

Typically, the teams that would be involved in containment during a DNS Hijacking incident include your network team, system administrators, perhaps your Legal and PR department. In some instances ISP's, third party DNS or other service providers and government CERT's may be needed to achieve containment.

Network related manual containment options mentioned in IR plans can include the details to;

  • Secure the systems under your control.
  • Contact the owner/s and upstream provider of systems involved.
  • Implement Network device configuration options including filtering, blocklisting and Null routing.
  • Implement Firewall configuration options.
  • Implement Security device configuration options.
  • Invoke alternate DNS or other service provider arrangements.

Containment may also need to include Notification to customers - timely notification of impacts and other critical information.

Incident response containment effort is not static, you take actions, you collect and analyze more data, report, contain again, and repeat loop until you can get to the final three steps in IR.

Although preparation has been covered in previous Diaries, DNS Hijacking containment can involve many teams and containment options, and the containment process will rely heavily on your coordination with the other teams. Your reaction time is going to be dependent on your ability to communicate quickly with the other teams. Your plans details should include OOB communication details and a method ensuring that all parties have regularly received up to date information on the communication details.

Thanks for participating with us and keep those suggestions coming! "If you would like to submit a tip, please use our contact form and be sure to put something in the subject like "Security Tip, day 15" to make it easier for us to sort them.  Keep your tips brief and to the point, also remember that the audience is broad, including end users, sysadmins, and managers".

0 comment(s)

Day 18 - Containing Other Incidents

Published: 2008-10-17. Last Updated: 2008-10-18 22:52:46 UTC
by Rick Wanner (Version: 1)
0 comment(s)

 I want to thank all the readers for all of the great ideas and feedback you have provided during the month
so far and especially this week.

So far this week you have addressed:
12 Gathering Evidence That Can be Used in Court
13 Containment on Production Systems Such as a Web Server
14 Containing a Personal IdentityTheft Incident
15 Containing the Damage From a Lost or Stolen Laptop
16 Containing a Malware Outbreak
17 Containing a DNS Hijacking

The comments and ideas from this week have been exceptional. Great work!

But as anyone who does incident handling knows, any incident you are familiar with or have planned
for is a lot easier than one you haven't. While this list addresses issues that are hot topics for today,
the list is barely a drop in the bucket for potential incidents.

Which brings us to today's question...containing other incidents?


Which incidents are on your radar and what plans do you have to contain them?
What other incidents have you run into in the last year or two, and what methods did you use to contain them?

Reader Scott sent in this insightful comment...

"As I was reading the article on containing other incidents, I was reminded of some advice pertaining to facility disaster plans. Do not create plans for every conceivable disaster. You could fill the library of congress with disaster plans for each disaster and still not cover all possibilities. Instead, create specific plans for disasters with high likelihood and create a general disaster plan to cover the unanticipated. In the general plan you must include reminders of specific unique attributes to your facilities so disaster commanders can make the snap decisions required. Write your plans for your successor, not yourself. You do plan to move on to bigger and better things, Right?"

 

-- Rick Wanner - rwanner at isc dot sans dot org

0 comment(s)

Comments


Diary Archives