Voice of the DBA

Tag: security

  • The Secret Password

    As I work with more server systems that help developers run Continuous Integration and automated releases, one of the things I see used often are variables. These are values you can set for a particular process and reference inside of that process. Great for setting server names, paths, etc. In releases, these are great for specifying specific values that change for each environment, such as the instance name or IP address.

    As with many developer based systems, security is not always set tightly on these systems and any developer can access the build server to kick off builds, reconfigure a process, etc. That makes sense in a CI process, but not so much in a release system. This is one reason I do recommend a separate release server from the CI server. You can use Jenkins or TeamCity to perform releases, but is it a good idea? Have you thought through the security?

    In the release servers, one thing that most systems allow the admin to do is use a variable for a password and mark it secret, so the value cannot be recovered. In this way, if some developer is working on the release process, they can’t get the password to the production server. They can only click the buttons that deploy to that server.

    However.

    They can deploy to that server, and they don’t need the password. If I were to execute a script in the release system that executes the “CREATE USER” and a “ALTER ROLE ” commands to give me access to data, does it matter if I know the deployment password is “G4da%$2h#5f” or $(ProdPwd)? It doesn’t. The actual value isn’t relevant; I just need to be able to use it.

    I think release systems are great pieces of software for reducing the risk of your deployments, but I do think the security models need to be carefully designed and easy to configure, especially when it comes to allowing arbitrary code to be submitted and executed by one person. Be sure that developers can’t necessarily deploy code directly to production servers, whether the password is hidden or not. If there is a way to use the value, someone will find it.

    Steve Jones

     

  • The Value of Your Personal Data

    Years ago I read Being Digital by Nicholas Negroponte of MIT. In the book, he relates a story about crossing the border from the US into Canada and a Border Patrol agent asking the value of his laptop. He said millions, not because of the hardware, but because of the data. I thought that was interesting, and I somewhat agree. The data I have on my machines, or really now, in cloud services, is more valuable than the hardware. The hardware is barely worth anything to me, including the time it takes to reinstall my applications, because I really treat my laptop as a piece of cattle. I could drop it, render it completely unusable and I’d be back up, running, and productive with new hardware in less than 4 hours.

    Then I saw this article on ransoming data for iCloud users, where the request is for US$75,000. This is for Apple itself and not individuals, but what if it were for each user? What would I pay to avoid losing all the data on my mobile device?

    It certainly wouldn’t be $75,000 despite the fact I think some of the data I have is precious. I love the pictures and video of my family most of all, but if I lost some of them, maybe all of the digital storage, would I just pay a ransom? Probably not. What about all the code in a VCS for my company? Would we pay a ransom for that? Likely we would, though perhaps not. We might think about reconstructing the code, especially if we were a small company.

    Ultimately I think there isn’t a lot of money to be made with individuals’ data. Too many of us older folks remember when we did lose physical objects and they were just gone. The idea of losing things is painful, but not inconceivable. For younger people, it seems that much of the data we produce and consume is transient and isn’t necessarily that valuable to us. My kids love Snapchat for the ability to create and lose memories. I dislike it for the same reason.

    Much of the data we personally have can be backed up, and possibly recreated if it isn’t. Many of our digital records have the characteristic that while we may have a copy, often some business or organization has another copy. Requesting new data is easy, and while it might cost some time and money, it may be preferable to the idea of paying a ransom, and potentially having to continue to pay again in the future with some virus still on our systems.

    I don’t quite know what to think about ransomware and how this might evolve. I suspect that this will always be a problem in some way, just as hardware failures will likely plague us forever. The only solution I have is to create backups regularly that contain versions, and can be restored to separate, clean devices. I’ve gotten away from my own personal offline backups, mostly because of data size, but I do continue to try and keep at least 2 or 3 backups going to different locations and with different services because my data is at least that important.

    Steve Jones

  • Hacked

    Hacked

    By Steve Jones, 2013/01/02

    This editorial was originally published on Jan 2, 2013. It is being rerun as Steve is out of the office.

    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.

  • I Hate To Send This Email

    I use TrueDelta to report my car status every month. It’s a nice service, allowing car owners to see what experiences others have, and think about which models and years might be a good fit for me. I’ve tracked multiple cars with their service for the last 3-4 years, with reminders from them every quarter to update any repairs I’ve made.

    Recently I got an email from them with this opening: ” We hoped never to have to send this email. A few days ago we learned that TrueDelta has joined the increasingly long list of organizations whose server security has been breached by hackers.” The email went on to note that names and passwords to taken, and that everyone needed to perform a password reset. I applaud them for including “Security breached” in the subject as well as immediately changing everyone’s passwords so old ones wouldn’t work.

    I’ve been hacked at SQLServerCentral, though to our knowledge no data was stolen, merely vandalized. We haven’t ever been able to track suspected data breaches back to SSC, and I hope we never do, but I’m not naive to think that we never will. I hope we don’t, but hackers make determined efforts to gain access to data. At least we are aware of security measures, have a small staff with administrative access, and try to not allow any simple attack vectors.

    Not every company does a great job at securing their data, especially from phishing attacks. There’s a spectrum of how carefully data is protected by organizations, and as we’ve seen from haveibeenpwned.com and plenty of media reports, more and more companies lose data all the time. Some of those companies notify customers (some have to), and I would guess more than a few people have had to send out emails they never expected to send. More of us will dsend those emails in the future, and we should think about that today. Is there something we can do to avoid having to send those notifications?

    There probably isn’t something to ensure it never happens, but we can certainly work towards improving our security. As developers, we shouldn’t have short limits or character choices for passwords. If you wonder why, there’s a great answer at security.stackexchange. We shouldn’t be writing our own authentication schemes, but incorporating code that’s been written, vetted, and reviewed. And make sure we apply patches. Most of the security holes in software are known and patched, but without being deployed. Certainly if new patches become available, we should be able to incorporate them quickly. Above all, learn what SQL Injection is and don’t allow unvetted user input in queries, including those in hidden form fields.

    Steve Jones

    The Voice of the DBA Podcast

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