Tuesday, March 31, 2009

The business of security is business

"Security decisions are business, not technical, decisions".
Gunnar Peterson in IEEE Security and Privacy

Yes exactly. Decisions of authentication and authorization are not technical procedures which are grafted onto an application in order to make it "more secure", they are what enables it in the first place.

Take the example of one of Vordel's customers, an insurance company which receives insurance "new business" information from a bank. These documents, formatted as XML (XML wrapped in XML, in some cases) includes private information which can only be accessed by the appropriate, authorized people. Without authentication and authorization, the solution is impossible.

Consider the common Venture Capitalist question "What would happen if your product didn't exist?". With a perimeter security product like a firewall, the answer is often "The application would be less secure". The application would work fine, but be prone to attack. But, when security decisions are part of the business application itself, the answer is that without the product in place (in this case an XML Gateway), the application itself cannot exist.

Wednesday, March 25, 2009

"Identity in the Clouds”

Next month in London I'm speaking at the Open Group practitioners conference which focuses on "Identity in the Clouds". Note that it's "Identity in the Clouds" rather than "Identity in the Cloud", since one of the key issues for identity in Cloud Computing is to tie disparate identity systems together.

For example, if a local application calls up to a Force.com service, the identity of the client must flow up to the Force.com service. The pivot point which connects the local applications to the Cloud is an XML Gateway . If a user is using a local application, and that application is connecting to a Cloud-based service (e.g. to Amazon's S3 storage service), then that connection must be managed based on the identity of the user, not only based on the client application. The decision should not only be "is this application allowed to put data up into Amazon S3?", but "Is this particular user running this particular application allowed to put this particular data up onto Amazon S3?". This is the level of control which the Vordel XML Gateway Cloud Edition can provide. It becomes especially important if local applications are using other Cloud services from multiple providers (i.e. "identity in the clouds" not just "identity in the cloud").

Here, from the Open Group site, is a picture of clouds over London:

Friday, March 13, 2009

Sniffing keystrokes from thin air

This kind of research is like catnip for infosec professionals: a study about deducing keyboard strokes by monitoring electromagnetic radiation. It reminds me that it's long been known that you can "listen" to conversations inside a building by pointing a laser rangefinder at nearby windows, and picking up the window flexes which act just like a speaker. Presumably the same technique be used to "listen" to keyboard strokes of people writing documents and emailing within a building...

SOA Security - The Basics

Published today - SOA Security - The Basics in CSO Magazine. Covering threat mitigation, identity standards, and future directions related to Cloud Computing.

Tuesday, March 3, 2009

White House removes YouTube embeddeding from its website

The Register and the Washington Post both report that the White House has removed YouTube from its site since it was setting cookies which tracked viewers to the whitehouse.gov site, even if the website visitors did not actually play the video.

Taking a step back: Maybe the worrying thing about embedding third-party components on your website should be.... embedding third-party components on your website. Remember the furor about ActiveX - which was for embedding components on websites and in applications? When did people lose the fear about embedding third-party video, maps, and social networking onto their sites?

I gave a presentation at RSA 2007 about security risks in Web 2.0, including attacks such as JavaScript hijacking. If you can get your code to run in someone else's Web page, then you have many options - both commercial (tracking cookies) and malicious (JavaScript hijacking). Click on the image below to get the full presentation.



The solution is to vet third-party components before their JavaScript is blindly copied-and-pasted into a website. Also, the content of these JavaScript components (e.g. code which is setting a cookie, or "phoning home" using an XMLHttpRequest) must be scanned, using an XML Gateway. Otherwise, the attractions of Web 2.0 end up becoming major security and privacy risks.