Buck Woody : Cloud Computing, Security

The Importance of Paranoia for the Technical Professional

BuckWoody — Wed, 08 Aug 2012 12:19:11 GMT

I recently read a blog post from a technical professional who’s account had been hacked (http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/all/) – not because he used poor passwords or unsafe practices, but because the hackers used some social engineering to get around the safety he had put into place.

While I won’t focus on the particulars of his situation, the interesting part of his loss was the fragility of the security of his data. In this case, he lost personal data – with no way to replace it. Two things stood out for me in his article: the chain of security through his accounts, and the single-source of data he had.

In this case, someone contacted the vendor and pretended to be this person. Using easily obtained information, they simply gained access to the account, and didn’t even have to hack the password. From there, the chain was that using various convenience-features, the hackers could delete the smartphone, and then on to the laptop the person owned. They completely wiped that out, and this is where there is an issue – he had his data on that laptop, and on the same vendor’s cloud backup. Since the hacker *was* the account owner by that time, they wiped out both. The person’s personal pictures, etc were gone forever. From there the hackers impersonated the person on Twitter and made racist and other statements to embarrass the person.

Although lots of features are available in all vendor products, I’ve always been….paranoid about using them. I try to follow the “moats and bridges” approach to security, meaning that one account or feature doesn’t lead to another. I don’t link things together that can be used to attach to more than one account, even when it's a cool new feature. One public logon from an airport’s “free” wifi (which I never use, by the way) can lead to these attacks – even if you don’t think you’re logging on. Ever check your mail from the airport? Do you have more than one mail account in your mail client? You could be hacked. I realize most client software does a good job of trying to prevent this, but I use my own MiFi device which I have set to the highest encryption I can.

I also keep lots of data in the cloud – but that’s not the only place. Periodically I have my important data backed up to a local drive,which I rotate to another secure location. After all, I’ve moved most of my books, pictures, scans, everything to a digital format. There’s no way I’m keeping that in just one place, or on just one vendor.

There are other things you can do to protect yourself – a great list is here: http://gizmodo.com/5932663/9-things-you-absolutely-must-do-to-keep-your-online-identity-secure

When I help clients design solutions on Windows Azure, I recommend another copy of the storage wherever possible – even on other vendor's cloud storage or locally on a drive, or both. I’m paranoid that way – I don’t want them to lose data. We take extraordinary precautions against losing data. Azure data has three copies on separate fault domains, and then those three are copied again to another physical datacenter automatically, that’s just built into the system. Even so, I recommend periodic backups to other
locations of data the client can’t easily re-generate.

While we provide lots of tools, information and guidance about security and protection in Windows Azure, ultimately it's up to you to properly secure your assets and plan for disaster recovery. That's true of any cloud provider - you need to learn the platform well to understand how to protect your data.

What I architect in Windows Azure I practice at home. Read that blog post, and I think you will agree it’s good to be a little paranoid. Sometimes they really are out to get you.

Should All Data Be Encrypted By Default?

BuckWoody — Tue, 09 Aug 2011 13:45:04 GMT

Recently several IT industry information outlets have reported that there has been a 10-year concentrated, organized effort on breaking through computer security at some of the largest companies in the world. Government sites have also been attacked in multiple countries. Add to this the regular loss of data by banking and other industries, and the fear of “the cloud” as a storage location, and it seems to beg the question asked in the title in this post: “should all data, everywhere, be encrypted by default?”

If you’re new to encryption, there’s an excellent video and overview here: http://blogs.msdn.com/b/plankytronixx/archive/2010/10/23/crypto-primer-understanding-encryption-public-private-key-signatures-and-certificates.aspx

If all data were encrypted, the break-in to websites would still continue, but the value would be lessened for some types of “orthogonal” attacks that only seek the pure stream of data.

Data States

Computing has two major components - static program elements and data. The program doesn’t change (until it is updated, of course) over the course of a transaction between a user and the ultimate data store. Data is classified as anything that is manipulated by the program. That implies three states of the data interchange: Creation, Transmission, and Storage. In on-premise systems, many times none of these states are encrypted. The entire system from user to data store is viewed as “secure”, which of course evidence has proved it is not. In some cases, even laptops are viewed as part of an on-premise system, and so is left unprotected. If all data were treated as “publicly viewable”, that mindset would lead to encrypting the data at all states, even for on-premise systems.

Creation

In this phase, a user, device or other input program creates data to send to the program. This can be entries on a web form, input from a weather sensor, or one service (program) sending information to another service. There are multiple ways to encrypt data at this state, most notably using client-side libraries such as the Windows Crypto API, hardware encryption and others. The reference for the Crypto API is here: http://msdn.microsoft.com/en-us/library/ms867086.aspx

Transmission

After the data is created, it needs to be transmitted to the processing and storage system. the references above explain how to secure the communications channel between the client systems and the various components used within the system. In the case of Windows Azure, the session can be protected with a secure session, and all communications within the Azure datacenters are encrypted. The key is that the transmission of data, regardless of method, should be considered to be “in the clear”, and treated as such. Without the decryption algorithm, it’s much harder to get to the ultimate goal.

Storage (data at rest)

It follows that f the data is encrypted at the source, and the decryption method is retained only with the code that processes the data, then the data “at rest” if obtained is less accessible. If the data is not encrypted at the source, then this step should be put into place at a minimum. In many cloud systems, including Windows and SQL Azure, the data is not encrypted at rest. There are various reasons for this, including performance, physical and logical security already in place, and the fact that the encryption process would expose customer data to the provider while it is being encrypted. In this case, the key is to encrypt the data before it is transmitted and stored, so that it is encrypted ahead of time.

Considerations

Encrypting data is a separate process, and must be factored into the original codebase. This means additional effort, and more CPU power for the encryption process (although many systems have security hardware included which help with this) and of course protecting the keys. If the keys are accessed, the data is considered unencrypted from then on, and all previous encryption with that particular key is now vulnerable. Key rotation and protection is essential. Even so, the benefits of treating all data as being at risk outweighs the efforts.

You can learn more about general encryption here: http://msdn.microsoft.com/en-us/library/aa380255(VS.85).aspx

Online Password Security Tactics

BuckWoody — Tue, 14 Dec 2010 14:11:24 GMT

Recently two more large databases were attacked and compromised, one at the popular Gawker Media sites and the other at McDonald’s. Every time this kind of thing happens (which is FAR too often) it should remind the technical professional to ensure that they secure their systems correctly. If you write software that stores passwords, it should be heavily encrypted, and not human-readable in any storage. I advocate a different store for the login and password, so that if one is compromised, the other is not. I also advocate that you set a bit flag when a user changes their password, and send out a reminder to change passwords if that bit isn’t changed every three or six months.

But this post is about the *other* side – what to do to secure your own passwords, especially those you use online, either in a cloud service or at a provider. While you’re not in control of these breaches, there are some things you can do to help protect yourself. Most of these are obvious, but they contain a few little twists that make the process easier.

Use Complex Passwords

This is easily stated, and probably one of the most un-heeded piece of advice. There are three main concepts here:

· Don’t use a dictionary-based word

· Use mixed case

· Use punctuation, special characters and so on

So this: password

Isn’t nearly as safe as this: P@ssw03d

Of course, this only helps if the site that stores your password encrypts it. Gawker does, so theoretically if you had the second password you’re in better shape, at least, than the first. Dictionary words are quickly broken, regardless of the encryption, so the more unusual characters you use, and the farther away from the dictionary words you get, the better.

Of course, this doesn’t help, not even a little, if the site stores the passwords in clear text, or the key to their encryption is broken. In that case…

Use a Different Password at Every Site

What? I have hundreds of sites! Are you kidding me? Nope – I’m not. If you use the same password at every site, when a site gets attacked, the attacker will store your name and password value for attacks at other sites. So the only safe thing to do is to use different names or passwords (or both) at each site. Of course, most sites use your e-mail as a username, so you’re kind of hosed there. So even though you have hundreds of sites you visit, you need to have at least a different password at each site.

But it’s easier than you think – if you use an algorithm.

What I’m describing is to pick a “root” password, and then modify that based on the site or purpose. That way, if the site is compromised, you can still use that root password for the other sites.

Let’s take that second password:

P@ssw03d

And now you can append, prepend or intersperse that password with other characters to make it unique to the site. That way you can easily remember the root password, but make it unique to the site. For instance, perhaps you read a lot of information on Gawker – how about these:

P@ssw03dRead

ReadP@ssw03d

PR@esasdw03d

If you have lots of sites, tracking even this can be difficult, so I recommend you use password software such as Password Safe or some other tool to have a secure database of your passwords at each site. DO NOT store this on the web. DO NOT use an Office document (Microsoft or otherwise) that is “encrypted” – the encryption office automation packages use is very trivial, and easily broken. A quick web search for tools to do that should show you how bad a choice this is.

Change Your Password on a Schedule

I know. It’s a real pain. And it doesn’t seem worth it…until your account gets hacked. A quick note here – whenever a site gets hacked (and I find out about it) I change the password at that site immediately (or quit doing business with them) and then change the root password on every site, as quickly as I can.

If you follow the tip above, it’s not as hard. Just add another number, year, month, day, something like that into the mix. It’s not unlike making a Primary Key in an RDBMS.

P@ssw03dRead10242010

Change the site, and then update your password database. I do this about once a month, on the first or last day, during staff meetings. (J)

If you have other tips, post them here. We can all learn from each other on this.