RFI: Looking for DAC coders with their dev box on commercial ISP

[Chaim Krause]

Please contact me off-list if:

• you're a software developer directly paid by the US Govt (DAC, Warfighter, etc.)
  
• have a computer used for software development that you have full admin rights to
• have an unfiltered ISP connection to that dev box

I work in an organization that knows nothing about having developers that actually need to do their job. Consequently I have enough restrictions placed on me that it is literally impossible to do my job. Things are so locked down that I can't do development work and now I have had my internet connection pulled.

I am not informed enough to be able to tell my direct boss(es) how they can provide air cover for me. I know their must be "special rules" for developers that allow them to do things "normal users" can't.

I get shut down constantly by the same "excuses" every time. A variation on themes of "If it isn't on the AGM you can't use it. You can't have Admin rights because you aren't IA. And no way you can hook up a computer to anything other than the Army's Internet which blocks all of that nasty hacker stuff you try to do."

How is this MIL-OSS related?

My current project involves me researching OSS to meet a customer's needs. I need to download OSS source (from many places on the Internet I can't get to), compile it (with tools I can't install on my computer), install it (on boxes I don't have admin rights to), on operating systems I am not allowed to use.... and on an on.

As a contractor I would be fired if I didn't do all that everyday.

I cannot promote OSS if I can't build it and use it and show it.

If it matters, I am a DAC on an Army installation.

In a perfect world, I would take some form you already had approved, whiteout your info, replace it with mine, and get what I need.

Thanks,
Chaim

[Ben Congdon]

We have the same issue and we're tackling it on many fronts.  We are currently seeking approval from our chain of command to purchase Amazon instances for development work (there's already a GSA contract available to buy them).  We're also working to get an ISP connection but that is taking a little longer amount of time than expected (GIG Waiver issues).  

As a contractor, I would think it would be easier for you to procure an amazon instance, rackspace box, etc... to remote into and do the things you need to do.  Software development is normally farmed out to contractors anyways as they can do software development at their site where it is strictly verboten on most/all DoD networks.  

Are you familiar with the process to get the software and/or network exception approved?  If so, I suggest you bombard them with requests as that sounds like the current, correct process to go about getting what you need.  As for global special rules, in my experience, the rules and processes are per enclave, per network, per person, per group, per agency/component/service.  I could give you the forms we use to have unapproved software approved and network exceptions created, but they would not be accepted by your group's IA/IT deciders (for a lack of a better term).

I've been trying to do my job without being able to have the tools to do my job for 6 years now, welcome to the club.  We have gripe working group meetings once a day.

--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com
To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
 
www.mil-oss.org

[Ex Nihilo]

Air Force govie here.  We are working closely with our agency IA and CIO for a development and testing network not on the GiG at unclassified as a "Class 3 waiver" (their words, not mine) on an ISP line. Our CIO recognizes our need due to the massive amount of R&D we perform for machined that have freedom in development, and act like STIGed machines in testing - majority of our projects are proof of concepts that when show ROI get rebuilt into formal processes with C&A onto the GiG. In return, they get to play also with newer tech not on the approved list to apply for its approval for AF EPL. Win-win.

Sent from my iPhone

[Josh Doe]

After struggling for literally years to develop on my network machine,
I gave up and do everything on an offline machine. This definitely
limits what I can do (no developing net apps), and still causes a
great deal of frustration and delay (constantly transferring files,
which makes Windows development nearly impossible, but apt-mirror
saves the day for Ubuntu). I think Internet + admin rights is a dream
for CIV/MIL, except for large teams that have the clout, time, and
expertise to get a whole host of waivers and exceptions.

-Josh

[Chaim Krause]

Your situation seems a close match to mine. I'll email you directly so we can compare notes and group therapy.

Ex Nihilo <ex.n...@detrimental.org> wrote:

Air Force govie here.  We are working closely with our agency IA and CIO for a development and testing network not on the GiG at unclassified as a "Class 3 waiver" (their words, not mine) on an ISP line. Our CIO recognizes our need due to the massive amount of R&D we perform for machined that have freedom in development, and act like STIGed machines in testing - majority of our projects are proof of concepts that when show ROI get rebuilt into formal processes with C&A onto the GiG. In return, they get to play also with newer tech not on the approved list to apply for its approval for AF EPL. Win-win.

Sent from my iPhone

On Aug 16, 2012, at 11:41 PM, Ben Congdon <benjamin...@gmail.com> wrote:

We have the same issue and we're tackling it on many fronts.  We are currently seeking approval from our chain of command to purchase Amazon instances for development work (there's already a GSA contract available to buy them).  We're also working to get an ISP connection but that is taking a little longer amount of time than expected (GIG Waiver issues).  

As a contractor, I would think it would be easier for you to procure an amazon instance, rackspace box, etc... to remote into and do the things you need to do.  Software development is normally farmed out to contractors anyways as they can do software development at their site where it is strictly verboten on most/all DoD networks.  

Are you familiar with the process to get the software and/or network exception approved?  If so, I suggest you bombard them with requests as that sounds like the current, correct process to go about getting what you need.  As for global special rules, in my experience, the rules and processes are per enclave, per network, per person, per group, per agency/component/service.  I could give you the forms we use to have unapproved software approved and network exceptions created, but they would not be accepted by your group's IA/IT deciders (for a lack of a better term).

I've been trying to do my job without being able to have the tools to do my job for 6 years now, welcome to the club.  We have gripe working group meetings once a day.

[Rick Brennan]

Chaim, 

I spent 30 years in uniform in the Navy (20 of these in the Reserves), flying carrier-based fighters, then working mostly on air vehicle systems as an engineer.  After my active duty time, my day jobs were in a series of positions in Silicon Valley including a stint running Sun Microsystems corporate internet development group in the mid 90's - when Java and XML entered the scene.  I now run a software development company that focuses on building scalable software for particularly difficult challenges.  One of our contracts is with the UCAS-D program where we signed on to lead an effort to combine government and commercial developers building government open source software applications for autonomous air vehicle operation and integration into carrier air wings.   

We started out trying really, really hard to integrate the civil service coders into our development environment (cloud-based, Eclipse, Maven, SVN, Bugzilla, etc, etc).  The idea was to get lots of developers across multiple teams to use a toolset that facilitates code sharing, collaboration, continuos integration, etc.  What a nightmare.  Things that were trivially easy to set up outside DoD proved impossible to do for these guys.  No technology problems whatsoever - all policy issues.  We decided to go at the policy issues directly.  Our argument was (and still is) that software development needs to take place under a different enterprise ruleset than the standard enterprise user.  Rules that make sense for 99% of the Navy make it impossible for civil service developers to work.  We met with senior security folks.  We met with senior NMCI infrastructure folks.  Asked for waivers, made proposals.  To date (over 2 years in), we've been unsuccessful at getting the government developers simple VPN access to our tools and administrative control of their machines for local tool installs.  Our environment is a virtual development environment - advanced, but not at all unusual for developers today.  The Navy denies that environment to it's developers by policy.  

This problem is self perpetuating.  Because there is so little experience with advanced software development inside DoD, the techniques and advantages are largely unknown, and when there is awareness of them, the lack of experience makes it so that developers and their chain of command don't understand the issues.  Because the experience level and understanding is so poor, software acquisitions that are contracted out cannot be evaluated or managed effectively.  The result is expensive software that integrates poorly, and can't be maintained, integrated, or updated effectively by the customer.  It also results in good developers leaving government service to go to work where they can do their jobs effectively.  Lose, lose, lose.

We work around the policies, but that's just ignoring the issue.  Love to fix this problem.  Please let me know if I can help.

 

Rick 

Phone: 303 748 2373
Email: rick.b...@opsysinc.com

www.opsysinc.com

[Kit Plummer]

FWIW I think the community here would benefit from the open dialog.  I'm sure there are others with similar/same sitches.  You're not wasting anyone's time - so unless you don't want to have a "big" group continue here.

Kit

[Chaim Krause]

I've had about a half-dozen replies from people who are having similar problems. I will let them repost here if they choose.

I am giving some thought to starting a support group. Maybe one of the "sub lists" that have been mentioned here.

Kit Plummer

Friday, August 17, 2012 10:38 AM

FWIW I think the community here would benefit from the open dialog.  I'm sure there are others with similar/same sitches.  You're not wasting anyone's time - so unless you don't want to have a "big" group continue here.

Kit

--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com
To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
 
www.mil-oss.org

Chaim Krause

Friday, August 17, 2012 10:34 AM

[James Neushul]

Chaim,

I have fought this battle on several occasions.  When I prevailed this was my approach:

1. Actively developing on an operational network that is connected to the Enterprise represents an unacceptable security risk and should never be supported.

2. Any organization can provide access to "White Line" - ie: unfettered Internet from a public service provider - to SELECT personnel as long as it is not connected to the Enterprise network,

This provides several practical advantages:

(a) The ability to view external facing pages from an unfiltered perspective.
(b) A redundant network in case the Enterprise is compromised or successfully attacked.
(c)  Access to development resources and other products which could compromise the Enterprise.
(d) Isolated environment to develop software without placing the enterprise at risk.

In general those who will prevent this access for developers are people who don't understand software development - and will actually place the entire DOD enterprise at risk by allowing code development to proceed on active government networks.  This betrays a naive trust in current security measures and is fundamentally stupid. 

If people like this are in charge of development activities on live DOD networks - they place the entire DOD at risk and should be stopped.  All security policies should prohibit software development on enterprise connected machines..

So - say you achieve this level of understanding..  What is "White Line" and how do you get it?  In most cases installations have cable television service.  A Cable Internet modem  can be installed on any outlet - and a dedicated line can be provided to those who need it.

The use of White Line requires reasonably intelligent leadership/management - but it also requires responsible users.  If specified users/developers act like children and surf porn or connect government computers to the White Line or otherwise create back doors into the DOD network - then the policy of treating highly paid programmers like children will be justified.

If you do not achieve any kind of acceptable arrangement - such as White Line or the ability to work from home - then I would simply recommend that you quit and get a job with people who understand software development.  I know that the DOD will pay you to accept stupidity and accomplish nothing - but this can't be the right answer no matter who's fault it is.

In summary - my recommendation is to pursue a rational security minded approach.

Cheers,

Neutron

[ben]

On a side note, if you have or have had an accreditation for a standalone zone D development enclave that is not connected to any DoD network, please tell us how you did it (and if you could send me your accreditation documents that'd be nice as well).

[Howard Cohen]

I set one up while at Lockheed Martin.  We followed NISPOM Chapter 8 http://www.dss.mil/isp/odaa/request.html There is a process in place to setup offsite and stand alone developer networks.  While at LM, we managed electronic information technical manual builds XML for the Navy and work related to SQQ89. 

 

Part of the problem here is that this process takes time and is not very friendly.  The good news is that you can do it. 

 

 

V/r,

 

Howie

 

On Mon, Aug 20, 2012 at 11:00 AM, ben <benjamin...@gmail.com> wrote:

On a side note, if you have or have had an accreditation for a standalone zone D development enclave that is not connected to any DoD network, please tell us how you did it (and if you could send me your accreditation documents that'd be nice as well).

[Andrew Dunn]

For some of us who emailed Chaim directly I'm guessing its because we didn't want to publicly relate our experiences as it can be damaging to our home organization.

I feel that Rick Brennan's last paragraph was really a topic that should be discussed more frequently in the MIL-OSS space. This may be one of the few cross organizational communities where we can discuss an widespread issue with policy implementation that is forcing capable developers to leave the government space.

[andy e]

I don't want to side track this discussion, but:

> All security policies should prohibit software development on enterprise connected machines..

Anyone with a web browser and a text editor can do 'software development'. In a day when NASA can upload live code to a rover on Mars, when github/etsy push code to their live, money generating websites tens of times per day, is this the attitude we should expect from the gov't side? Isn't that part of the problem ("no coding on ops systems!!!11!")? 

Seems there should be some grey in that area. 

andy