Tag: security

  • Data Masking for Convenience

    I was at Microsoft in Redmond recently and heard an interesting comment from a SQL Server developer. I was debating the data masking feature with a friend, and we were torn on the value of this for various situations we’d each encountered in the past. There are some restrictions, and it doesn’t seem that data masking is really offering a lot of security.

    The Microsoft developer, however, noted that this isn’t really a high security feature. It’s a developer feature. The design of data masking is to prevent that same code from being rewritten over and over by application developers. The use case is really to help with systems that might read some data, like those that print off part of an account number, ID number, credit card number, etc.

    If you read up on the restrictions, this makes sense. If you are just trying to make development more convenient, the feature makes sense. I hadn’t thought about that use case, but the more I consider this, the more I’m sure that data masking does remove a bunch of code that developers might be re-implementing themselves, perhaps with highly variable levels of quality. It also removes the chance that application developers will accidentally pull sensitive data to a client and (poorly) implement mask replacement there.

    I think this feature is being mis-marketed a bit, really to increase sales to executives and management. I’m sure there isn’t anything we can do about that, but I’d love to see technical documents and information about this for developers and DBAs. Give us a more realistic use case and give us better guidance. I think if we got that for many features, there might be more positive responses and great interest from technical professionals to the changes in the SQL Server platform.

    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.

  • Everyone is a Target

    There was a piece in Dark Reading about a security researcher being targeted by a hacking group. While this is more political, this does raise some questions about how hackers might target our systems in the future. It just might be through personalized attacks against anyone that has privileged access.

    In this case, hackers learned who researchers were and made repeated attempts to personally craft phishing attacks against specific people. However since many hackers communicate with each other, and could easily turn from political goals to economic ones, I’d be concerned about how this might affect data professionals in the future.

    We know that social engineering works. While many of our customers and clients do have access to large amount of data and are perhaps easier targets, I would still expect to see attacks against a data professional that manages lots of data. Especially if the individual might have access to high profile data, or multiple companies as a consultant.

    Targeted attacks against individuals could be a concern for many of us. We are usually more conscious of phishing and social engineering, but we’re not invulnerable. Many of us need to practice good security habits, being careful how we access privileged information, and perhaps even finding ways to do so only through containers or virtual machines that may protect us against some of the malware that could slip past us.

    Security is a pain, it’s annoying, it can slow us down, and it is hard to adhere to best practices consistently and constantly. However we need to be careful and vigilant against the regular stream of attacks that will likely continue for the foreseeable future.

    Steve Jones

    The Voice of the DBA Podcast

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

  • How Many Times Will You Change a Password?

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    If you create a login and the user can’t log in, how many times will you change the password?

    It turns out I’ll do it 5 times.

    I was setting up a new installation of DLM Dashboard on a test machine. In the setup it asks for an account to run under. I dislike setting my own account (even for tests), so I flipped over to SSMS and added a new login, entered a password, unchecked “require change” and set this as a sysadmin. I clicked OK and returned to Chrome.

    I entered the password and hit “Add”, only to get the “login failed” message for the user. Surely I mistyped something, so I typed the password again, with the same result.

    Maybe I mistyped it in SSMS. Go back, change it to the same thing, adding a character in SSMS (let’s call this the first change) and then hit enter in Chrome.

    Failure.

    Maybe I mistyped it. Go back to SSMS, change the password again (now twice), this time making it simpler. Uncheck the “policy check” and try again.

    Failure.

    Hmmm. I’m confused. Let me type a password in Notepad. I’ll copy paste that in SSMS (now 3 times) and into Chrome.

    Still a Failure.

    At this point I’m confused. Why can’t a new user log in? I’m wracking my brain.

    Maybe I have a sticky keyboard key? I’ll change the password again, this time to 5 of the same character (now 4 changes). I go slowly, typing the same 5 characters into Chrome.

    Failure.

    What’s the cause? I’m starting to wonder if perhaps logins aren’t allowed on a protocol, and it hits me. SQL Authentication.

    I go to the instance properties and I never allowed SQL Authentication when I installed SQL Server. After all, this is a test machine.

    Change that and restart SQL Server. Change the password again (5 times) to a decent password that won’t be guessed if someone gets to this machine.

    DLM Dashboard setup proceeds.

    SQLNewBlogger

    We all make mistakes. We do things wrong. Talk about how you learn and figure things out. This is a good story and lesson for me.

    Resources

    I should know better.

  • The Security Payoff

    I wrote a few months ago about United offering rewards for people that discovered security issues in the United Airlines software. Not the plane software, thankfully, but in their customer facing IT systems. Apparently a few people discovered flaws and were recently awarded frequent flyer miles, a couple of which received 1 million miles. That’s a nice bonus for some people, though I hope the end result of this is that United builds better security into their software and learns to code better. Certainly other manufacturers have programs that have helped in the tech world. Microsoft, Google, and others have programs that pay bounties for flaws that are discovered and reported.

    However I wonder if this isn’t something that should become an accepted practice. I don’t necessarily want regulation here, though I would prefer our regulation not prevent the research and exploration of security issues. Imagine, however, if we had an accepted, known process for finding flaws in all software. Maybe this would be like a standard process, like reporting spam to the webmaster@ address for websites. If someone finds an issue, they let the company know. The company has a bounty of some sort, perhaps a token reward, and a limited time to fix the issue. One the time passes, the individual is free to disclose the issue to the public, the problem can be publicly discussed and analyzed. More importantly, the company now has liability for any data loss or productivity issues.

    In theory this should already exist. However it doesn’t seem to regularly work, and we have lots of software with flaws, along with no incentive to fix the issues, even when data is exposed. There are some laws for personally identifiable information (PII), but what about random data that might be annoying to users? What about the various software packages that we use that monitor our systems or provide anti-virus protection or manage other aspects of business. I’d like to see perhaps more class action arbitration (not lawsuits, we need less lawyers involved in the world) that perhaps doesn’t award damages, but refunds purchase costs. If that CMS doesn’t work, your money is refunded. I’d think that would incentivize some secure coding practices. If vendors had to make insurance claims, I bet we’d start to see more requirements of code reviews and PEN testing of software in general.

    This is certainly a hard issue to discuss. For every solution out there, plenty of edge cases or exceptions will be an issue. The openness and ease with which people can create software is a double edged sword. This encourages innovation and experimentation, resulting in some amazing new concepts, but that same freedom often also brings about lots of poorly written software, full of vulnerabilities and bugs. I hope that we find a way to mature this industry and start to build better, standard, well engineered practices and habits that encourage secure, robust, well written code.

    Steve Jones

     

    The Voice of the DBA Podcast

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