The Biggest Data Breech (For Now)

I keep reading the words “the largest data breach in history” in a variety of stories. In fact, given the tremendous growth of data acquisition, I’m guessing that this headline will continue to repeat itself over and over. I think I’m getting to the point where I’d rather just see a story say that xxx million customers were affected. At least then I’d be able to easily put some scale to the loss of data.

What’s interesting in this case involving JP Morgan is there are indictments being handed down, to at least two men that somehow participated in hacks that copied over 100million people’s data. JPMorgan admits 76 million households and 7 million small businesses were compromised, which isn’t 100, but perhaps there’s something I’m missing. However the data wasn’t just sold, but rather hackers used the information to market stocks to the individuals compromised. That’s an interesting level of sophistication, and a scary one.

Can you start to imagine criminals using the information intelligently to not directly sell the data but to make a secondary use of the information. Perhaps they will enagage social engineering by bundling the information with other data to perform some other attack on individuals? It’s entirely possible that we will see more sophisticated uses in the future as criminals work to evade or avoid the fraud detection systems that have been put in place.

I have no doubt that bigger data breaches are coming. Perhaps we could reduce the impact and frequency with better security frameworks and development practices, but I’m not sure that any company out there will place a high priority on security over ease of access and speed of development. I do continue to hope that market forces will drive companies to build better detection and protection mechanisms, and our vendors will build better security mechanisms into all platforms.

Steve Jones

The Voice of the DBA Podcast

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

Private Data

I think that as we evolve into a more digital world, we really need to modify and enhance the various legal systems around the world to cope with the challenges of digital information. The world changes when vast troves of information can be gathered, indexed, easily maintained, queried, and copied without anyone being aware, or few people understanding how any particular data is used. Data fundamentally is different in the digital world precisely because the costs and barriers to its movement are so low.

I’ve been concerned with this for a few reasons. One is that I like my personal privacy and would like to ensure that data collected about me and my family is something I have some say in. Or at least some understanding. However as a data professional, I also have concerns about the responsibilities and potentials liabilities of managing data in the future. There’s also the not-so-little concern about employers pressuring employees to deal with data in a way that might conflict with their personal ethics, or even the local laws.

I’m glad someone at Microsoft is taking a stance, asking the US and EU to recognize the privacy of digital data as a right we have as individuals and corporations. The request asks that governments treat digital data like they treat analog data, serving subpoenas and warrants to the owners of the data, not the custodians. While this isn’t what always happens in the real world, we certainly should have more protections for digital data than we have now.

I’d like to see governments amend their laws to also exclude IT workers from liability in working with data that they are custodians of. We often don’t make the decisions about what data to gather or how it should be managed and moved. We just implement the decisions, often under coercion from our employers. Liability should rest with those employers, not those the employers have hired.

I don’t have hope that things will change anytime soon, but I hold out hope they will at some point.

Steve Jones

The Voice of the DBA Podcast

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

Rogue Software Changes

Could a group of software developers make changes that fundamentally alter the way a software system should work without management being aware?

That’s the question being asked of VW right now. Most people are skeptical, but I ran across a piece that wants to lend credence to the idea that a few software engineers acted with few people being aware. They did this, not because they wanted to defraud everyone, but they wanted a solve a problem that they couldn’t do in other ways. They also didn’t see the alteration of test results as much of an issue because they thought the tests were too stringent.

I’m not sure I believe that’s what happened. Certainly there is some disagreement from various parties, but with my experience in software projects, management always wants to know how things are proceeding, with more and more questions whenever the applications don’t work as expected. When problems are solved, natural human curiosity leads more managers to ask for details, even when they don’t understand. In this case, I can’t imagine lots of VW management weren’t aware that software was being used to pass tests. Many people report to many others, and everyone would have wanted to know how VW solved this engineering problem.

The stakes for organizations will continue to rise in a global economy, and software will play increasing roles in many companies. Will we see more and more pressure to manipulate our world with software, even in criminal ways? I suspect so, and I sympathize with those that might face the loss of employment for not complying with the requirements they’re given.

Ultimately I think transparency of software is the best way to bring about better software that complies with regulations and rules. Transparency also ensures that copyrights aren’t violated (since violators code is available), and we can determine if security is being built into systems. Perhaps best of all, developers can all learn from each other, seeing exactly what works and doesn’t in each system.

I doubt we’ll get there, but transparency would be a nice place to be.

Steve Jones

The Voice of the DBA Podcast

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

The Lost Laptop Crisis

I wrote about the dangers of travel awhile back, where I had concerns about information when crossing the borders of a country. However that’s a case that most of us encounter rarely. However many of us do move information around on a regular basis with our devices, carrying them wherever we go. Each time we change locations, there’s a chance we’ll forget a device, or that one might be stolen from us.

There is a limited amount of information in our phones and tablets, but in many laptops, we can carry more information, and often do. No shortage of us keep database backups or imports/exports of data for development purposes. Our clients certainly have reports or data in Excel, but often that’s a limited amount of data compared to what some of us might keep on our machines. In thinking about this, I wanted to ask this question:

What would you do if you lost your laptop?

I’m talking about the main laptop that you use for work. What’s on it? What’s important? How would you react? Have you even thought about it?

I have, and I’ve had laptops die, though never stolen. However I have taken some precautions. When I get a new laptop, the first thing I do is enable the whole disk encryption in Windows or OSX. I keep backups of the recovery codes at home and I make sure I’ve taken advantage of strong passwords and other encryption for information I carry. I don’t have passwords saved for any VPN or other secure connections to banks or work.

It’s not a perfect solution, but it’s a start. Let me know today if you take other precautions.

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.

Secret Software Security

This might not be the best title, but I like the alliteration for a the problems we have when governments seek to prevent security researchers from releasing information about software vulnerabilities. This is nothing new, as vendors have tried to prevent this for years, arguing that criminals will exploit the information and target users before a patch can be built. The other side of the argument is that many software companies don’t bother building patches if the issues are kept secret.

What might be different in this case is that we aren’t talking about database software, devices, or banking websites. Certainly those systems may need secure software, but here we have the US Department of Transportation arguing that security details about automobile software shouldn’t be released. There is some leeway in that potentially limiting details might satisfy the government, but apart from that, how do you feel?

Many of us use vehicles every day. We might use private cars, but we might use public buses, trains, and airplanes, all of which are making more and more use of software over time. I don’t know, but I suspect, that much of this software is being developed with an eye towards ensuring it works as intended much more than with a view towards how malicious users might take advantage of vulnerabilities. Far too often it seems that we have new systems where control data is allowed to transit the same networks and computing structures as less secure data, with minimal security across the entire system.

I certainly think that some researchers might not appreciate the dangers of random people experimenting with the issues they disclose, but I also truly believe that the pressures of getting software released overwhelm the concerns and dangers that exist overall. There are no shortage of people with time to spare, abundant computing resources, and substantial intelligence devoted to finding flaws in software. They work at “hacking” the system to change behaviors. While it’s a game to many, there are very real consequences to the world if strong security isn’t built into vehicle software.

I don’t know that I expect much to change, but I suspect that we will see more and more issues over time, more lawsuits and more highly technical and forensic analysis performed when we a system is attacked. I can only hope that we actually disclose poor security practices so that vendors do learn that their embedded systems need better, and more secure, software engineering practices implemented.

Steve Jones

The Voice of the DBA Podcast

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

Masking Data

This editorial was originally published on Mar 7, 2008. It is being re-run as Steve is out of town.

I saw an interesting thread awhile back where one of our very talented community members was asking about how to go about altering data in an application for a demo. It’s a valid scenario and one that I’m sure many people have run into at some point in their career. You want to show data that’s somewhat real so that it showcases the application and what it can do, but you don’t want to show real names, amounts, or any identifying information.

A bit of a quandary and it seems that many people solve it in one of three ways. They just use test data, which is a very small set of data and doesn’t show as well. Or they may alter everyone’s name to something like “Steve Jones”, all phone numbers to 555-555-5555, etc., which looks funny.

Or you just show the production data and wink and say “I don’t usually do this, but since you’re such a valued client…”

So for the Friday poll: Do You Alter Production Data When It’s Copied?

Meaning when the data gets moved to a non-production system (demo, test, development, etc.), do you alter the data and obfuscate it to remove any identifying information. Make it “safe” data that can’t be used to somehow compromise your production system.

It’s a good practice, and one that I used to follow at a couple companies. I didn’t have any tools, but I did write scripts, load a few base tables of names, and then run those scripts as part of the restore job. They would randomly reassign new names to people, companies, addresses, etc. We would also redo phone numbers in sequential orders (555-555-0001, 555-555-0002, etc), and even randomly add products to sales or amounts to financial figures. It wasn’t perfect, and if you worked on the production system a lot you could guess which people were which, but it worked well for testing and client demos.

I actually ran into a product recently (Camouflage) that does this and it’s a great idea. It’s something that quite a few companies should be implementing to ensure that their non-production systems are that much more secure.

Steve Jones

The Dangers of Travel

I cross a lot of borders, and I have been worried at times about losing my electronic devices. There hasn’t even been an issue, but then again, I don’t really have anything of value other than the hardware. The bits themselves are fairly replaceable for me as I ensure I keep things backed up in multiple ways.

However, I wonder if this will start to become a new type of data breach. Will officials of governments be required to relinquish their devices when proceeding through customs? Will this happen to corporate employees? Something like this happened and it was unclear if this was an action on the part of the Department of Homeland Security in relation to an investigation. However, could this start to become a standard practice as a way for governments to spy on other governments or even corporations?

This definitely sounds like a movie plot more than something that occurs in real life I would guess this is what we’ll find to be true here. It’s also not likely to be that effective if it does become a standard practice. If devices were being confiscated and checked at any scale, I’m sure we’d all be looking to travel with blank laptops that only had a VPN connection. Once we crossed a border, we could easily access information and download it as needed, deleting it before we recross the border.

However carrying information on a mobile device is always a bit risky. You could lose a device by accident or theft, and anything you had on the hardware could be exposed to others. For most of us, it’s not a problem, but since some of us carry around database backups or developemnt data, we should be sure that we aren’t carrying sensitive information. There’s really no excuse to do so, no matter what your deadline. Use masked sets of test data that you don’t mind losing, and you won’t have an issue.

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.

Serious Hacking

There’s a piece that calls the US Office of Personal Management (OPM) data breach the biggest government hack ever. It might be, but give us a few months and I’m sure something will be bigger. After all, we constantly acquire more data, so the next breech is likely to contain more information. I’m also not sure most of us are actually getting much better at security.

There were a few notes about this that would apply to every company I’ve worked in. Such as the OPM not having a comprehensive list of devices and databases. I’m not sure any company does, and having worked with people that run SCOM-type systems, it’s a hard problem to solve. This doesn’t even cover the problems of Excel. Access, and soon, PowerBI data being scattered across systems.

However there was one problem I think we could fundamentally improve in most companies. The article noted that OPM didn’t have control over how it’s systems were configured, meaning an attacker could reconfigure things. Far, far too many companies allow a (too) large group of people to deploy changes to servers. Even when larger companies limit rights for developers, I’ve too often seen operations staff log in and allow developers to change systems to get them working.

As an industry, we really need to solidify and build better systems for ensuring the security of our hardware and software and preventing, or detecting, unauthorized changes. Certainly there will always be social engineering and other techniques that bypass security, but we should be able to prevent malicious changes to systems with solid architectures from our vendors/FOSS developers. We should also decide upon, and be sure, that our staff learn, understand, and follow, best practices.

Steve Jones

The Voice of the DBA Podcast

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

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.