Video Screencast Help
As we strive to continually improve your experience on our site, please help us by taking this survey and tell us about your satisfaction level using Symantec Connect. One lucky winner will receive 500 Connect points! * Take the survey.

How to utilize SEP 12.1 for Incident Response - PART 1

Created: 23 Apr 2013 • Updated: 01 Aug 2016 | 19 comments
Language Translations
ℬrίαη's picture
+28 28 Votes
Login to vote

The purpose of this article is to provide insight on how to use the various features within SEP 12.1 for Incident Response. This will be the first in a series of articles showing you various ways to utilize SEP 12.1 for this purpose. I make no assumptions regarding your environment so this is provided "As-is." You should always test before deploying into your production environment or at the very least, understand the consequences associated with it. Let's get started.

PROBLEM: You receive a call in the middle of the night that a virus is loose on your network. SEP 12.1 appears to only be stopping a few infected files but some still remain. The technician who first noticed the infection performed a quick analysis and sent you a file which SEP does not appear to remediate. You quickly confirm this by submitting to https://www.virustotal.com and see that Symantec does not yet have a signature for this piece of malware. You head to the office and get to work. After submitting the file to Symantec Security Response, you decide to use the "Application to Monitor" feature which is inside the Exceptions policy.

As we can see, for the purposes of this article, the undetected malicous file running on PCs is called apt.exe

7.JPG

This filename needs to be added so that is can be monitored and reported back to the SEPM any time it executes.

To add, open your Exception policy and select the Exceptions tab

2_0.JPG

Click Add >> Windows Exceptions >> Application to Monitor

3_0.JPG

The "Add an Application to Monitor" windows appears and we add the filename and click "Add"

8.JPG

9.JPG

After being added, click OK to save to the policy. Once the clients check in and pickup the latest policy, this application will be monitored (Log Only) when it is executed and reported back to the SEPM. This process can take some time depending on how often your clients are configured to heart beat in so be wary of this if you don't see logs for awhile. This feature is better used in situations where the heart beat is set at a lower time interval (5-15 minutes) or especially if the clients are in Push mode. After we have waited for some time, we need to check our Application log to see if the process has showed up so we can configure an action to be taken on it when it tries to execute.

Go back to your Exception policy and select the Exceptions tab again. This time, select Add >> Windows Exception >> Application

6_0.JPG

The "Add Application Exception" window will come up, set the View to "Watched Applications"

10.JPG

This view will only show applications that you specifically added to be monitored and filters out all the others that you don't need to see at this point.

Now, we can select the apt.exe file and to the Action of your choice. I will set it to "Terminate"

11.JPG

Click OK to add to the Exception policy and you will see the new exception added using the Hash of the executable. Click OK to save to the policy

12.JPG

Once your clients pickup the new policy, SEP will now block the file from executing

13.JPG

This feature is very useful in cases where SEP is not yet detecting a malicious executable. You can use it for Incident Response purposes while Symantec creates a signature. And it will stop the further spreading of malware throughout your network.

I hope this article will be helpful for you. Comments/Questions/Criticisms are welcome!

Brian

Comments 19 CommentsJump to latest comment

ABN's picture

Amazing feature, but I was wondering can't this be accomplished by the existing Application contorl policy in SEP 11. That too does stop the application from running and also can be co-related with fingerprint. Pray correct me if I'm wrong, just trying to find the diffirence.

+1
Login to vote
ℬrίαη's picture

Sure it could. Some companies don't use Application and Device control though so this could be another option.

My aim of these articles is to show features which could be used in Incident Response. I'm not limiting it to one specific feature.

Application and Device control and Incident Response will be done in a future article.

​​

+1
Login to vote
ABN's picture

Hi Brian,

My Apoliges, my intentions was only to get clarified. I did not test the Aplication Device control feature completley. Application and device control is still not supported on 64 Bit platforms as of SEP RU 7. It is supported in SEP 12.1.

+2
Login to vote
John Santana's picture

thank you for sharing !

Kind regards,

John Santana
IT Professional

-----------------------

The author cannot accept liability for any loss or damage sustained as a result of the content of this post.

+2
Login to vote
technical_specialist's picture

Nice feature. I will use this.yes

+3
Login to vote
Chetan Savade's picture

Nice article !!!

Chetan Savade
Social Media Support Lead
Enterprise Technical Support
CCNA | CCNP | MCSE | SCTS |

Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<

+1
Login to vote
SecondXL's picture

very useful, thanks for sharing! 

+1
Login to vote
nwranich's picture

Great article.  This had me confused for a while.

+1
Login to vote
Rodrigo Calvo's picture

Hi _Brian

Great article, as a suggestion, before upload to  virutotal try to upload using ThreatExpert Submission Applet http://www.threatexpert.com/submissionapplet.aspx , you will receive more technical detail about the file .

Regards

Rodrigo

+1
Login to vote
ℬrίαη's picture

Part 3 is now available:

How to utilize SEP 12.1 for Incident Response - PART 3

https://www-secure.symantec.com/connect/articles/h...

​​

+2
Login to vote
sdc's picture

Hi Brian,

 Why do  we use  "apt.exe" ?  Thanks for sharing.

Regards,

0
Login to vote
ℬrίαη's picture

It was only used as an example for the purpose of this article.

​​

0
Login to vote
ℬrίαη's picture

Links to Part 2,3, and 4 as well

How to utilize SEP 12.1 for Incident Response - PART 2

https://www-secure.symantec.com/connect/articles/h...

How to utilize SEP 12.1 for Incident Response - PART 3

https://www-secure.symantec.com/connect/articles/h...

How to utilize SEP 12.1 for Incident Response - PART 4

https://www-secure.symantec.com/connect/articles/h...

​​

0
Login to vote
SMahieddine11's picture

Est ce que tu peux refaire les articles en français s.v.p

0
Login to vote
ℬrίαη's picture

I don't speak it. Sorry.

​​

0
Login to vote
anekkab's picture

Bonjour,

Tu peux utiliser Google translator pour les URL:

https://translate.googleusercontent.com/translate_...

Hi

You can use google translator 

Best Regards

0
Login to vote
MIXIT's picture

Why o why did I wait until now to start reading these?  I've only read Part 1 so far but wtf am I doing with myself that I didn't know you could do this stuff in the Exceptions policy.  I always thought that thing was just for excluding certain files from scrutiny. 

One thing though:  why does Symantec design it that you have to wait until the file is actually encountered before you can then go into SEPM and efine an action?  Your article was in 2013, but this still seems to be the case in today's version of SEP.  (Aug 25 2016).  I'm only asking because it seems odd that the logic would be to allow a system to runa  virus first, before diong anything about it, when you could in theory specify the filename in advance and stop it from happening. 

Or is that the role of Application Control?  (another item I have not yet used in 7 years of SEP admin). 

Must be something with the generated hashes and file uniqueness. 

0
Login to vote