Archive for the ‘Security Architecture and Design’ Category
Monday, June 29th, 2009
With the death of Michael Jackson last week, Google saw an unprecedented level of Michael Jackson related searches. The most impressive thing about Google’s response is that they apparently deploy captcha tests on demand only when they think there is an automated attack going on. As someone who hates having to type in those letters printing in the most unreadable manner possible, I think this is a great step up.
Tags: captcha, google, Michael Jackson Posted in Security Architecture and Design | Comments Off
Tuesday, June 16th, 2009
A few weeks ago Trustwave reported on a new piece of malware that targets ATMs. This sparked a conversation in Bruce Schneier’s blog about the value of running a well known commercial OS (like Windows) on a limited use device (like an ATM or voting machine). The debate has centered around the fact that commercial operating systems have well known vulnerabilities which can be targeted by black hats. This has of course raised calls of security through obscurity.
I’ve been doing a lot of work in this area of late, and I think the debate is missing the point. Writing a custom OS for a custom piece of hardware is not more secure than a Windows OS on a Intel chip because it’s less common, it’s more secure because it does less. A windows machine is general purpose – it can be used to surf the web, read PDF documents, play movies, edit images, send email, and transfer files. An ATM should do none of those things. If you were making an ATM from scratch and not using Windows, you would undoubtedly write a very small custom OS that would only perform the dozen or so functions that an ATM actually needs to do. It is not more secure because it is obscure, it is more secure because there is less of it to be insecure.
Tags: ATM, embedded devices, security though obscurity, voting machine, windows Posted in Security Architecture and Design | Comments Off
Wednesday, February 11th, 2009
While trying to dig up the conversion rate for phishing attacks in the previous post, I stumbled across some very interesting findings from paypal on their anti-phishing techniques. Paypal has actually managed to put together a fairly decent anti-phishing program. Most importantly – it works! (It is amazing how many people implement anti-phishing strategies that don’t work). They have implemented a multi-pronged approach to combating phishing, smartly realizing that there is no single strategy that will work. You can read their whole white paper (which I highly recommend), but here are the highlights:
Honestly this looks like a pretty good and fairly comprehensive anti-phishing program. Some of those things (SPF and DKIM in particular) are things which have had an immediate impact for Paypal, and should have an immediate impact for anyone who implements them. They can also be implemented for minimal cost. IMHO, the industry should be getting behind these initiatives big time as it will have an almost immediate positive impact on their bottom lines, as well as making users happier with less spam.
Tags: , DKIM, paypal, phishing, SPF Posted in Security Architecture and Design | Comments Off
Tuesday, May 6th, 2008
When dealing with any kind of security, whether physical or electronic, there are two kinds of attacks to worry about – those that are picking their targets based on opportunity, and those that are picking their targets based on intent. To borrow a common example, a target of opportunity is simply walking down the street trying to door handle on every car looking for one that is unlocked, while a target of intent is trying to steal a specific car. When it comes to the internet, many large entities (especially government organizations) are regular targets of intent. On the other hand things like viruses and worms that scan indiscriminately for unpatched systems are perfect examples of targets of opportunity.
Most internet organizations currently consider both lines of attack when designing a security plan, although this may start to change if IPv6 ever becomes a full fledged reality. (Whether or not IPV6 ever does gain wide acceptance is not a matter I care to speculate on). Since IPv6 uses 128 bit IP addresses, (IPv4 uses 32 bit addresses), there will be approximately 3.4×1038 total IP addresses. Even small organizations could have IP spaces that dwarf the entire IPv4 address space. Scanning random IPv6 addresses looking for targets will likely become an exercise in futility. One way attackers will have to adapt in an all IPv6 world is to spend much more time footprinting their targets – trying to find specific system’s through publicly available information sources before attacking them. Parts of this process can clearly be automated by opportunists. For example, an attacker could use Google to find web servers at random and then check them for web specific flaws. However, this will likely deter several common methods of finding targets of opportunity. The danger to this of course is that internet organizations will get lazy and assume that if they can simply hide something in the larger IP space it will never be found. As well know, difficult does not mean impossible.
Tags: future, ipv6, security through obscurity Posted in Security Architecture and Design | Comments Off
Tuesday, April 22nd, 2008
Far too much time is spent worrying whether passwords are strong or not. The main weakness passwords encounter though is not the string that defines them, but the human being that remembers them. In short, all passwords are weak, and it has nothing to do with string length, complexity, or password change rules.
Recently I got an email from someone I am close to which included his new password. It was not accidental or coerced – he simply mentioned it in his email (which went to about 5 or 6 people, myself included), as part of a funny anecdote. Now this person is not stupid. He is a practicing lawyer who works for the state government and has argued several times in front of his state supreme court. As a security professional I felt it my duty to inform him of the necessity of protecting passwords, but I know that it did no good. He reacted nonchalantly and simply did not seem to care. (It is also clear that he is not alone).
IT folks have a tendency to blame the employee who gave out (or wrote down) their password, but the truth is the fault cannot ultimately lie with them. Competent clerks, secretaries, lawyers, doctors, and others who were born a generation prior to the explosion of the internet cannot be expected to be an expert in IT security, or even to understand anything about IT. The fault belongs to the people who architected the system and placed everyday users in the frontline position against attackers. I hate to harp on a single topic, but security systems must be transparent to be effective. The frontline defense against attacks should not be the users – it should be the trained security professionals. Making the least qualified people the first line of defense against attackers will always be a losing position.
Tags: passwords, transparency Posted in Security Architecture and Design | Comments Off
Sunday, April 6th, 2008
People frequently wonder what makes a good security system. One of the frequently overlooked aspects is transparency. Simply put, the more transparent a system is, the less it will be noticed by the users. The reason for this is simple – users are frequently the most vulnerable link in the security chain. Worse than that, if users perceive a security control to be an inconvenience, they will actively work to circumvent it.
I’ll take a simple example from my own life. The corporate laptop I use came with antivirus software installed. The software kept picking up a password cracking tool I was trying to use as a virus. (As a security analyst a password cracking tool is a legitimate part of my job). I tried to write an exception into the AV software, but I didn’t have the appropriate permissions. Eventually I had no choice but to simply disable the antivirus software entirely. There are thousands of similar stories – employees propping doors open because there is no way to re-enter through a back door, sending sensitive information in the clear when a secure method of transmission can’t be located quickly, setting up rogue wireless access points, or a programmer writing a script which contains all of his or her login information to various internal systems. The bottom line is that security which is invisible is far less likely to be circumvented by frustrated users.
Tags: fundamentals, transparency Posted in Security Architecture and Design | Comments Off
|