OMG, DSS, & ODAA Process Manual v. 3.3, para 5.2.2
Joshua L. Davis
ODAA Process Manual v. 3.3, para 5.2.2
An unclassified software review
and/or testing provides two options for examination of unclassified software
prior to its introduction into the IS and use for classified processing; 1) the
contractor may choose either a review or testing of the unclassified software,
2) an unclassified software review must be a line-by-line source code review.
Unclassified software testing must include a validation of all functionality
for security-relevant items.
- Open-source software must be downloaded from a
trusted (government) source or the source code must be reviewed line-by-line
prior to each installation on an AIS.
- DSS will not (re)accredit systems with
open-source software unless it meets the above requirement; recommend removing
open-source software on systems coming up for reaccreditation to avoid DSS
delaying ATO issuance and remove all
Josh
678.831.0182
@ijoshuadavis
Wheeler, David A
I only know of version 3.2. Is version 3.3 out? Where would someone get a copy? Version 3.3 may be a draft...!
--- David A. Wheeler
John Scott III
Sent from my iPhone
--
--
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
---
You received this message because you are subscribed to the Google Groups "Military Open Source Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mil-oss+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Wheeler, David A
http://www.dss.mil/documents/odaa/ODAA%20Process%20Manual%20Version%203.2.pdf
Where’s this version 3.3 coming from?
--- David A. Wheeler
Trevor Vaughan
--
--
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
---
You received this message because you are subscribed to the Google Groups "Military Open Source Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mil-oss+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Vice President, Onyx Point, Inc
-- This account not approved for unencrypted proprietary information --
Joshua L. Davis
There was an internal email where I believe DSS shared draft language
Kyle Harrigan
Paragraphs of fun include 5.1.3, and 5.2.2, among others. Left as an exercise to the reader. Enjoy!
Wheeler, David A
Thanks for the info! The only document with version 3.3 identified that I’ve seen is “Defense Security Service Process Manual for the Certification and Accreditation of Classified Systems under the NISPOM” Version 3.3 May 21,2016
http://www.dss.mil/documents/odaa/ODAA_Process_Manual_Revision_3.3.pdf
I can’t figure out if this is a final document – or even a real one. The website doesn’t say that this is the current version, however, it has no “draft” markings either. Even weirder, it says it’s from the “Defense Security Service (DSS) Industrial Security Field Operations (ISFO) Office of the Designated Approving Authority (ODAA)” – but the Office of the Designated Approving Authority (ODAA) was recently renamed to be the National Industrial Security Program (NISP) Authorization Office (NAO) < http://www.dss.mil/isp/nao/nao_faqs.html>. If this was real, you’d think they’d use their current name.
But since it’s on dss.mil, I’ll presume it’s a real document, though perhaps not a final version. Its title page says that its “Effective Date” is “6 months from Revision” – around November 21, 2016. So if this is real, there’s a short fuse to fix it.
> Paragraphs of fun include 5.1.3, and 5.2.2, among others. Left as an exercise to the reader. Enjoy
I’ve extracted text below. The version I saw doesn’t say “open source software” specifically, so some of text Josh noted aren’t tehre. However, there are reasons to be concerned.
* 5.1.3: “The use of personal or public domain software is discouraged…”: This doesn’t significantly impact OSS, since public domain software (in the copyright sense) is very rare (less than 0.2% of all OSS around ten years ago, and it’s been going down since). This does mean that software developed by government employees, as part of their official duties, and later released can’t be used (since that IS public domain)… which is pretty silly. It’s an absurd requirement, though; there’s no justification given. This is probably a holdover from a misunderstanding of the now-obsolete DIACAP.
* 5.1.3: “Unclassified software that will eventually be used during classified processing periods must be developed by cleared, knowledgeable personnel or reviewed and/or tested by cleared, knowledgeable personnel. This includes operating systems, virus detection and software sanitization software.” – strictly read that’s ridiculous. Most commercial software (including operating systems and virus detection software) is NOT developed by cleared personnel. This would imply that Microsoft Windows, Red Hat Linux, Solaris, and anything else is forbidden. They mention Windows later, so I *think* they meant in context for this to apply only to DoD-developed custom software… they should fix that.
* 5.2.2 has the same issues; it seems to imply that you can’t use commercial software of any kind. I’m guessing that they *meant* for these requirements to apply to custom software. Is anyone certifying a line-by-line review of Windows source code? I doubt very much that the Common Criteria evaluations of Windows or GNU/Linux go to that level. I think what they meant, and what they wrote, are really different.
Can anyone find out if this is a draft, or the real thing? If it’s the real thing, this has real problems. If there’s a more recent draft (Josh’s?), there are more problems.
Anyone know more?
--- David A. Wheeler
===============================================
5.1.3 Software Protections
Software from unknown or questionable sources will not be used on classified information systems (IS). The use of personal or public domain software is discouraged and each installation of such software will be approved by the ISSM. From the earliest feasible time, all IS software will be stored on media that is safeguarded to the highest level of intended processing. Installation and modification of software will be performed by authorized personnel who are knowledgeable of the computer system and the software being installed. Software will only be loaded from media that is write-protected. Software will be screened and tested for malicious code or logic.
Unclassified software that will eventually be used during classified processing periods must be developed by cleared, knowledgeable personnel or reviewed and/or tested by cleared, knowledgeable personnel. This includes operating systems, virus detection and software sanitization software. The best method to safeguard is to develop the software on the classified system. If developing the software in an unclassified environment the ISSM must ensure uncleared persons are restricted from having the ability to access the software. This can be accomplished through strict control of file permissions. The ISSM must ensure that all users with access, including privileged administrators, have the appropriate clearance.
5.2.2 Unclassified Software Review
An unclassified software review and/or testing provides two options for examination of unclassified software prior to its introduction into the IS and use for classified processing; 1) the contractor may choose either a review or testing of the unclassified software, 2) an unclassified software review must be a line-by-line source code review. Unclassified software testing must include a validation of all functionality for security-relevant items. This includes security relevant software such as all OS software on an IS where I&A and/or auditing have been technically implemented, virus and malicious code detection and sanitization software, all security relevant information such as software and router tables, configuration settings, IS and OS documentation, audit data, etc. Security relevant hardware includes any hardware or IS component that contains, or has the potential of containing classified information as well as resolution of any discrepancies. For example, if the software writes to a file, the file must then be reviewed using a hexadecimal editor to ensure that only the intended information was written.
Unclassified software that will eventually be used during classified processing periods must be developed by cleared, knowledgeable personnel or reviewed and/or tested by cleared, knowledgeable personnel. The review and/or testing are done to provide reasonable assurance that security vulnerabilities do not exist
Kyle Harrigan
I'm sorry for the delay in responding. This is real for us, at least for now. You are correct that the ODAA is legacy as everyone moves to RMF. However, we are unclear how much of the spirit or language will be retained in policy by our local DSS office as we move to RMF.
One thing is for sure, we are seeing fairly significant policy modifications on our end, and they range from "bad" to "we can't do our jobs anymore."
Right now, we are being discouraged from using OSS consistent with that language. We must hand-compile anything we are bringing into the room (no pre-built RPMs). Every revision must be re-approved (even minor revs or bug fixes). There is a concept of a trusted vendor, but we don't know what the litmus test is for one or who is or isn't on the list.
It seems a lot of Redhat-related things are getting green-lighted automatically, which just makes the policy even more inconsistent.
One of the bigger issues is that, as you can see, basic definitions of OSS are being completely screwed up. I've floated out one of your briefings from a few years ago which addresses all of the classic misconceptions regarding OSS, with the DoD focus. No one seems to really care.
After looking at the org chart, it seems DSS has no official relationship with DoD CIO? True statement?
Guys, we need some serious help here.