Voice of the DBA

Tag: security

  • Anonymous Research

    Anonymity is important

    It’s no secret that anonomizing data doesn’t always work well. We have heard about this when Netflix released their data for people to build algorithms with. Some people were identified based on the data released being correlated with other data the people had entered on the Internet themselves. I know that there are dangers with sharing too much information on the Internet, but people are going to share and there will only be more services in the future for us to use that require data.

    I ran across a post recently from Microsoft researchers that showed similar issues with other anonymous data sets that contain IP information. A number of logs containing traffic from Bing and Hotmail were analyzed with the intention of identifying particular hosts. Even when the data was anonymized, it was possible to identify hosts with a high degree of accuracy.

    You might not think this is a big deal, but as more data is gathered by companies and used for secondary purposes, like analysis, it becomes more likely to be inappropriately released. Is a log on a server more secure, or a copies of multiple logs on analysts’ laptops? I’d think the former, or at least I’d hope the former. If that’s true, then we should really be anonymizing data on a regular basis once it leaves hardened server machines.

    That means we ought to have better algorithms for preventing any identifying information from being retrieved. I would hope that this is an area where research can help, and one that receives a lot of attention in the near future.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Encryption in Production

    WWII era encryption with the Enigma Machine

    The encryption capabilities of SQL Server have been growing in each new version. We have gone from password protected backups to Transparent Data Encryption (TDE), we have moved form PWDENCRYPT() to symmetric, asymmetric keys, and certificates. There are quite a few options available in the current SQL Server platform. However I don’t often see people writing or talking about their use of security.

    It might be the nature of sensitive data means keeping the use of encryption quiet, but that shouldn’t matter. If you are keeping your keys safe, the algorithms and deployments you use should not matter. This Friday I wanted to ask a question about your use of encryption in real world systems.

    If you have sensitive information (identity/financial/medical) data in a database, have you deployed encryption?

    I would like to know if you’ve actually implemented native or third party encryption and if so, in what percentage of the databases that have sensitive information is encrpytion deployed. Do you strip out data before you store it, perhaps only storing something like the last four digits of a credit card in plain text? How diligent do you think your employer is being with regards to encryption?

    If you work with encryption, are you confident that you can recover your systems in a disaster? That’s one question I’d want to be sure I could answer before I deployed any keys in my database.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Insider Security Threats

    Monitoring is the key to really good security.

    Are you worried about internal users at your company compromising your data security? I’d hope that you are at least a little worried, after all, we find out regularly that people we thought we knew acted in a surprising manner, or did something inappropriate that we hadn’t expected. It’s not always malicious or intentional, but even when it’s accidental, our security gets compromised and we receive some of the blame.

    Security is a hard process to implement, especially over time. Too much security implies too little trust, and as humans, we want to trust each other. As we work together, and build trust, we tend to let security lapse a bit. As organizations grow, evolve, and change people around, we introduce security loopholes from mis-configurations, poor architectural foundations, or simple mistakes like failing to remove someone from a security role.

    This piece talks a bit about the internal security threats you face, while ranting a bit about the term “insider threat”. The threats you face from external attackers are different from those you face from internal employees. However in each case, there’s one thing that’s important for getting close to a secure environment: monitoring.

    We can’t determine every type of attack vector, protect every system or database completely, but we can monitor for issues and be prepared to react when a problem occurs. The auditing capabilities of SQL Server have grown tremendously with the eventing enhancements to the platform, and I urge you to spend some time learning about Extended Events, which give you even more of an insight into what is happening on your server.

    Steve Jones

    The Voice of the DBA Podcasts

    We are having some technical issues with our hosting provider and are working to get the podcasts back online soon. Our apologies for the delays.

  • Should we outsource identity management

    My Database Weekly editorial for Jan 30, 2012

    One of the first things many people build when they’re developing an application these days on the web is a login/identity system for their users. This allows them to identify people, customize the features and functions, and separate out the different classes of users from each other. However many developers don’t really understand good, secure design, much less encryption, and end up “storing passwords hair kari in unsecured databases”, a quote from this piece on password security.

    I’d hope that most developers know that passwords should be stored in a digest (one-way hash) form, but that’s like assuming most developers understand the issues with SQL Injection. It’s not true, and not necessarily going to be true until, well, it’s not likely to ever be true. Even if we had minimum standards, there are plenty of developers that would ignore them and plow forward with the arrogance that their custom method is better implemented, and more secure, than any standard.

    Passwords and password security are hard. I’d hope that most people would be looking to move to passphrases instead of passwords, but I don’t see the recommendations being widely disseminated in the world. I recently rebuilt a computer, requiring my kids to implement new credentials, and my recommendation was a simple phrase they can remember with a number. I was hoping it would serve the dual purpose of instilling good security habits as well as improving their typing skills. We’ll see if it helps.

    With large rainbow tables, creative social engineering, and poor application security, it’s even more important now that we use passphrases, and even develop better identity frameworks for applications. Personally I liked the Passport system Microsoft had, and I like the OAuth system even better. Perhaps we can get more of these frameworks implemented in reference applications and frameworks, as a default way of managing identity systems.

    That’s the easy part; convincing developers they can’t manage identity better is probably the hard part and I would love to see some good ideas for that.

    Steve Jones