Protecting Code

There are so many data breaches taking place, that it’s hard to keep track of them. While I rarely find my email in any of the breaches loaded into, I do see Mr. Hunt regularly loading more data sets into the database. I don’t know how many you’ve been a part of, but I certainly hope you know, and I hope you’ve changed shared passwords and updated accounts.

While we do need to protect data, we also need to ensure that we protect our code, as that might be where the vulnerabilities lie that others might discover. While I’m not a big fan of encrypting or hiding the code in a database from customers, I certainly don’t want that code, or the application code, to be visible to outsiders, especially potential hackers.

While your team might not be are careless as the Boeing research team, I’d hope that you don’t expose your code on the Internet, as they did. Perhaps more importantly, I hope no one does a Black Hat talk about potential issues in your code. A researcher did this to Boeing, talking about potentially being able to jump from a customer network and application to a more privileged one to the command and control network. Boeing denies this is possible, and I’m not worried about my future Dreamliner flights, but I think Boeing should do more publicly here. Let the researcher have a few days on a plane and truly pen test the software.

I’ve seen lots of “hidden” features in software that administrators use to get work done. I’ve seen sloppily written tooling that solves a problem and isn’t intended for general use. I’ve also see far too many of these features “discovered” by ordinary users. Even assuming your internal network is completely free of malicious users is a bad idea. We’ve seen plenty of viruses and trojan software that can be used maliciously.

We don’t want to lock our networks and applications so tightly that we create impediments to work, but we certainly can do better jobs in limiting access, keeping tight privileges, ensuring administrative accounts are protected and more. Those might be hard to get done today, but you certainly can prevent simple things, like securing your VCS. Don’t use public places like GitHub, or ensure you have private repositories that only your organization can see. It’s not perfect, but it does stop the researchers and lazy criminals that are just scanning for easy targets on the Internet.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , . Bookmark the permalink.