Tag: security

  • MY Data

    Data is merely a set of numbers. However when data is given context, it allows conclusions to be drawn and many of us make a living managing some part of that process every day. Most of us deal with data that is viewed as somewhat public, related to our interactions with businesses and organizations. However we see some of this changing as employers start to gather more data on us through social media and other sources, beginning to use that data to make hiring decisions.

    It can get worse. As Shane Battier says in this article says, “big data is scary.”

    Most of us don’t aren’t hired for our physical performance. While our health can make a difference in how well we write code over time, the regular, subtle decisions of drinking juice or soda don’t affect our performance much on a daily basis. We could argue about that, but from the employer’s perspective, I’m not sure those things matter.

    Or do they? If the cost of employees rises over time, especially with regard to health care or sick time, should employers start to make decisions based on the data? Are we confident in the conclusions from data, which are really probabilities, not actualities? Would you want aspects of your life, perhaps outside of your health (think driving, finance, etc) to be part of the evaluation (or negotiation) process for your employment?

    Perhaps a lighter question, would you be comfortable managing and writing applications that work with employee data and try to analyze, perhaps even strongly recommend, changes in peoples’ live? I’m not sure I would, and I certainly hope we don’t get to the point where the data about our personal lives directly impacts the way we are managed.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • It’s Not Just Poor Coding

    We hear regularly about SQL injection continuing to be a problem (it is) and malware causing data loss for many companies. We’ve got misconfigured firewalls and backup tapes being lost. However even if we could solve all those issues, we’d still have security issues.

    A new study shows that many workers share a tremendous number of files with coworkers, and potentially friends on a regular basis through the various cloud services. I don’t worry so much about cloud service providers being hacked themselves, or their employees selling information. It could happen, and probably does, but it’s also likely just isolated incidents that have limited impact. However I’m more worried about the poor security practices of the employees.

    Many people tend to use the same passwords on different sites (a bad practice). They also often open attachments from “friends”, unaware of how dangerous it can be to pass along and share documents that can embed malware. Malicious coders are becoming smarter, learning to make their actions more subtle, often only infecting a device to use it to send emails or files to other users who are the real target of the malware. With all of these issues, it’s much more likely that a user will end up creating their own hack for malicious servers than targeted attacks will work. It’s also highly possible that many users will share documents with friends, unaware that they might be exposing corporate data to the general public with confusing settings in some of these services.

    Ultimately I’m becoming more cautious about sharing information with others. I won’t open many files sent to me by people I don’t know well, and never look at any “humorous” attachments. I won’t accept a USB key from you and plug it into my laptop. It’s sad because we’ve built some amazing services to allow us to communicate easier and faster than ever before, however we’ve also not built these applications with an eye towards security first, and convenience second.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Have You Been Hacked?

    I am glad that I don’t work in the retail industry as a DBA. It seems that I read about a new security breach every few weeks from some company. Home Depot, Target, Staples, the list goes on and on, and includes more and more businesses that at least some of us use regularly. It’s gotten to the point where I expect that I’ll need to replace at least one of my cards every year because of some data loss issue.

    However it’s not just retail companies that are getting attacked. According to the Q3 Dambella report, companies are having dozens of devices infected daily and seeing increasing numbers of point-of-sale (POS) attacks all the time. Even those companies that don’t deal directly with credit cards and consumers are finding that they are targets of network attacks more and more. Some of these are merely vandalism, but many are intended as some sort of industrial espionage or data breach that can be used for profit.

    This is the other edge of the data professional’s sword. We have low unemployment and high salaries, but we are also becoming responsible and the target of blame when data is stolen. I really believe that theft detection is becoming more important for data professionals. We won’t be able to prevent attacks, but we surely need to know when they have occurred and be prepared to respond.

    I don’t know how our profession will move forward in the future to meet these needs. Perhaps we’ll become bonded like locksmiths. Perhaps we’ll be bound by insurance requirements to adhere to best practices. I’m not sure any of that will help increase security, but it might help reduce the liability that we may face.

    Steve Jones

    The Voice of the DBA Podcast

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

  • T-SQL Tuesday #58–Passwords

    It’s the second Tuesday of the month, time for T-SQL Tuesday again. This time the invitation to participate comes from Sebastian Meine (@sqlity, blog) with the topic of passwords. It’s a great topic, especially as security concerns are growing regularly.

    I would encourage anyone that looks to build their brand, and further their career to write a post for T-SQL Tuesday. It’s easy, just look for the invitation and then publish on the second Tuesday of the month.  Be sure to follow the #tsql2sday tag on Twitter.

    You can even go back and write about previous topics, and share your own thoughts and insight. I keep a list of previous topics here: T-SQL Tuesday Topics.

    SysAdmin Passwords

    I’ve tried to maintain strong passwords for years. I used to have a formula, similar to Bruce Schneier, where I’d use a sentence to build a password. However a few years back I went to Password Safe, and have been using that on Windows, OSX, iOS, and Android, with Dropbox keeping my password safes in sync. I let Pasword Safe generate my passwords, 12 characters), with random digits and I use this to stick passwords into systems.

    I use a different password for every system, which has been fine for me. It’s slightly annoying to unlock the safes on a mobile device, but I like the idea that a compromised password on one system doesn’t affect any others.

    Years ago, I worked as a DBA and we managed a large number of systems. One of our mandates was that administrative passwords would be changed every 30 days. That was fine for the people running the systems, but changing the administrator password for hundreds of Windows hosts was an issue. We grouped servers (IIS servers, Exchange servers, etc), to make it easier for each administrator to manage the systems, but it was still a challenge to create passwords for each group every 30 days.

    I introduced Password Safe, and simplified things. We let the application generate passwords for each group, stored them in the safe, and used a script that took the group and password as parameters to change all the systems passwords. This was still time consuming, but it provided for a limited window to crack a password, allowed us to use longer passwords, and we could also retrieve them when we needed to administer a particular system.

    Note that this was just for administrator passwords. We had a separate scheme for service accounts, which was to randomly create a long, 15+ character, password that was used to start the service, but was never stored. Similar to many applications, we couldn’t recover the service account passwords. If we needed one, we changed it, and sent a note to the security group whose event log scanners would note the change.

    I know that strong passwords don’t necessarily solve our security issues with hackers and social engineering, but I do think this is the lowest bar you can tolerate. If “sa” and blank, or “sa” and “password”, or “system” and “manager” (for the Oracle folks) work on your database, you deserve to be fired. There’s no excuse for not picking a strong password for privileged accounts.