Saturday, April 24, 2010
Friday, April 23, 2010
Block, Quarantine or Delete?
Taken from http://www.sophos.com/blogs/chetw/g/2010/04/23/mcafee-fix-dangers-virus-handling
McAfee fix and the dangers of virus handling
from Security Bloggers Network by Chester Wisniewski, Sophos
In the security world the news has been dominated for the last 48 hours with tales of woe regarding the false-positive some McAfee customers encountered with svchost.exe. McAfee customers who have run into the problem can find detailed advice on fixing the issue in McAfee KB68780.
Our emotions regarding malware often lead us astray. Instinctively we want to delete or quarantine malware. McAfee's situation shows why this is a bad idea. According to their KB article if your system experienced this issue your copy of C:\Windows\System32\svchosts.exe has either been quarantined or deleted.
When I was in the Sales Engineering department here at Sophos it seemed to be a full-time job explaining to prospects why it was a bad idea to delete or quarantine viruses and other malware. Why on earth would I want a known malicious file to remain on my PC?
Upon the discovery of malicious code, anti-virus solutions are unable to determine with 100% confidence whether the file in question is required to boot, or required for the regular operation of your PC. As a safety precaution it is best to prevent access to the identified file, but leave it in place and by no means delete it. Viruses often infect critical drivers and other key components of the operating system. If you delete these files upon detection (or even move them) you create a much more difficult recovery process.
Fortunately in this case, McAfee customers are able to boot into Safe Mode and take the actions necessary to restore the computer to a fully working state. There is still a lot of manual work involved, but it does not require you to boot a live CD or USB stick to save the system. In cases where more important files have been moved it can be difficult if not impossible to fix once the files have been tampered with.
My Point? For everyday computers in your workplace the best practice is to attempt to cleanup viruses, but not move them to a central area or delete them permanently. For extremely risk-averse environments and mission critical systems you may wish to be more conservative and simply block access to the file and require a human to take action before making system modifications.
The good news is that false positives are few and far between. Recovery is difficult enough, don't complicate it more than necessary.
Take it from an expert - don't transport malware around your computer/network, clean it up in place, and do your best to do no harm.
McAfee fix and the dangers of virus handling
from Security Bloggers Network by Chester Wisniewski, Sophos
In the security world the news has been dominated for the last 48 hours with tales of woe regarding the false-positive some McAfee customers encountered with svchost.exe. McAfee customers who have run into the problem can find detailed advice on fixing the issue in McAfee KB68780.
Our emotions regarding malware often lead us astray. Instinctively we want to delete or quarantine malware. McAfee's situation shows why this is a bad idea. According to their KB article if your system experienced this issue your copy of C:\Windows\System32\svchosts.exe has either been quarantined or deleted.
When I was in the Sales Engineering department here at Sophos it seemed to be a full-time job explaining to prospects why it was a bad idea to delete or quarantine viruses and other malware. Why on earth would I want a known malicious file to remain on my PC?
Upon the discovery of malicious code, anti-virus solutions are unable to determine with 100% confidence whether the file in question is required to boot, or required for the regular operation of your PC. As a safety precaution it is best to prevent access to the identified file, but leave it in place and by no means delete it. Viruses often infect critical drivers and other key components of the operating system. If you delete these files upon detection (or even move them) you create a much more difficult recovery process.
Fortunately in this case, McAfee customers are able to boot into Safe Mode and take the actions necessary to restore the computer to a fully working state. There is still a lot of manual work involved, but it does not require you to boot a live CD or USB stick to save the system. In cases where more important files have been moved it can be difficult if not impossible to fix once the files have been tampered with.
My Point? For everyday computers in your workplace the best practice is to attempt to cleanup viruses, but not move them to a central area or delete them permanently. For extremely risk-averse environments and mission critical systems you may wish to be more conservative and simply block access to the file and require a human to take action before making system modifications.
The good news is that false positives are few and far between. Recovery is difficult enough, don't complicate it more than necessary.
Take it from an expert - don't transport malware around your computer/network, clean it up in place, and do your best to do no harm.
Labels:
incident response,
procedure,
process,
security,
vulnerability
Friday, April 16, 2010
Sophos 'threatasaurus' pdf
http://www.sophos.com/sophos/docs/eng/papers/sophos-threatsaurus-a-z-en.pdf
Insider threat
HSBC Database Breach Highlights Lack Of Accountability For IT Super Users
http://www.darkreading.com/shared/printableArticle.jhtml?articleID=224200365
Insiders Not The Real Database Threat
http://www.darkreading.com/blog/archives/2010/03/database_inside.html?print=true
http://www.darkreading.com/shared/printableArticle.jhtml?articleID=224200365
Insiders Not The Real Database Threat
http://www.darkreading.com/blog/archives/2010/03/database_inside.html?print=true
Converting epoch time
Convert from epoch time to standard date/time
perl -e 'print scalar(localtime(1226424300)), "\n"'
Wed Nov 12 01:25:00 2008
Convert from standard date/time to epoch time
perl -e 'use Time::Local; print timelocal(0,25,1,11,11,2008), "\n";'
1228929900
perl -e 'print scalar(localtime(1226424300)), "\n"'
Wed Nov 12 01:25:00 2008
Convert from standard date/time to epoch time
perl -e 'use Time::Local; print timelocal(0,25,1,11,11,2008), "\n";'
1228929900
nessus update
The list below outlines the changes included in the 4.2.2 release:
- nessus-fetch binary:
- Proxy authentication now works on Windows
- Proxy authentication (NTLM) with a username and domain now works
- In some cases, the last nessus-fetch.rc statement might be ignored
Wednesday, April 14, 2010
Friday, April 9, 2010
Interesting password generating web page
Could be hosted on any LAN or Intranet
http://code.google.com/p/hype-free/source/browse/trunk/js_password_generator.html
http://code.google.com/p/hype-free/source/browse/trunk/js_password_generator.html
Friday, April 2, 2010
VMWare security appliance
Interesting security appliance to manage the interactions between the admins and the infrastructure. also can provide non admin users with access to admin level access without ever providing password. covers audit as well.
http://www.hytrust.com/
http://www.hytrust.com/
Thursday, April 1, 2010
Cisco ASA/PIX firewall rule checker
Interesting open source VM for checking the rules of Cisco ASA/PIX firewalls. Open source firewalls like iptabes coming soon
http://runplaybook.com/p/11
http://runplaybook.com/p/11