Download our in-depth report: The Ultimate Guide to IT Security VendorsHappy New Year. Its now 2008 and what do we have to show for it? Seriously, its not a rhetorical questionits one that every information security person and organization should be asking, and the beginning of a new year is as good a time as any. Really.
So, rather than rattle off a list of accomplishments or predictions, Im going to use this space this month to provide some food for thought, just as Ive done in past Januaries.
Profit. Weve all witnessed how attackers have increasingly adopted for-profit motivations over the past 5 or so years. That whipped cream is out of the can now, and we shouldnt expect it to change ever. Behind all those spam emails, all those malware attacks, all those zero-day exploits, all those phishing schemes, all those botnets, all of itlies a living breathing criminal intent on making boatloads of money. Theyre just as happy to get their money from you, your customers, or the next guy. And theyre not going to give up.https://o1.qnsr.com/log/p.gif?;n=203;c=204650394;s=9477;x=7936;f=201801171506010;u=j;z=TIMESTAMP;a=20392931;e=i
|Security and the Politics of Fear
Norton Internet Security 2008: Faster, Stronger
Microsoft's New Patent: The Dark Side of SaaS
Google's Android vs. Apple's iPhone: Which is More Secure?|
That said, the attackers are running businesses. It is our job to present them with a target that is cost-prohibitive for them to go after. If it costs them too much to attack you, theyll find less expensive targets.
That is the state of the world we live in. Accept it and get on with business.
CSRF. I know not many IT security folks watch the Open Web Application Security Project (OWASP) top-10 list, but theres one hidden in their 2007 list that should be getting a lot more attentionCross Site Request Forgery, or CSRF. OWASP defines CSRF as, A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
Sure enough, that sounds bad, but if anything, the badness is understated. You see, CSRF attacks generally hide in image requests on web pages or in HTML emails. (Ill bet your email client is configured to render HTML content by default, and to load requested images, right?) The problem that comes in is because in HTML, image requests can contain any valid HTML including parameters. Whats the big deal, you say? Well, an example cited in the OWASP details describes how a miscreant could reprogram a home router/firewall to allow incoming packets on any arbitrary TCP/UDP portall it takes is a router with a default password (admin, anyone?).
Since the browser, by way of the image request, sends a packet along with any active cookies to the third party site, the third party site believes the request is legitimate.
The vast majority of todays web sites are affected by this issue. As OWASP puts it, Unfortunately, today, most web applications rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, SSL certificates, or Windows domain credentials.
Having said all that, the sky is surely not going to fall any time soon (so far as I know). CSRF vulnerabilities can be avoided in our web applications, but in most cases, the solution involves some fairly significant recoding of every page of every web app. Time consuming and costly.
Now, Im not a FUD guy, really. But I do know software well enough to recognize a major problem when I see one. I expect well be hearing a lot more of CSRF over the next year or so.
Multics. Why would a 1960s era operating system be on a 2008 New Years column list, you ask? It turns out that a lot of seminal work in information security was done in and around the Multics system over several years. It also turns out that many of us in todays Web 2.0, hyper-connected, supercomputer-in-a-smart-phone world have failed to learn much, if anything, from what those visionaries tried to teach us in the 60s and 70s. I, for one, would sure like to see some of those lessons dusted off and re-introduced to our software developers today. That is why I put it here on this list. (I plan to elaborate on this here over the year.)
Welcome 2008. I hope its a good one for all of us. But in our rush to make our systems PCI compliant and such, lets take a moment to make sure were addressing whats really important.