This is a huge battle I am in the middle of fighting right now. I am working on a project that is extremely late and we are having all kinds of political pressure put on us by very senior people. Meanwhile their damn IA staff won't approve any of the tools or hardware that I need to help us get the job done.
One huge obstacle to open-source anything in DoD is the attitudes of their information assurance professionals. I have been told by numerous DoD IA people that "Open Source is bad because anyone can put anything in it" and "We'd rather have someone to call." I understand the second point -- we honestly don't have the time to run every last issue to ground and it's probably better if we do have some professional support for some of our most important tools. But the first just boggles my mind.
But the IA pros are, as a group, schizophrenic, because somehow people are getting things by them anyway. The system I'm working on has Python as a build dependency. The devs are creating reports using Jupyter notebooks.
Basically the DoD needs to stop being so damn obstinate about open source.
There are also many people who are trying to modernize software development practices in the DoD (and the US government more generally).
The official US DoD policy is very pro the use of open source software. The DoD's official policy on open source software is "Clarifying Guidance Regarding Open Source Software (OSS)" (2009), available at: http://dodcio.defense.gov/Portals/0/Documents/FOSS/2009OSS.p...
That policy says:
"a. In almost all cases, OSS meets the definition of “commercial computer software” and shall be given appropriate statutory preference in accordance with 10 USC 2377...
There are positive aspects of OSS that should be considered when conducting market research on software for DoD use, such as:
(i) The continuous and broad peer-review enabled by publicly available source code supports software reliability and security efforts through the identification
and elimination of defects that might otherwise go unrecognized by a more limited core development team."
(Full disclosure: Dan Risacher is the point-of-contact and lead author of this policy, but I helped write the policy.)
The claims that "Open Source is bad because anyone can put anything in it" is ridiculous. Anyone can edit proprietary software, too - just use a hex editor. The issue isn't whether it's technically possible to edit software (it always is), the issue is who has control over the supply chain. In both proprietary and open source software, there are only a limited number of people who have the privilege to determine what is accepted into the software. In addition, in almost all OSS you have a public record of who made what change (and what the change was), and everyone can see the result.
"We'd rather have someone to call" is completely legitimate. So, go hire someone. There are a lot of organizations who would be happy to take money in exchange for a person to call. It's how many companies make their living. This shift happened in the early 2000s.
To those so-called "IA" people who don't understand that open source software is a key aspect of software development today: welcome to the 21st century, perhaps you'd like to try living here.
> To those so-called "IA" people who don't understand that open source software is a key aspect of software development today: welcome to the 21st century, perhaps you'd like to try living here.
For good talent, it's easier just to leave, get paid more, have a better life, than spend your work life arguing with irrational sandbaggers.
IA is there to tell you no. You have to make the case to the aquisition organization and the end user that not using the tool is a greater risk to the mission than using the tool. And remember what you're developing may outlast your career- maintenance and sustainability are much bigger issues to the DoD than any discomfort caused to the developer, even if it means schedule slip.
And for what it's worth, open source has been used pretty widely on the projects I've worked on- there's risk being tied to a single vendor and most acquisition orgs get that. The rare cases where we couldn't use O/S were usually situations where someone was trying to do something on Windows machines and they were trying to fly under IA's radar.
Oddly enough it sometimes helps to go further up the IA chain- the program/acquisition IA guys are usually retired prior who just want to get a check, but if you can reach higher level service branch or OSD IA oversight staff they are usually more motivated and tech savvy, and more willing to help/give suggestions rather than just say 'no, try again'.
Hire a good Cybersecurity Engineer that can run all of the scans and make reports to submit up the IA chain. If you can prove that your IS or application is secure it really becomes hard(er) for the ISSM to say "no, can't, and I don't know"
We don't have a good cyber security person in-house, so we are relying on guidance from a very good and trusted cyber security engineer from a research institution that is under contract with us. I've been lobbying for money to hire a good cyber security person but haven't had luck (yet).
I work around the outside of the DoD world myself and I wish you the best of luck. The office of no in the DoD is extra strict and their (government) actual security is awful. Without getting into the details some of the stuff I have seen employees do is shocking. Another hoop you have to jump through is that it is such a pain to get hired by the DoD or IC and a lot of the better security people have a culture which clashes with IA and OPM to say the least so even if someone wants to get hired by them there is a good chance they will get rejected off of a culture fit or they smoked pot once in college half a decade ago.
STIGS say that if it is open source and unencumbered by contract support requirements that it is fair game. Use IA's own hammer against them. It's right in the AppDev STIG.
There must be a further vetting process beside whether or not an open source library has contract support requirements. Otherwise GOV developers could just pull some Chinese student's OSS encryption library for their next VPN project... Oh wait, there's FIPS. This blanket statement you've made isn't very meaningful.
They are not exactly wrong with the first point, actually. I once worked on a DARPA malicious code detection challenge and even carefully inspecting the source of a library can often fail to uncover a carefully crafted implant, even if you know there is going to be something there and even if you know it is hidden within a small area of 5-50K lines of code. Of course, they are right whether the code is open source or commercially developed (how many companies have counter-intelligence divisions to vet or monitor their employees to detect proper spies?). For something critical enough, you would want all the code to be developed in-house using some semi-formal process (or, if truly truly critical, formal verification), but it probably depends what the project is.
Of course, if it is in python, then it seems to me the horse is so far out of that particular barn door that it is now half-way across the country...
They buy 100% Juniper to secure their routing. Formal analysis?! They can barely analyze the purchase contracts. In fact, that too gets farmed out to contractors. You'd be hard pressed to find an actual civil servant or active duty military signature anywhere beyond a vague application or statement of need. Formal analysis... Oh, my sides, they are killing me!
Let me add a bit more irony here: github is blocked from my work(USAF) so I can't get to code.mil. All I want to do is be the workaholic that I am and DoD makes it literally impossible for me to do that. You have no idea how much bureaucracy can defeat the spirit of an employee. Most of my friends are leaving the AF for reasons like this. I'll do my best during my time here, but needless to say, I'm out.
For some reason the AF seems to have draconian web filtering in place, compared to other places I have experience with. In the late 2000's when I was still on active duty, we used to complain about having to look stuff up at home because when you'd go to search for a tech solution and it was on someone's random blog, 9 times out of 10 it'd be blocked. It was extremely frustrating.
Fwiw, I'm a Navy physician and have the same problem. Wait until you know, that right now, someone is very sick, and the study you're trying to look up is hosted on a server in some super sketchy non-ally, like Switzerland.
This is why part of my profile says "reformed rocket scientist". I spent a little under two years working for a NASA contractor on their sounding rocket program. The problems I was paid to solve were relatively un-interesting (find the best ways to fit the experimenter's data requirements into our ancient, antiquated, badly-in-need-of-replacement hardware). The problems the experimenters were solving were actually fascinating, but I didn't get much exposure to their side of things.
Now yes, I am struggling with Information Assurance people and their cantankerousness, but I also have the unique pleasure of being the primary data scientist on this very large project, which is exposing me to new things every day. I just haven't had an environment for learning this rich before.
> I have been told by numerous DoD IA people that "Open Source is bad because anyone can put anything in it" and "We'd rather have someone to call." I understand the second point
Regarding that point -- it's not really a dichotomy, is it? For the most popular open source projects you can nearly always find a corporation or 501(c)(3) willing to sell a support subscription. For the less popular projects, you might be able to get a subscription from individuals, if your sourcing rules allow suppliers like that.
The IA people have attempted to use "lack of paid support" to deny me the use of tools (PuTTY is one glaring example) that are already being used on other systems that I have access to, and that had to go through the same sort of IA approvals.
So they use the understandable business logic of "we'd like to have paid support" to some silly and pointless purposes.
And yeah, my experience is not universal, but it's not uncommon, either, if the tales I have heard from all sorts of professionals in this world have any truth to them.
> The IA people have attempted to use "lack of paid support" to deny me the use of tools (PuTTY is one glaring example) that are already being used on other systems that I have access to, and that had to go through the same sort of IA approvals.
This sort of thing was exhausting. It's a lack of communication/coordination between the units. I had one office that didn't want to use DOORS (everyone else in industry and DoD that was on the project had their own DOORS servers setup already). The reason: Money and time to set up. Here's the deal, though, that one unit didn't need to take on the whole burden. There were already other projects using DOORS in the organization, someone had done the server setup and license purchasing already! "All" we needed to do was coordinate with them to share the costs so we could have access to their systems.
But no, they wouldn't even let me take on that task. They'd rather keep passing around excel spreadsheets and word documents. Clusterfuck.
Same thing with 99% of server systems. Each unit established their own enclave, rather than sharing. So the licensing costs overall were about 5-20x what they should've been. One license/purchase for 1000 users is cheaper than 20x50-user licenses (typically).
Would it be useful if someone started a company that offered support for virtually any OSS? Like, you contact them, say "I need support for X", and they research it, figure out how much expertise they need to support it, and quote you a figure.
Perhaps this organization would also sign up to monitor for security vulnerabilities affecting the software, on your behalf, and would be responsible for getting you information about the patch.
> . I have been told by numerous DoD IA people that "Open Source is bad because anyone can put anything in it" and "We'd rather have someone to call." I understand the second point -- we honestly don't have the time to run every last issue to ground and it's probably better if we do have some professional support for some of our most important tools. But the first just boggles my mind.
Given the degree to which the DoD itself, via the NSA, has subverted open standards which have the same theoretical "many eyes" protection as open source, this isn't actually a surprising attitude for DoD to have.
Whether "no open source" is the best (or even a practicable, as the rest of your post addresses) method of addressing this concern is another question.
The "IA" in DoD is generally the NSA. The NSA is made primarily of two different camps. SIGINT is their offensive side aka "hack the planet". The Information Assurance Directorate is the "blue team" who tries to protect government infrastructure.
The overall, top-level IA people who set the standards and procedures that must be followed are NSA. However each department and organization is responsible for having professionals who understand the policies and can follow the rules.
True, but this project will not be allowed to die. So we will see what happens when the proverbial immovable object (IA) meets an unstoppable force (people with stars on their shoulders).
Well the flask security architecture (about 10 years of research that culminated in what is now SELinux) was written specifically for Information Assurance by IAD so... Blue Team.
It's not just the IA folks. The DoD regs are written in such a way that they only grudgingly accept that software can exist as its own thing.
The DoD by and large certifies SYSTEMS meaning a bundle of hardware and software. That makes sense when certifying an F-16 or an Abrams tank because they are bundled packages of hardware and software, but it is maddening when trying to work on say a web app or database.
A team I was on wanted to use a particular open source app and was told we couldn't because it wasn't authorized -- but it was bundled as part of the Oracle DBMS. So the ruling was that if we installed the Oracle DBMS on our desktops we could use it because that is how it was approved. But wait, another rule said we CAN'T run a DBMS on our desktops. ARGH!
That said it IS possible to use open source software. We use SVN and Tortoise SVN at work and it is explicitly on an approved products list. Another team is developing Java apps on Linux using Eclipse. But the only reason it is there is because an organization took the time to go through the test and evaluation process and submitted a request for approval to the network security gods (who are NOT your local IA people most likely) and waited 6-9 months for it to get through the review backlog. So it is possible, and your IA people SHOULD be in the business of helping you get to YES instead of just saying NO -- but the reality is many of them don't know how to get to yes because it can be a convoluted maze, so they just default to no for everything.
Bad IA people show up for the salary and point to a policy which says 'no' (i.e., not actually evaluating risk)
Ad-hoc proper IA requires evaluating your project according to a checklist of security controls. It could very well be something about open source doesn't fit well with those controls. The answer is to change the policy, then change the controls, and finally, pass your compliance checks.
Idk about DoD, but US Dept of Veterans Affairs is doing better with open source. Their bread&butter application, VistA, is open sourced. Their Technical Reference Model (TRM) is a catalog of approved/unapproved software. NodeJS and a lot of NPM packages are approved.
I know this is a little off topic for the parent but this seems where all the DOD people are collating.
I'm currently working in a research team at NJIT's CSTR. We're looking to do a lot of raytracing for a project that we are working on. We've talked to one of our friends at JHAPL and they said they use 3 internally, 2 were DOD projects and 1 was PHARLAP. He also claimed that PHARLAP was neither the fastest nor the best and that the only reason he mentioned it was that it's not export controlled and we can get our hands on it. We've started interfacing with PHARLAP and the progrnosis does not look good at all. ~12 seconds/trace, I assume because we're going from python->matlab->fortran then back from fortran->matlab->python.
Does anyone here work on those other 2 raytracers? If you do work on one of those I'd love to get an email from you to see if we can get our hands on a copy of it (either from the code.mil project or via some contract for internal use only).
If you'd like to know more my boss would love to do a telecon if you work on one of these.
We were planning on writing our own which would be a hard endevour so if anything we'd rather just improve someone else's raytracer to include the loss calculations we need.
For a brief moment, I had a mobile test automation gig. I found a device specific bug, and we only had one unit of that device. The device was inexpensive and easy to procure. But I had to make the case about why I needed to procure another device for fault isolation purposes, and doing so was not a trivial process. It kind of felt like a someone in accounts payable having to explain the need to buy more checks.
I am a Data Scientist without any tools except a single installation of MATLAB 2010a on a computer that my organization doesn't even own, on a network we don't even control. I have a few hundred TB of stuff I need to make sense of. I just can't do it with the tools available.
Not OP, but my assumption is that despite the concerns about open source, they are still using open source tools like Python and still collaborating using non-DOD approved tools like Jupyter (also open source). But correct me if I'm wrong.
OP here. The implication was that the organization cannot deliver consistent guidelines. The devs of the sim I am working on are using Python and Jupyter on their systems, which were accredited and approved in the exact same fashion that I need my corresponding data analysis network approved. However, the IA professionals -- who are the same people who approved the sim dev systems -- are telling me that my request for Python (actually I'm requesting an enterprise license for Anaconda Python distribution) is problematic for the reasons I spelled out in my original post.
Consistency, clarity, and understanding are what I'd like. But, these same IA people also get confused when I mention "highly technical terms" like the size of the SAN I'm planning on using.
Electronic components are practically the opposite of open source software. To evaluate an IC, you need to painstakingly decap it and study it under a microscope as well as logic probe it to ensure its functionality. And that only applies to the random sample of chips you audit. Open source software allows you to evaluate it with virtually no encumbrance, and once you've frozen a version in your source control, you do not have to worry about it changing underneath you.
One huge obstacle to open-source anything in DoD is the attitudes of their information assurance professionals. I have been told by numerous DoD IA people that "Open Source is bad because anyone can put anything in it" and "We'd rather have someone to call." I understand the second point -- we honestly don't have the time to run every last issue to ground and it's probably better if we do have some professional support for some of our most important tools. But the first just boggles my mind.
But the IA pros are, as a group, schizophrenic, because somehow people are getting things by them anyway. The system I'm working on has Python as a build dependency. The devs are creating reports using Jupyter notebooks.
Basically the DoD needs to stop being so damn obstinate about open source.