http://www.sqlservercentral.com/blogs/brian_kelley/2009/10/02/security-development-servers-and-workstations/

Printed 2014/07/26 01:16PM

Security: Development Servers and Workstations

2009/10/02

I've written about this before, but probably not as a specific subject or blog post. Trading some comments with a friend brought this topic to mind. Basically, there are some things in security we know not to do in production. Things like putting your spouse's name or your favorite sports team as your password. And it was along that kind of line of don't dos we were having the conversation on. So my friend said, "Hey, I'll throw a reminder not to do that in production." The catch is this isn't something we want to do anywhere that can touch production.

If we take a step back and put ourself in the attacker's mindset, one of the first major goals is to get a foothold somewhere in the environment. If I'm an attacker, I don't care if that's a development server or a workstation, so long as I can get to the production servers where the production data is. In fact, knowing that usually there is greater monitoring on production systems, I may prefer to be on a development server, because scrutiny is less. And that means my changes of discovery are less. So if something is considered a weakness in production, it's a weakness anywhere that touches production, even if the specific asset isn't labeled "production."

Let's stay in the mindset of an attacker and consider a bit further. As an attacker, my goal is getting the data. If production data exists in non-production environments, then a development server holding said data is of just as much interest to me as the production server. Remember, my goal isn't to compromise the production server. My goal is to get my hands on the production data. And if that production data happens to reside on a development SQL Server or a developer's workstation or in the Access database of a business analyst, I could really care less. I will take the easiest method I discover first to get the data. I'm not interested in some security joust like knights of old to see who is the greatest. In fact, if I can avoid security measures, I'll take that approach every time.

This is also one of the reasons physical security is so important. There are a lot of things we don't even consider as a possible entry point that an attacker might. For instance, printers that are connected to the network have a network connection. And you're probably thinking, "Yeah, Brian, that's what connects it to the network." If it has a network connection that gives access to the production network unhindered, that's a point of entry. As an attacker, if I can slip into one of the buildings, find a little used printer, and hook up some device that allows me remote connectivity, then I'm effectively in the network. And it may be a while before anyone realizes that printer is unavailable and should be available. Most folks don't think, "Hey, they can get in by using the network port where the printer is connected." Now if you do, then you're thinking about ACLs to restrict where the printer can talk, etc., but you get the idea. And once such access is gained, the attacker will begin to look for the first vulnerable target, compromise it, and then spider from there. If that happens to be a development server or someone's workstation, that's just fine.

 


Copyright © 2002-2014 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.