Tag: security

  • The Danger of Algorithms

    There is a report that came out recently that shows how you can predict Social  Security numbers, an important piece of identity information in the US. This, according to this C|Net article, could result in massive fraud taking place if someone’s birthday is disclosed.

    So many sites want to get this piece of information from you, often to ping you on your birthday or give you some gift. I’ve always been wary, however, and usually put in April 1 instead of my real birthday. It makes for lots of birthday wishes on that day, but that’s OK. I appreciate the thoughts, even if they are a few months off.

    This does highlight the danger of using an algorithm to generate data. Unfortunately there are plenty of people out there that will maliciously find ways to mis-use data, and if they can guess how you generated the data, they can extrapolate that out to calculate what other data might exist in your system. I know most people that need to generate codes often don’t spend a lot of time ensuring they’ve picked a good method from a security point of view.

    The key here is to keep pieces of information somehow separate, to make it more difficult for a criminal of some sort to perform the extrapolation. That gets harder and harder to do, primarily because of the job many of us do. We gather data into SQL Server and other platforms, and make it easy to put this data together.

    As with many of the problems I see in today’s world, I don’t have a perfect solution to this problem. However I think that many of us handle data insecurely, often comparing actual values when a hash, or digital signature might work instead. I know some of that is because we don’t have great tools for working with digital signatures, but also because it’s a complex process.

    Credit card companies, banks, and other institutions often have complex rules for how they handle and process data. I think this more of their secure methods of handling data should be published and taught so that other companies can better learn how to build more secure applications.

    Steve Jones

  • Good Practices for Software Development

    Would you post your password on a wall in your office? Of course not, because other employees, the cleaning crew, even guests walking around your office would be able to access your system with your account. When I read Brian Kelly’s post on passwords in files, that’s what I thought of. Sticking credentials in a file, where they’re subject to any kind of search, is a bad idea.

    However this happens all the time. Combine this with a few other “common practices” like using sa to connect to a database and building dynamic SQL, and you might as well just set blank passwords and invite someone to have fun with your database. It’s sad that we continue to see these types of software development practices in 2014, and especially poor to see them from companies that sell software.

    There is so much information out there on building software that is of higher quality and is much more secure. However all too often I find developers just aren’t implementing these practices. There are probably a myriad of reasons why, and I wish we had more ways to better train people, disseminate the information, and enforce it’s use.

    Ultimately we can only do what we can. However I’d encourage those of you that see poor practices taking place to have a word with the developer (internally), or send a note to the vendor. If it’s more important to make a few more dollars than implement better practices, I’d encourage you to publicly call some attention to the matter. Maybe a little exposure to the dark side of software development will pressure managers to require more secure work over time.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • If or When?

    I saw this post recently about security and preparing for a data breach. The title caught my eye because it implies that we’re all doomed. Do the rest of you think that? Is it a question of when we’ll have a security breach not if?

    Given the headlines, the news we find out about companies not disclosing security issues, the back doors and poor code in much software, is it any wonder that people think it’s a “when” and not an “if”? Given the lack of realization from many companies that suffer incidents that they were even attacked, perhaps that’s an assumption worth making.

    We’ve been hacked at SQLServerCentral in the past. I don’t think we’ve been hacked in many years, but I also have no way of knowing. That’s the difficult part of dealing with bits. If they get copied, there’s not necessarily a trace of anything amiss. It’s quite possible that many of us have no idea that our bits are being copied. Every read is a copy of data and how long did the NSA read data without most of us being aware? How sure are we that they, or some other organization, hasn’t been reading much more than was disclosed?

    I’d hate to think that our systems are so porous that we’re all likely to get hacked at some point. It’s probably technically possible, but hopefully not likely for most of us. However we should consider that it will happen and ensure we have some handle on our data security. It’s hard, and complex for most of us, and I’d like to think that Microsoft will recognize this and build better controls and features into future versions of Windows and SQL Server that enable easier auditing, granular permissions, and separation of duties.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Data Security Policies

    Does your organization have some policy around data security on mobile devices? Do your fellow employees care about data security? A new study says that most organizations don’t, and potentially that’s an issue.

    Many of us are data professionals, and we might have no idea how much data a user can access using today’s modern mobile devices. Potentially we can help them understand that the $500 smartphone they use can actually contain and access much more than $500 worth of data. If their device is the cause of a data breach, the cost could easily be much closer to $50,000 than $500.

    Security is always a big gamble, and rather than the old models of controlling all devices and limiting access, we need to learn to educate users, work with them to secure their devices and report losses quickly. The survey shows that most employees don’t even know how to report the loss of a device that might cause a data breach. At the very least, we can establish some procedures that will allow an account to be quickly turned off. And to ensure productivity doesn’t suffer, we need a procedure that also engages a new account for a user quickly.

    My guess is a lot of security issues could be handled quicker if we ensured that users were aware of issues and penalized for ignoring them, but made sure those penalties were balanced with an understanding that there it is inevitable people will make mistakes and accidents. Forgive mistakes and ask for reports of potential issues quickly.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.