Voice of the DBA

Tag: security

  • The $50,000 Laptop

    Hopefully you won't lose this amount of data.
    Hopefully you won’t lose this amount of data.

    I wrote a long time ago about the value of the data on a laptop being worth more than the hardware. That’s certainly true for me, and I very much worry more about losing the data on my devices than the any of the devices themselves. I use sync services to keep a backup of most things, but I still worry about losing any of my bits.

    There was a large study competed recently, called The Billion Dollar Lost Laptop Program, which examined 329 organizations. The idea was to find out the economic costs of lost laptops related to various public and private entities. The conclusion? The average value of a lost laptop, just one laptop, is $49,000. The conclusions say that least expensive part of losing a laptop of replacing the hardware.

    As we would expect, most losses occurred away from the office, however it’s not known how many of these losses might be targeted thefts. Many of the losses did occur through theft, which is disturbing when most of these disks did not have encryption in place. This was true even when confidential data was contained on the laptop.  It is nice to see that companies that realize they were targets of theft, as opposed to losses, typically do use encryption.

    As the study shows, there are a lot of costs that go into replacing a laptop. Many people don’t think of all of these costs, and even if the costs are double what they should be, these are still substantial costs for companies to absorb. The costs will only go up in the future, especially as more and more people move from desktop workstations to laptops.

    The one positive note? Encrypting the laptop almost cuts the loss in half. A good reason to require encryption on all laptops.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Hacked

    Getting hacked is never fun, and it can happen in so many ways.
    Getting hacked is never fun, and it can happen in so many ways.

    I’ve been hacked before. My personal web site has been hacked with a variety of injection and XSS attacks over the years. None too serious, and I’ve had backups that allowed me to fix things fairly easily, especially once I had a copy of Data Compare, which saved me a lot of time. At SQLServerCentral, we’ve been hacked as well, though not in a long time. I think we’ve closed most of the security holes, and I haven’t had any issues to deal with in quite some time.

    However as I was reading a note from Richard Douglas about being hacked, it brought back memories of working at JD Edwards. Richard was hacked at work, on his personal system. At JD Edwards, we were required to lock our workstations at all times when we were not physically in front of them. We also had two accounts: a normal user and a domain admin “privileged” user. As you might expect, there were numerous lapses of people walking to the kitchen or bathroom and forgetting to lock their workstations. It was considered fair game to change settings, send email to our group, even place semi-SFW pictures on someone’s desktop. It was quite embarrassing to be caught, and was much more a an effective security reminder than a reprimand from our boss.

    However there is a serious security problem here. Many of us would use our privileged account all too often, since it was a hassle to log out and back in. The “run as” option didn’t work well for some applications, and we were less secure than we probably should have been. If someone walking by, whether an employee, guest, consultant, or someone else noticed SSMS running, how long would it take them to type:

      sp_addlogin 'joeuser', 'joeuser'
  sp_addrole 'joeuser', sysadmin

    I type quickly and that took me less than 30 seconds. I’m sure even a slow typist could get that entered, and erased, inside of a minute. That might result in a serious security breech, if the system to which you were connected contained HIPAA, PCI, or any identity information. Perhaps even worse these days is the chance someone might attach a USB key logger to your keyboard.

    You might be safe in your environment, but you can never be sure. A little care in ensuring you are not unnecessarily exposing security holes, and making sure that outsiders are always escorted can prevent embarrassing incidents from occurring.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • The Principle of Least Privilege

    One of the tenets of good security is that no person or process is granted more rights than it needs to accomplish a task. This is the Principle of Least Privilege, and is designed to ensure that your system is as secure, stable, and predictable as possible.

    For a SQL Server instance, this means that unless a person or process needs to perform instance level changes (configuration, patching, etc.), then they should not have instance level privileges. If a process accesses data in a database, there is no need to grant sysadmin privileges, even if they do need db_owner privileges.

    Many software packages require sysadmin access be granted, often without any justification. Developers build software as a sysadmin on their own workstation, or on a development server. They often don’t understand or realize that less privileges will still allow their software to work. As a result we find software running under elevated privileges, which can be a security risk if there are bugs or injection holes in the software.

    It’s hard to make changes later on, and it can be frustrating to argue with vendors that their software doesn’t need elevated privileges. The best way to combat this is to educate yourself and any developers you know about security.

    Adding login or user accounts does not require sa privileges. The securityadmin and db_securityadmin roles can be used. The rights to create objects in a database can be handled with granular permissions in a schema, or with the db_ddladmin role instead of db_owner.

    Work with limited rights when you can, and help other learn how to work with the minimum they need and we’ll all be more secure.

  • Cloud Concerns

    cloud concerns
    The biggest concern with cloud computing isn’t security.

    When I get feedback about cloud computing from DBAs, the main concern seems to be data security, or the perception of problems with security from a cloud provider. That’s natural as sending your data to the cloud doesn’t necessarily remove the responsibility for security from the purview of the DBA, yet you don’t have complete control over the way the data is managed. Various providers are working on their security and passing certifications, though this doesn’t necessarily make many DBAs feel comfortable with databases in the cloud.

    However security may not be your number one concern. Outages and business continuity should be your primary concern. As noted in this article, cloud service outages have been more common than lost data. It’s much more likely that the service will go down, and if it does, what do you do? Contacting a cloud services company, and receiving fast answers aren’t likely when a cloud outage usually affects a large number of customers.

    However business continuity is important. If your database, or application server goes down, what would you do? In most cases you would sit in your office waiting for the cloud provider to come back online. That’s not much different from in-house failures where you may wait on the network or OS administrators to recover a host server. In a few of the disasters I’ve experienced, I only had slightly more control than I’d guess a cloud provider gives me.

    In either case, having good backups and a strategy to bring your system online in the event of an extended outage is important. I suspect that will mean hybrid public/private cloud applications that can function from an alternative location will need to be an architectural requirement for many businesses.

    Steve Jones

    The Voice of the DBA Podcasts

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