Securing THE CLOUD

Dilbert.com

One of the primary purposes for this blog is to talk about information security.  An appropriate first post on the topic is Securing THE CLOUD.

Cloud is one of those words I don’t like to use.  It was drummed up by marketing gurus to make an old idea sound new.  All the cloud means to me is putting your stuff on somebody else’s servers.  Generally that stuff is accessible from anywhere on the internet, although they have coined the term ‘private cloud’ to describe a scenario where access is more limited.  I digress.

As a developer for the cloud, the stakes are high for you.  Customers are entrusting you to protect their stuff which is logically connected every internet user on the planet (potentially sans N. Korea, Iran, China, et al.).

Here is a checklist that I like to think of when I’m evaluating the security of a cloud product.  I suppose you could turn it around and use it as a howto guide.  Just a quick caveat.  I am not a programmer.  I stopped programming as soon as I realized just how bad I am at it.  You know what they say, “those who can’t do manage”.

  1. Guard the front gates with everything you have.  Every restricted-access cloud service sits behind an authentication layer.  That is your first line of defense.  The first line of code on every page (figuratively) should be an authentication/authorization check.
  2. Don’t even think of writing your own authentication system.  Let somebody else do that for you.  Trust me, they are much better at it than you are.  Use Microsoft ID (aka LiveID), Open ID, Google ID, Facebook ID.  Better yet, let them pick.  Your customers will thank you because that is one less password they have to remember.http://msdn.microsoft.com/en-us/library/bb676633.aspx
  3. Don’t let the bad guy pretend to be a legitimate user.  How do they do that?  Cross-site scripting (XSS) is the most common vulnerability I run across in the wild.  That is followed closely by cross-site request forgery (CSRF).  Both of these can be leveraged by an attacker to cause a user to shoot themselves in the foot.   This is a huge topic which probably warrants its own post.  I’ll try to break it down.
    • sanitize! sanitize! sanitize! Consider every piece of data which is ever in a user’s possession as evil. This includes cookies, form variables, url parameters, and uploaded files. They are all evil and must be stopped.  I do mean everything.  Use somebody else’s form sanitization library.  Again, they have thought of things you haven’t.  http://blogs.msdn.com/b/securitytools/archive/2010/09/30/antixss_2d00_4_2d00_0_2d00_release_2d00_notes.aspx
    • Canaries are your friend.  This is the only effective way to prevent cross-site request forgery.  Multi-step forms don’t work.  Cookies don’t work.  Use a challenge-response system with canaries to validate that a user really just came from one of your pages.
      https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
      _Prevention_Cheat_Sheet
    • Use HTTP commands as designed.  Never change state with an HTTP GET.  Use a POST.  It may take some extra JavaScript foo, but it is much harder to attack.
    • Scan every version of your code.  There are a number of automated XSS scanners on the market.  They are pretty good at finding script kiddie vulnerabilities.  If you are a juicy enough of a target to warrant attention by ‘advanced’ researchers’, you may want to invest in a second set of eyes.  Trust me, an expert pentest crew is a whole lot cheaper than getting horribly owned.
  4. Don’t do dumb things with SQL.  It never ceases to amaze me that SQL injection still works. Use stored procedures for everything.  Also, building an SQL string in a stored procedure and EXECing it is just as bad as parameterized SQL.  Don’t do it.
  5. SSL is good.  If the data is important enough to put behind a login page, it is important enough to protect with SSL.  Period.
  6. Protect data in storage.  This is a topic I am planning on writing a dedicated post about.  The news is full of companies whose data has been stolen and put on pastebin or similar.  If it shouldn’t be shown to the world, it should be encrypted.  Stay tuned for the specifics of this.

As I write this, you may notice that none of these items are specific to the cloud.  These are all best practices for developing on the internet in general.  That is because they are the same thing.  Cloud == internet, internet == cloud.  Marketing will say what marketing will say.  For the rest of us, nothing has changed.  The web is still the web.  If you can secure one, you can secure the other.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s