.

Malware Incident Response

<<

Cutaway

User avatar

Jr. Member
Jr. Member

Posts: 96

Joined: Mon Nov 20, 2006 5:02 pm

Post Sun Jan 14, 2007 2:27 am

Malware Incident Response

I recently posted (http://www.cutawaysecurity.com/blog/archives/80) this to my blog and I was interested in some feedback from this forum.

When to Initiate Malware Incident Response

When somebody tells you that their anti-virus software detected a virus do you start your incident response procedures?  If you do not you should reconsider your position.

"But, Cutaway, if I initiated my incident response plan everytime a virus was detected I wouldn't get anything else done!"

I really hope that you do not work in an environment where systems are being infected on a daily basis.  But if you do, and they are, then perhaps you should consider implementing your incident response procedures everytime.  Please allow me to explain.

Most virus/worm reports are going to come in through your helpdesk or by a quick call to the responsible administrator.  The first step in your incident response plan should be to identify the assets that are involved.  I'm not just talking about the physical assets.  For instance, the infected system was an end-user's workstation.  I am also speaking about the other assets that are involved with the infected system.  Does the end-user work with sensitive information?  Is the system on the same network segment as the database server that contains the database with credit card information?  By quickly determining the type of assets involved the point of contact can choose to continue following the incident response plan and escalate the situation or log and mark the system for review and maintenance.  Without this situation analysis you might not know the full extent of the issue.

Now that the situation has been identified a course of action can be determined, whether through the incident reponse plan or the maintenance procedures.  Do we need to pull the system from the network?  Do we need to get a copy of the malware so that it can be analyzed to determine its function and purpose?  Do we have to identify if sensitive information was accessed or exposed?  How did the system get infected in the first place?  Can the system be cleaned sufficiently to perform its function or does it need to be wiped and redeployed?

All of these are standard questions and easy for anybody to pick up on.  From the list I really want to focus on the "how did the system get infected" question.  If you don't have to initiate an incident response plan this question has the biggest potential to get overlooked.  It is easy to say, "I got infected but the anti-virus detected and deleted the malware for me.  I'm good, I've got work to do, I'm moving on."  A common business continuity, attitude but what got solved here?  The system is not infected anymore but it is still vulnerable to the same incident.  By initiating the incident response plan you are ensuring that this question will be asked and sufficiently answered.  Now, you have to be careful here because it is very easy to get sucked into a tunnel vision approach and miss the gaping hole in the side of the ship.  Viruses, worms, and malware don't just magically generate on a system.  There are any number of ways they can find a home: user interaction, worm prorogation, web surfing and email reading, exploited applications and services.  When you look at that list can you see the potential that one avenue of approach might be mistaken for another.  Let me put it this way, if your anti-virus detected a worm on your system whose method of propagating includes exploiting DCOM or some other service can you say for certain that the worm was not placed on the system by a person who exploited a different vulnerable service and then uploaded this worm because their network reconnaissance of your network showed that more systems were vulnerable to the detected worm?  You might have to read that sentence again to get my point but it is there.  Until you look into and address all the methods a system could have been compromised then you are still vulnerable and the system will get owned again, and again, and again.

Okay, we have identified our assets we have determined how the system is vulnerable, are you satisfied?  Actually, that is my question to you.  If you were following your incident response plan would you be satisfied at this point.  Where is the follow up?  What was assigned with this task?  Did their manager or the incident response team leader follow up with them?  The process is not complete until the all of the issues have been resolved, the administration of the system has been reviewed, and procedures have been modified to increase the prevention related to malware infection on this and other systems in the organization.

Yes, I do understand that implementing your incident response plan is going to cost you in man-hours and money that could be spent elsewhere.  This is exactly my point.  By devoting man-hours and money to this type of activity people (MANAGERS) are going to start to take notice.  If they don't notice then you need to be pointing it out to them.  At the same time you should present them with options as to how new procedures, updated policies, end-user training, system hardening, and other security modifications can reduce the number of incidents and thereby decrease the amount of man-hours/money devoted to responding to these types of incidents.

Sure, what I have described here is a very simplistic example of an incident response plan.  But the point of this exercise was to help you understand that just allowing your anti-virus software to act as your final step in the malware security aspect of your defense will only ensure the continued infection of your systems.  This will eventually lead to bigger and badder compromises in the future.  Protect yourself now by being proactive and not allowing yourself and others to take the easy way out.

UPDATE:  When I got up this morning I realized that I forgot to mention one important fact.  The primary reason behind an incident response plan is not the security of the assets involved.  Rather, it is the business continuity of these assets.  The job of a security professional is not to firefight potential issues but to evaluate the threats associated with the companies assets and mitigate them as much as possible to ensure the business continuity of the organization.  By not initiating your incident response plan to help you combat malware within your environment you are, in effect, placing your assets at greater risk.

Please, if I have missed something point it out to me in a comment or trackback a blog posting from your site.  I welcome the feedback and critiques as they help me grow and become a better security professional.

Go forth and do good things,

Cutaway


Thanks,
Go forth and do good things,
Cutaway
Go forth and do good things,
Cutaway
<<

slimjim100

User avatar

EH-Net Columnist
EH-Net Columnist

Posts: 385

Joined: Wed Nov 08, 2006 12:50 pm

Location: Atlanta

Post Mon Jan 15, 2007 6:41 pm

Re: Malware Incident Response

Thanks Cutaway! Very interesting post and a lot of very good recommendations for processes & procedures. Makes me want to jump every time I hear the word infected. The ideas and approach you bring to light here are an eye opener to possible biger issues and broke processes. Thanks for sharing your knowledge.

Brian
(AKA Slimjim100)
CISSP, CCSE, CCNA, CCAI, Network+, Security+, JNCIA, & MCP
<<

manju_salian

User avatar

Jr. Member
Jr. Member

Posts: 89

Joined: Mon Apr 09, 2007 1:31 am

Post Sat Jul 25, 2009 1:26 am

Re: Malware Incident Response

I found some views from the blogs for the same
http://blog.trendmicro.com/virux-cases-escalate/

Return to Incident Response

Who is online

Users browsing this forum: No registered users and 0 guests

cron
.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software