Buck Woody : Security, Best Practices

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

More than one way to skin an Audit

BuckWoody — Thu, 20 May 2010 13:40:00 GMT

I get asked quite a bit about auditing in SQL Server. By "audit", people mean everything from tracking logins to finding out exactly who ran a particular SELECT statement.

In the really early versions of SQL Server, we didn't have a great story for very granular audits, so lots of workarounds were suggested. As time progressed, more and more audit capabilities were added to the product, and in typical database platform fashion, as we added a feature we didn't often take the others away. So now, instead of not having an option to audit actions by users, you might face the opposite problem - too many ways to audit! You can read more about the options you have for tracking users here: http://msdn.microsoft.com/en-us/library/cc280526(v=SQL.100).aspx

In SQL Server 2008, we introduced SQL Server Audit, which uses Extended Events to really get a simple way to implement high-level or granular auditing. You can read more about that here: http://msdn.microsoft.com/en-us/library/dd392015.aspx

As with any feature, you should understand what your needs are first. Auditing isn't "free" in the performance sense, so you need to make sure you're only auditing what you need to.

Backup those keys, citizen

BuckWoody — Tue, 20 Apr 2010 12:14:50 GMT

Periodically I back up the keys within my servers and databases, and when I do, I blog a reminder here. This should be part of your standard backup rotation – the keys should be backed up often enough to have at hand and again when they change.

The first key you need to back up is the Service Master Key, which each Instance already has built-in. You do that with the BACKUP SERVICE MASTER KEY command, which you can read more about here.

The second set of keys are the Database Master Keys, stored per database, if you’ve created one. You can back those up with the BACKUP MASTER KEY command, which you can read more about here.

Finally, you can use the keys to create certificates and other keys – those should also be backed up. Read more about those here.

Anyway, the important part here is the backup. Make sure you keep those keys safe!

Have you backed up your keys lately?

BuckWoody — Mon, 01 Mar 2010 14:06:04 GMT

Did you know that you already have a Server Master Key (SMK) generated for your system? That’s right – while a Database Master Key (DMK) is generated when you encrypt a certificate or Asymmetric Key with code, the Server Master Key is generated automatically when you start the Instance.

So you should back all of those keys up periodically, and then store that backup AWAY from the server itself.

There are two reasons for this – first, if the drives get stolen and you’re storing the key backup there, well, that should be obvious why that’s bad. Second, you want to protect the keys in case the system is destroyed or you can’t recover the drives. You will need those keys if you have encrypted anything in the database to get the data back.

More here: http://technet.microsoft.com/en-us/library/bb964742.aspx

No, the standard Maintenance Wizards don’t get this data. And no, I haven’t seen it addressed in most of the maintenance scripts out there anyway – sometimes for good reason, but this means you need to take care of it manually, and then document where you put that backup.

SQL Server Best Practices: Use Roles When You Can

BuckWoody — Mon, 07 Dec 2009 14:49:46 GMT

SQL Server has two major security vectors: “Principals”, which are primarily users and roles (groups), and “Securables”, which are primarily objects on the server or in the database, like tables or views. Many applications use Logins for their users, and then tie those Instance Logins to Database Users. The Database Users are then given rights and permissions to database objects like tables or stored procedures.

If you can, it’s a good idea to apply permissions not to the individual users, but to database roles. The reason is that you can move users in and out of the roles without changing the permission scheme.

It also helps if you want to transfer the database to another server. All you have to do is script out the groups and permissions, and when you transfer the database to another system you simply add the users on that system to the proper roles – no permission changes needed.