Just a reminder to the tool
http://simile.mit.edu/wiki/Timeline
as i always have trouble tracking it down
UPDATE
Now moved to http://www.simile-widgets.org/
Example of the sort of things it can do
http://www.simile-widgets.org/timeline/examples/jfk/jfk.html
Sunday, May 16, 2010
Tuesday, May 4, 2010
Threat Modelling Process
A general high level overview of common steps in the defensive perspective threat modeling are:
* Define the application requirements:
o Identify business objectives
o Identify user roles that will interact with the application
o Identify the data the application will manipulate
o Identify the use cases for operating on that data that the application will facilitate
* Model the application architecture
o Model the components of the application
o Model the service roles that the components will act under
o Model any external dependencies
o Model the calls from roles, to components and eventually to the data store for each use case as identified above
* Identify any threats to the confidentiality, availability and integrity of the data and the application based on the data access control matrix that your application should be enforcing
* Assign risk values and determine the risk responses
* Determine the countermeasures to implement based on your chosen risk responses
* Continually update the threat model based on the emerging security landscape.
* Define the application requirements:
o Identify business objectives
o Identify user roles that will interact with the application
o Identify the data the application will manipulate
o Identify the use cases for operating on that data that the application will facilitate
* Model the application architecture
o Model the components of the application
o Model the service roles that the components will act under
o Model any external dependencies
o Model the calls from roles, to components and eventually to the data store for each use case as identified above
* Identify any threats to the confidentiality, availability and integrity of the data and the application based on the data access control matrix that your application should be enforcing
* Assign risk values and determine the risk responses
* Determine the countermeasures to implement based on your chosen risk responses
* Continually update the threat model based on the emerging security landscape.
Sunday, May 2, 2010
Protecting Against Password Reset Attacks
Protecting Against Password Reset Attacks
from Security Bloggers Network by Randy Abrams
As I previously blogged today, the hacker who broke into Sarah Palin’s Yahoo account was convicted on two charges. The way that David Kernall gained access to Palin’s email account was by trying to log into her account, saying “I forgot my password” and then he correctly answered the password reset questions. Some of the questions had answer’s that were public information and others were easily guessed.
When you have to choose a password reset question, always use the wrong answer. There is typically only one correct answer to the questions and often times the answer is known by others. There are an infinite number of wrong answers so it is extremely difficult for an attacker to correctly answer the rest questions if you use the wrong answer.
Now, here’s the tricky part… How do YOU remember the wrong answers? You can write them down. You can use tricks such as a theme. For example, if you like Star Wars, then perhaps your first car was the Millennium Falcon. You first pet was a wookie. For me, I use the comment field in Password Corral.
The password reset attack is a fairly easy attack, but fortunately the defense is also quite easy too!
from Security Bloggers Network by Randy Abrams
As I previously blogged today, the hacker who broke into Sarah Palin’s Yahoo account was convicted on two charges. The way that David Kernall gained access to Palin’s email account was by trying to log into her account, saying “I forgot my password” and then he correctly answered the password reset questions. Some of the questions had answer’s that were public information and others were easily guessed.
When you have to choose a password reset question, always use the wrong answer. There is typically only one correct answer to the questions and often times the answer is known by others. There are an infinite number of wrong answers so it is extremely difficult for an attacker to correctly answer the rest questions if you use the wrong answer.
Now, here’s the tricky part… How do YOU remember the wrong answers? You can write them down. You can use tricks such as a theme. For example, if you like Star Wars, then perhaps your first car was the Millennium Falcon. You first pet was a wookie. For me, I use the comment field in Password Corral.
The password reset attack is a fairly easy attack, but fortunately the defense is also quite easy too!
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.
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