Securing Developer Workstations | The Coffeehouse

ScottWelker

I could use 9ers cogent thoughts on securing Developer Workstations. I am on a site where developers are constrained to very minimal workstation privileges AND, the infrastructure team is… well… let’s just say unresponsive. The frustration is off-the-scale.

I now have the ear – Monday – of someone with the authority to fix this. I need to make a sound case.

I understand and agree that the workstation must be “secured against attack” and I understand and agree with the “Least-Privileged Account” idea described here: http://msdn.microsoft.com/en-us/library/aa302367.aspx.

Our infrastructure team adds that they don’t want unsupported technologies “leaking” into our applications and, they don’t want the support calls when developers “wipe-out” their workstations.

I intend to propose largely keeping everything as it is now but with these additions:

1) For each “trustworthy” developer do as the aforementioned article prescribes, create a secondary, seldom used, administrative account.

2) Make the development team responsible for their own workstation image. If we (I) wipeout our workstation, it’s our responsibility. We won’t bother the infrastructure team.

3) Establish sufficient oversight, architecture/code review, production hand-off, ??, that ensures no technology ever “leaks” into our applications.

Sorry so long winded. This is the case I’ll make – with some fine tuning.

Please feel free to fire holes in it or counter or bolster the arguments.

AndyC

1) Doesn't work. Or maybe works for a few weeks before everyone just starts using the higher privileged account all the time.

2) Then you wander into the realms of developers thinking they know better than the infrastructure team. Manageability goes out of the window and the problems the infrastructure team have to deal with increase exponentially.

3) Plan ahead and know what you are going to need so that it can be dealt with in an appropriate manner? If there was much chance of that happening, it'd be where you are already.

lensman

Sounds like where I used to work. You are not working in Idaho by chance? :->

I would suggest you learn to love the word "Standards". Your infrastructure team likely has a corporate standard. Your development team should also have a "development standard". This standard should define what technologies your team will use and establish a "base" for your infrastructure team to help you with. I suspect you probably have the first but not he last item. Push for, adopt, and enforce the adherence of standards. They are a benefit to all parties. By providing your team with a set standard your team stays focused and develops quality code without diversions down non-approved technological side streets.

I am of course not suggesting you do not learn new items, but deploy them into your development environment in an agreed upon manner.

Depending upon how paranoid your infrastructure team is, you could also push for a completely different network. I.E., have development servers, dns, and other items on their own network. You the developers hold the keys and must fix your own problems. You cannot however get outside the "box" they put you in.

As to the least privileged account? While you can have a second box for this, why not use a virtual test box? This way you can test your deployment against a known configuration over and over again.

W3bbo
The Master of Baiters

Wouldn't it just be easier to put all the developer's workstations on a separate network, isolated from the infrastructure team's?

Or am I missing something?

harumscarum
out of memory

In reply to W3bbo

#Aug 17th, 2008 @ 1:43 PM

Or work off VMs that aren't on the network?

W3bbo
The Master of Baiters

In reply to harumscarum

#Aug 17th, 2008 @ 1:46 PM

Interactive virtual-machine performance still needs a lot of work, mainly due to the emulated GPUs. The emulated S3 Trio64 in VirtualPC 2007 can't run at 1600x1200 with 32bpp (which is smaller than my current desktop), the one in Hyper-V isn't much better either.

Modern GPUs can be virtualized (check out VMWare's work), but until emulation can be done away with completely a VM will never match the responsive feel of a native desktop.

Jason I

In reply to W3bbo

#Aug 17th, 2008 @ 4:52 PM

I used to work only on VMs. We had a nice Server, Dual Core / Dual Proc server, 16gb of RAM, Windows 2003 R2 (if I recall correctly), RAID configuration (forget which one). One main drive for the OS, the RAID was used only for the VMs.

I would VPN into the corporate network and use Remote Desktop to go into my box for development.

Note, I wouldn't be running high-end graphic apps at all, but the work I did, did involve UI work,

The thing was so fast, it honestly felt like I was working my laptop, when in fact my remote deskop was merely full-screened.

Man, I miss that box.

W3bbo
The Master of Baiters

In reply to Jason I

#Aug 17th, 2008 @ 6:48 PM

Accessing a VM via RDP isn't running it in Console mode though. When you use RDP you're using the rdpdd display driver which isn't emulated so you're going to get better interactive performance with rdpdd than any emulated GPU.

ScottWelker

In reply to AndyC

#Aug 17th, 2008 @ 8:46 AM

Thanks AncyC for your thoughts. Here are my knee-jerk thoughts - sorry, so little time…Ninjas on fire, and all Wink

1) In this limited case, #1 does work. I agree it won't work in many cases and, of course it won't even work for all of our developers. However, for this finite group, it does work.

2) I don't really follow your response to #2. The intent is to relieve infrastructure of what they perceive as an onerous burden - restoring the developer workstation in the event we... wipe out the registry or something. Perhaps you're responding to our [developers'] propensity to choose to use (install) our preferred tools. In this regard we do know better than the infrastructure team.

Oh! This tips me off to an unspoken concern that is certainly in play: LICENSING! Thanks!! I'll probably suggest one of the many scanning solutions… probably within infrastructure's prevue.

3) My #3 was meant to address infrastructure's concern regarding unsupported technologies "leaking" into our applications. There must be some history here but I am too new on this block to know what that is. Present process precludes this but there is MUCH room for improvement.

ScottWelker

In reply to lensman

#Aug 17th, 2008 @ 8:53 AM

Nope lensman, not Idaho, Roseville CA. Smiley

Standards, Guidelines, and Process are terms I know well. This team I recently joined grew up in the fires of an environment that had no patients for such burdensome stuff. Now, under the crushing weight of the resulting maintenance costs, they desire a change. Helps that the competition is nipping at our heals. It's going to be a long and arduous journey but at least we're taking first steps.

Thanks for your counsel. Much appreciated.

ScottWelker

Thanks to all who chimed in with "Separate Network", VM, and the like. I thank you for your input.

Right now, I'd have better luck asking for delivery of the moon on a silver platter. Perhaps these are worthy long-term goals but our group is simply in no position to adopt these - at this time.

Thanks again though for your thoughts. I'm absolutely not dismissing any of these. Just need to aim low right now.

vesuvius
Das Glasperlenspiel

At some point, you have to eat humble pie and just accept that you are not, and will not be the administrator of the network. Were the network administrator to supply you with administrative privileges, then they'd be talking themselves out of a job. Why would they bother coming to work if everybody has admin access and can do as they please?

In Britain, the Prime Minister reserves the right to re-shuffle his cabinet (bad example I know - politics 'n all). What happens when he or she supplies other cabinet members the right to re-shuffle whoever they want at a whim?

Disaster, that's what happens.

This is by no means and isolated request. In any IT company, whether it is support or development, you always have advanced users (I know you are much more advanced than advanced) who require a little more control, but in my experience it has always been an opportunity for person x-y-z to show me who is boss.

AndyC

In reply to vesuvius

#Aug 18th, 2008 @ 6:49 AM

Agreed. In fact, I'd go so far as to say you're asking the wrong question. Rather than make demands, why not talk with the infrastructure team to find out what it is they can do to support you better. Tell them what software and tools you need and let them find the way to best support that within the constraints they need in place to ensure a reliable and stable environment.

ScottWelker

In reply to vesuvius

#Aug 18th, 2008 @ 6:49 AM

Err... umm.. humble pie? I suppose my quick, terse postings may have created the impression that something of the sort is in order. Not so. Likewise for network administration. I have no desire – or expertise – in this area. I simply desire the tools to do my job – designing and building software.

ScottWelker

In reply to AndyC

#Aug 18th, 2008 @ 6:54 AM

"...talk to the infrastructure team.." Exactly what I (we) are preparing for Smiley

I gotta watch the hastily complied, terse postings Smiley )

Thanks all for your assistance. Good stuff and it is much appreciated. I'll keep you poseted.

Andor

I think the bigger issue, is, what are you doing that actually requires developers to have administrative priveleges? I've yet to encounter a single situation where I've ever needed administrator priveleges to do anything dev-related, with the exception of testing installer packages (which I do in a blank slate windows vm installation anyways).

If none of your dev-work requires it, then, the devs should not have administrative priveleges on their machines at all. And if a dev is wiping out their workstation somehow... then there's something seriously wrong with that developer, and I'd seriously question their future employment.

As for technology "leaking" into your code, that's what code review is for, and actually keeping track of what your developers are doing. That's more of a management issue than any sort of infrastructure issue. After all, you have to let developers be able to modify the code, which automatically lets them put whatever they want into their part of the codebase, there has to be some measure of trust here. Setting a clear policy on what is allowed here and what isn't is needed, with real consequences if you get caught doing violating the policy.

Proposed solutions 1 and 2 simply do not work at all.

androidi

In reply to ScottWelker

#Aug 18th, 2008 @ 12:54 PM

App virtualization is more light weight approach to running things without affecting the environment than VM's etc.

a) Simpler solutions that also allow you "going behind the back not telling anyone": Installfree and Thinapp should be able to wrap anything that doesn't install drivers so that it will work with limited privileges. Atleast that's the word, I started only recently playing around but it looks good. Of course if they say "use this and that" and attempt to restrict things so you can't use anything else and find out you still managed to do things your way then you might have some explaining to do.

b) There are other solutions that are more centralized and have also things like license management and so on. These more likely to involve more initial setup work where as the above ones can also be centrally deployed but in more hands on way rather than a ready made solution.

Here's a chart http://virtualfuture.info/2008/06/virtualfuture-appchart/ that compares the different products and from which my info above is from.

ScottWelker

In reply to Andor

#Aug 18th, 2008 @ 3:03 PM

Surely Andor you've had need to install something new or different, i.e. not already on your workstation. Many (most?) installs require administrative privileges.

For example, just today I needed to view a Scalable Vector Graphics (SVG) file. If there is a viewer on my company provided XP Pro workstation, it isn't associated with .svg files. No problem, Adobe's freeware viewer will work just fine... Doh! Can't have that. Requires administrator privileges to install. Yes I was readily able to get around this, that's not the point (9ers - I am not looking for a solution to this).

Re: "devs should not have administrative privileges on their machines at all": In the ideal world, I'm inclined to agree. However, there MUST be adequate provision for handling the odd cases where something new or different is genuinely needed - my previous example isn’t the best but it illustrates the point.

As for developers wiping out a workstaion, again we agree. Not sure this is a rational concern but it IS a concern of our infrastructure team.

Re: technology "leaking" into the App: again we agree. Seems this is a ghost of the past. I see no evidence this is an issue. It would be caught in our Regression/Acceptance testing where the environments are sufficiently controlled to prevent it. Also, we are instituting code reviews.

Thanks a bunch for your thoughts. Much appreciated!!

ScottWelker

In reply to androidi

#Aug 18th, 2008 @ 4:59 PM

Thanks androidi, I'll review the info. Looks very interesting. However, I am not prepared to argue in favor of virtualization - at this time. I prefer as little boat rocking as possible, while accommodating everyone's concerns.

Thanks again all. The discussion was most helpful.

AndyC

In reply to ScottWelker

#Aug 20th, 2008 @ 1:30 PM

Yes. But the whole point of having a managed desktop and an infrastructure team is so that they can assess the impact of installing new applications, roll them out and update them accordingly. Now, if you have a problem that your infrastructure team need to be more agile so that delays are minimised, that's one thing, but expecting them to simply grant full admin rights isn't particularly helpful since it undermines their ability to do their job just as much as you not having an SVG plugin (or whatever) may undermine yours.

jjesse

In reply to ScottWelker

#Aug 20th, 2008 @ 3:20 PM

Follow the corportate standard the infratstructure team has created or if possible work on creating a developer standard. As to the "free" adobe program are you sure its licenseable for business work? Remember the "Free" version of Adobe is for personal use and not corporate use.

Licensing is a huge pain in the a$$ however it sis something that needs to be dealt with and worked with.

Infrastructure team is trying to manage the devices in an easy to do automated way and needs to be kept as standard as possible.

cheong

In reply to jjesse

#Aug 20th, 2008 @ 5:36 PM

Actually, he did mention that it is "Adobe SVG viewer" which is free even for corporate use (Just like the Adobe Reader.)

Note that lots of the "read only" softwares (like Microsoft's Word/Excel/Powerpoint viewers, RARLAB's UnRAR DLL, just to name a few) are free and you might use them freely.

If it's in-house development, the choice of free software/libraries would have been even wider (GPL does allow free usage as long as you're not going to sell the software that includes it).

Although I'd agree that's the way to go to ask the infrasturcture team to install it, dealing with unresponse infrastructure team can be a pain. It's always a good idea to keep a handfull of "replacement toolset" that offers less functionality, but neither need administrative right to run nor need to be installed (mostly command-line tools however... who knows why it's so rare to find capable GUI variants).

ScottWelker

In reply to jjesse

#Aug 20th, 2008 @ 5:36 PM

Understood and agreed. I am simply in a position to influence a standard that isn't working for us. Got many good ideas here. Much appreciated.

ScottWelker

In reply to cheong

#Aug 20th, 2008 @ 10:46 PM

Thanks Cheong, I think you bolstered by point. Again, we'll work through this and ensure everyone's concerns - especially the important concerns of our infrastructure team - are met.

ScottWelker

Ha! I'm such a dope.

I actually believed the Infrastructure Manager, ture to his word, would hear me out. Did I mention they were... less than responsive? Perhaps in the coming months... Can't believe I fell for that :-/

Thanks to everyone for your thoughts... may prove useful... eventually. I'll just keep to company provided workstation as a door stop and continue working off of my laptop Sad