Creating a secure development environment

[mmirabito]

My apologies if I am putting this in the wrong category but I am not sure how to classify it.

We have been developing in Java for a while. Our development environment involves installing Eclipse and Jboss on a local development machine then connecting to a SQL server remotely.

A week ago we were notified by security that we are in violation of desktop software. Apparently security decided that running Jboss (server software) on desktop constitutes an undue risk.

Frankly I was dumbfounded when I heard that, I tried to explain to the security team how a developer needs a sand box to do his/her development but obviously I was shut down. Of course when I asked if they had an alternative they were quick to point out NO.
One person mentioned using a VMware farm, developers can connect to an instance preconfigured with Jboss and do their work.

I am wondering if any of you can give me pointers/ammunitions or a case for or against this direction?

I am really interested to know how other enterprises are doing their development and what are the best practices that will placate the ?SWAT Team??

If VMware is the way to go what will performance be like?
Do I need to load all my development tools (i.e. Eclipse) or can eclipse connect to a remote Jboss instance as it was local to the box?
What is another alternative?

I am aware that virtualization is hitting the data centers and there are talks of deploying dumb-like terminal but is this really feasible for developer workstations

Any insight is greatly appreciated

Max

[peterj]

Usually security teams are concerned when server applications open ports that are accessible from other PCs. With JBoss AS 4.2.x, it opens ports but binds to localhost. Thus only users on the same desktop PC have access to the app server.

If you are running a 4.0.x version, you can always bind to localhost by running as:

./run.sh -b 127.0.0.1

If this issue of accessible ports is not what concerns the security team, I would be interested in knowing what the issue is.

[mmirabito]

Peter,

Thanks for the suggestion. As far as I remember their concern was twofold
1) a worm making it's way from Jboss through some type of vulnerability and propagate across the network like wildfire
2) inability to shutdown or patch all the servers if they discover a vulnerability

I understand that these things need to be mitigated but I am not sure how effective is the suggestion of running from a vmware farm. I feel like we are taking 10 steps backward, but maybe this is where IT is going too.

I am compiling a list of alternatives so yours will be definitely at the top.

I think most companies would be running Jboss development on developer desktops, am I imagining things? How do you guys do it?

If you or others have more ideas, either good or bad please feel free to share, I will take anything :-)

Thanks again,

Max

[peterj]

I do not see how a worm could propagate through the JBoss app servers if those app server are not opening ports accessible by remote hosts. You cannot get at the app server if it does not provide you with an opening. By binding to localhost, the app server could be considered just another desktop application. Heck, any application can send traffic out to the network, that's what outbound firewalls are for (and why Windows Firewall is a joke), to stop such traffic.

I do not see why they could not shutdown and patch your desktops if the JBoss app server is running. I think they are confusing production machines with desktop development machines. If your desktop reboots to apply a patch, who cares that the app server is down? Only you. But then your whole desktop rebooted so it is not like you could do anything anyway.

One solution that we implemented was to take offending machines and place then on a private network. Several of our machines could not be upgraded to meet corporate security requirements for various reasons, so we placed them all on a separate network with their own routers, etc. We then took a "corporate approved" machine on the corporate network, added in a second NIC and connected that NIC to the private network. To gain remote access to a machine on the private network, we remote desktop (or VNC) to the "bridge" machine, and from there remote desktop (or VNC) to the desired machine.

I think in your situation I would ask for a second desktop (most places have older PCs sitting around), hook the second desktop to the corporate network to do email, etc. Then take my primary desktop off the network and do my development work in peace. If several people in your group are in the same situation, you could network all of the development PCs and perhaps get another PC to host the database. You could even use that PC as the "bridge" to the corporate network.

[adldev]

We do the same as PeterJ mentioned in the last paragraph.

Our environment is an extremely secured area and network. Therefore they gave us a separate pc to go on the the secured network to view email within the corporate environment.

Our development PCs are on a separate isolated network with each of our own JBoss sandbox. We need our individual sandboxes to develop in, till we were able to interface our platform developments together. If we didn't we would be stepping on one anothers processes before we were ready to interface.

Ah, one more thing. That PC they gave me for my secured email, after 1 year I told them to get rid of it out of my cubicle and they did. I believe, if the only function of a PC is to run my email and produce nothing at the end of the day like my development machines do, it wasn't worth to keep.

That machine was so secured with software and hardware (and I could not even admin that PC for basic maintenance). I would come in every morning and see it on because the network admins ran remote scans and updates nightly. No wonder it burned up 2 hard drives. As far as my development PCs (two of them), they have ran great for 4 years no problems.:)

They took out that PC, 1 month ago when they noticed I had unplugged it and had it plastered it with post-its and taped class diagram pages on its PC monitor. I couldn't use the monitor for my other PCs because it was a security violation. Go figure.

Now I read my email at home with better security then I had at work.

[mmirabito]

Thanks for you continued feedback.

I agree with you all that if you are running on localhost there should not be problems. But I am beginning to think security teams operate under the concept of "conspiracy theory" and all development teams are and an due risk to the network.

We already have a second desktop but both are connected to the same network. One for email and office apps with no privileges and the second one is for development with full admin privileges.

We where told that separating the network is not possible at this time ? this is a long term plan. Of course I can?t argue this since I am not an infrastructure guy.

The dual-nic came up briefly but always in the context of doing RDP to VMware server session. The way I see it if this stands we would turn our workstations (dual core 3GB RAM and 500GB+ HDD) into dumb-terminals ? how smart is that?

I like the idea of working disconnected (which BTW I do when I am not in the office) but then it becomes a challenge to manage lots of developers that require enterprise services (ie DBMS, LDAP, Reporting server, source control etc)

We could duplicate them on the disconnected workstation but how practical is that beyond a DBMS? In addition if we need to do research on the internet we now would have to use as second PC and manually transfer files.

I am also curious to know what JBoss would recommend assuming you guys are not working for Red Hat already?

Thanks again for your thoughts

Max

[peterj]

adldev - ROTFLOL! Your story is a classic, thanks for brightening my day.