Voice of the DBA

Tag: security

  • More Regulation Coming?

    This editorial was originally published on Jun 22, 2011. It is being re-run as Steve is out of town.

    Recently Citibank had hackers access a large number of credit card numbers and account details for their customers. It was all over the news, but there was a great piece in the New York Times (registration required) about how this seems to be a nagging problem. We’ve had data breaches before, and banks have had security issues, but they don’t seem to be learning. A number of government officials in the article are quoted as seeking new regulations for data security.

    As data professionals, we are often charged with ensuring data is safe, yet accessible to authorized individuals. That responsibility can be hard to manage, especially when our management often doesn’t want to increase our budgets, or accept more restrictive ways of authenticating users or even slower access. I certainly don’t envy the IT folks working at banks and healthcare companies, and am not sure I’d even want to take a job in those industries in the future.

    I don’t think that more regulation is necessarily the answer, at least not direct regulation. Technology changes so quickly, systems are implemented in diverse ways, and direct regulation often leads to rules that exist to help some vendor profit, not provide better security.

    Whether we get new regulation or not, I think that most of us need to learn more about what security methods work well in our systems, the implications of picking a specific type of encryption, and in which ways we can be audit our systems to detect issues. In the days of limited budgets and apathy from management, a little education is the best way to improve the security of your systems.

    Steve Jones

  • Architecture for Auditing

    In the analog world, when we need to provide an auditing system for checking on physical activity, we usually separate out the roles of people that might record or track activity from those that perform activities. The better separation we have between individuals, the better we can usually ensure our auditing records are intact, complete, and trustworthy. We certainly have issues in the real world achieving these goals, but overall things work well.

    In our digital systems, however, auditing seems to be bolted on to the systems and not designed with the need to separate duties and protect our auditing records from tampering. I would have hoped that many of the software platforms (Oses, RDBMSs, etc) over the years would have recognized this (along with security) and enabled auditing as a function separate from Administrator/root/sa/etc, but it hasn’t happened. Far too often, we’ve operated under the assumption that administrators can, and should, be trusted.

    In SQL Server, most all of the auditing mechanisms are enabled, managed, and reviewed by administrators. While viewing is certainly helpful, and perhaps necessary, for good administration, there ought to be a way to enable auditing that doesn’t require DBAs to manage it. There ought to be some role for auditors, one that allows an independent individual (or group), to access the record of actions taken on the instance.

    Perhaps it’s not as big a concern for the world as I think it is. In most cases, auditing data exists to help solve problems, not to ensure a legal record of activity for sensitive actions. If that’s the case, then SQL Server provides lots of choices and options for the auditing of your system. Extended Events, SQL Audit, and more are valuable tools for the DBA. I’m just not sure their value extends beyond being useful tools.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Security Through Chaos

    This editorial was originally published on June 16, 2005. It is being re-run as Steve is away at training.

    I can’t really disclose who told me this, or at which company, but I found it very interesting. Recently there was a worm that rolled through a large number of Windows systems on the Internet. A few friends told me about it since it had rippled fairly quickly through their companies. These were all large organizations, with over 2,000 people employed in each of them. However, one company had almost no infections. The spread between their internal systems was almost non-existant.

    Now I’m sure that you are all wondering what great technique they used so you can deploy it in your environment. I was as well, until I heard the details. I dismissed it at first, but then thought it did make some sense. I’m not sure I’d recommend the technique, but it was interesting.

    Their defense was chaos. They don’t really have a central IT organization, standards are almost non-existent, no central AD setup, not even a standard platform. They do make anti-virus, firewalls, etc. available, but it is up to individual departments, people, and labs/data center areas to deploy them as they see fit. Need a resource from another group? Better start making friends. Want to breach a firewall? I’d recommend buying a Starbucks card or a 6 pack of Red Bull for the admin of that firewall.

    Now this is a technology company and most of the employees are fairly smart technologists. They are each responsible for the most part for their systems. If they break it, they need to fix it or find someone to help because a broken computer is not an excuse for work not being complete. But an individual can have a Mac, PC, Sparc, run Windows, Linux, whatever, as long they get their job done.

    Samba is in use as a file system in many places, but permissions control is distributed. Sarbanes-Oxley, secuirty, auditing, etc. all still apply, but there is no central group that ensures it’s performed in a consistent manner.

    As I mentioned, at first I was shocked. I thought this was ridiculous. But the more I thought about it, the more I realized that it made some sense. You couldn’t easily break into their network because what worked in one place wouldn’t necessarily work in another. Compromise one password and you might not get very far at all, even if you had an administrator password.

    I’m still not completely sure what to think of this, but apparently it works. Probably just like my life with three kids and a wife that works hard. You juggle all the balls and hope none of them drops.

    Steve Jones

  • The Opportunistic Hacker

    You’re sitting in Starbucks, working. You need to use the restroom and you ask the hip, cool looking person sitting coding next to you, with whom you’ve chatted with for the last hour about C# and SQL, to watch your laptop. You leave and come back to an empty table.

    This was a hacker, coding away at their side job to pay a bills in between causing mayhem. They walked away with your laptop, not knowing if you work for a bank or a soy milk manufacturer. The hacker won’t know if you have a copy of the production database on your laptop or simple a few .ASPX files that are useless without a VPN connection to your office. Hopefully that can’t access other machines from yours.

    This is a crime of opportunity, and it happens regularly. Criminals steal laptops from coffee shops, airports, cars, and more. Often just because they can. Some may just wipe the device and sell it, but others may spend some time poking around to see if there is any value in the data on the machine. Or on a connected machine.

    Many of us have far too much data on our machines, with many, many saved passwords and connections. We have copies of code, databases, or backups, and losing our machine to a random criminal might be just as damaging to our organization as losing it to a hacker that targets us.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.9MB) podcast or subscribe to the feed at iTunes and LibSyn.