Practical Information Security

One of the things that concerns me about the direction of Information Security as a discipline is the focus on what I call "gee whiz security". This is the flashy, trendy stuff like new attacks and the marketing terms of the moment (that often are actually meaningful terms that marketing people misuse or misappropriate). It is good to stay on top of new developments, new attack vectors, new defense ideas, etc. but (for most of us that are employed by a company) our job is to provide solutions to solve these issues or provide suggestions on how to mitigate the risks associated with these threats. If all you provide is a constant stream of risks and concerns without any meaningful solutions or ideas on how to manage a problem, your employer is likely going to have to look elsewhere. This is why when folks ask me about penetration testing as a career choice I advise them to consider a more balanced approach. You can find any number of people or companies that will tell you

So by now you have likely heard of the April 20th anti-virus signatures released by McAfee which had negative effects on various systems (mostly it seems Windows XP SP3). More details here Judging from the responses from administrators, etc. this seemed to have caused a number of outages of various levels (including at least one 911 call center documented in an article on isc.sans.org ). This is not the first time that automatic updates of software (either patches, anti-virus updates, etc.) have caused unexpected results on systems. This should be a reminder to all who are responsible for the maintenance of systems or software that you still can not trust that software from a vendor will always work on all of the environments that you are responsible for. In previous engagements I've had to respond to outages caused by patches or updates, and after going though this a couple times it was decided that the solution was to centralize the deployment of patches/Anti-virus update

Recent developments in privacy decisions should have both H.R. departments, internal investigations teams, and employees re-evaluating what is private, and what is not. A couple recent decisions to be aware of: This is in progress at the Supreme Court, but is based on a case from California where a police officer used a work issued device to send inappropriate messages (even though his supervisor at one time said that the department allowed personal use if he paid for the usage fees). http://www.cnn.com/2010/LIVING/worklife/04/20/work.text.email.privacy/index.html?hpt=Sbin Another recent decision from the New Jersey Supreme Court. The summary is that an employer can not read email messages sent via a third-party email service provider -- even if the emails are accessed during work hours from a company PC. This is a bit more complex because it has to do with communication to legal counsel (privileged communication). But it is an important thing to consider, just because you

SANS Forensics Blog Great resource for the latest for legal issues, tools, and ideas about forensics and e-discovery. One of the stories (the Zeus trojan) reminds me of a previous engagement with a company. They had a number of consistent compromises of internal systems and then also external (non-employee) brokers that used our systems and became compromised. During the SEC investigation they found that the company was responsible for inadequate security controls on the brokers systems, and that the SEC held them responsible for allowing insecure computers to connect to financial systems. So keep that in mind, your customer's security may be your business.

So there has been an article going around the IT/Security community a bit today that was an eye opener to many - and old news to most of us. http://www.boston.com/bostonglobe/ideas/articles/2010/04/11/please_do_not_change_your_password/ This article starts with the catchy title "Please do not change your password" and alludes that it is better for users NOT to change passwords than to change passwords. I don't disagree that passwords are often more trouble than they are worth, and they can themselves become a weakness. This is not news folks, if you ask any certified InfoSec professional, they should advise you that multi-factor authentication is the right choice if you are serious about protecting access. One of the challenges has been to date that implementing this level of control is expensive and not usually done for leisure activities/web sites. Any organization that is still relying on simple passwords as a security control in 2010 deserves the hacking that

Interesting story out of Europe (home of very strict and confusing privacy regulations). Sounds like the German police think paying for stolen data that they can't get legitimately is a good idea? Thursday, April 8, 2010 German Government Pays Hacker For Stolen Bank Account Data By Ryan Barnett 04/08/2010 The latest entry to the WASC Web Hacking Incident Database (WHID) is pretty interesting (below). The attack method is currently unknown (most likely candidate is SQL Injection due to bulk extraction of account holder data) however this story is a really good discussion topic and is why it is being included in WHID at this time. The short of it is that someone hacked into some banks in Germany and Switzerland and stole account data about customers. Many of the banks are used as havens for people to hide their money for tax evasion purposes. The banks identified that this happened and did not notify their customers that their data was stolen. Well, the attacker decided to

So, are the days of Network port scanners behind us? or do organizations still use these tools as part of a proactive/preventative service? I can certainly see when you could use a network port scanner to validate that a machine that is behaving suspiciously is listening on ports that is shouldn't, but wouldn't proper log monitoring, SIM/SIEM, and end point/HIDS systems catch that before it would ever be detected via a network based scan? From a compliance perspective I can see the need to assess the configuration of key systems, but again there are probably better ways to do this (again using endpoint protection, integrity/configuration management tools, and compliance type tools) than what you can accomplish with a network based scanner. Thoughts?