Proposed change in DFARS: bad for us?

[Gunnar Hellekson]

Just ran across this article:

http://gcn.com/articles/2011/07/11/cybereye-box-dfars-reg.aspx

which links to this proposed rule:

http://www.gpo.gov/fdsys/pkg/FR-2011-06-29/pdf/2011-16399.pdf

Which appears to require contractors to put in place additional security protections for software and technical data even if they're unclassified. I don't totally understand it, but I fear this may hamper use and creation of open source in the DOD.

Does anyone understand the consequences of this?

g

[Miles Fidelman]

Sounds like a situation that could be very dangerous for both open
source development, and small businesses in general:
- creates yet another class of information that's not classified, but
has to be handled in special ways
- creates yet another situation where it might become very easy for
contracting officers to simply define everything as "critical program
information" (just like folks who mark everything FOUO)
- creates some serious sys admin burdens for small companies
- creates a general burden re. the free flow of information - with
particular impact on open source development

I plan to put in a comment to this effect. I suggest others do the same.

--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra

[Daniel Risacher]

My first take was that this was largely harmless, in that the Basic
controls seem to require that defense contractors take the same sorts
of reasonable precautions that DoD offices do - updated antivirus and
whatnot - and the "Enhanced Controls" require reporting of intrusion
and cyber events. This seems moderately reasonable.

But reading more deeply, I'm concerned. The controls *also* include
language that forbids posting "Government information" to the
Internet, and defines "government information" very broadly.
Enhancements to OSS, done under contract, would be "government
information" and could not be discussed on the internet, if I'm
reading this right.

> --
> 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
>

[cjturner]

Actually, they are quite clear and define "Government Information"
early in the proposed change. (Y)our (gov) customer is responsible
for labeling data/information in transit to (y)our facilities so that
you KNOW when you are on the hook. Simplistically put, things like
"UNCLASSIFIED//FOUO" on the docs.

Applicable references:
1) it is intended to implement Executive Order 13556 (Controlled
Unclassified Information)
Specifically, it defines that as:
2) Critical Program Information as per DoDI 5200.39
3) Critical Information as per DoDD 5205.02 (OPSEC)
4) Subject to ITAR controls.
5) Exempt from Mandatory Disclosure as per DoDD 5400.07
6) Anything with an access/distribution label: "(e.g., For Official
Use Only, Sensitive But Unclassified, Limited Distribution,
Proprietary, Originator Controlled, Law Enforcement Sensitive)" - to
me, this is an "Executive Summary," for those who don't want to read
this stuff. See my "simplistically" above....
7) Tech data with a distribution statement (other than "unlimited
public") as per DoDI 5230.24, or tech data as defined in DoDI 5230.25
(this document is VERY specific, and can be used to slice up your
"dual use" conundrums).
8) Personally Identifiable Data: Privacy Act, HIPAA

The OSS concern I see with this is the possibility that a contractor
would employ DFAR 27.4 sort of limitation on the government in their
contract when they were, in fact, using OSS to solve the requirement.
Not to say that it has not already been done.

[Thoma...@gtri.gatech.edu]

Although it is not a big change, it has a lot of repercussions for any
vendor who makes money by becoming a DoD contractor. If the do any
"development" as part of their contract, their development processes fall
under this proposed rule. On the surface it looks mostly benign, but
there are a few problems.

One of the big areas I see are Data at Rest (DAR)/Data in Transit (DIT)
encryption (DFARS 252.204-70YY). Very few people use DAR encryption
unless on a laptop. If DoD's DAR/DIT rules come into play (FIPS 140-2)
that eliminates a lot of OSS solutions which drives up costs. Plus
rebuilding all the contractor's internal workstations and servers (e-mail,
bug tracking, fileservers, SCM, wiki, etc.) that are used to discuss the
code and collaborate on documentation/training.

If they extend the protection to anything involving PII that's another can
of worms. I've been through two DoD PII drills and both eventually ended
with our CDRs decision to ignore the rules, but not until weeks of wasted
effort elapsed. You cannot conduct business if you have to treat anything
with PII as FOUO. Why would a security rule extend to PII and HIPAA
anyway?

The biggest concern would be how far does this reach. If a vendor who
develops/supports an OSS project has a contract with DoD, do all of their
operations fall under this rule, or only those that directly tie to their
DoD contract? Who makes that determination? Do they have to keep their
DoD work sequestered? Very few OSS shops work that way.

Tom Dunn, RHCE
Georgia Tech Research Institute <http://www.gtri.gatech.edu/>
Voice: (757) 514-1309
thoma...@gtri.gatech.edu

[Gunnar Hellekson]

Thanks to everyone for responding, it looks like there are a number of potential harms in the proposed rule change. Perhaps we should draft a response on behalf of Mil-OSS? Is that in our purview?

If folks aren't comfortable with that, I'd be happy to bring up the issue with Open Source for America.

g

[Kane McLean]

I would consider it within our purview. If both organizations were to respond, that's twice the opportunity to state the case.

Kane

[Jim Kinney]

So how does the luks drive encrytion fare in the new proposal. It works well except for requiring a password to boot a server.
Does the new proposal require the data to be encrypted on the disk for storage with the keys offline until data requested? I don't see a way to do that with file system unless it's all in a database.

[Boyd Fletcher]

You can store keys in the server's TPM and have them automatically unlocked if the trusted boot checks succeed. Not going to help you much if the box is stolen but does cause some malware and root kits to break.

Boyd Fletcher

M: 757.535.8190

O: 410.854.4064

E: boyd.f...@gmail.com

E: boyd.f...@us.army.mil

[Boyd Fletcher]

Not sure I agree with the potential harm in requiring dar/dit for all software. OSS has been able (albeit painfully so) to meet dit requirements with fips 140-2 crypto in OpenSSL.

There are very good security reasons for WDE and DAR. There should be no technical reason why OSS can't meet the requirements and I suspect OSS could probably improve on them.

Boyd Fletcher
M: 757.535.8190
O: 410.854.4064
E: boyd.f...@gmail.com
E: boyd.f...@us.army.mil

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Boyd Fletcher:
> no technical reason why OSS can't meet the [data-at-rest encryption]
requirements

Ay, there's the rub. How many years till there's no _official_ reason
why OSS can't meet the requirements?

[Gunnar Hellekson]

My thinking on this is still not perfectly clear, but my concern is less about raising the technical bar than the acquisition bar. For example, would an OSS project have to comply with some set of internal process controls in order to be used on a program?

I have a less strong secondary concern about the burden the proposed rules would impose on small firms, which OSS relies on heavily to enter the DOD market.

g

[John Scott III]

from a new member:

   Comment on Proposed Change in DFARS: Bad for us? The change is not bad for OSS if folks take the time to understand the policy behind it. For an example of interpretation and implementation, see California Institute of Technology 2011 Guidelines for Safeguarding Export Controlled Information as required by the DFARS http://www.imss.caltech.edu/cms.php?key=safeguarding-export-controlled-data IA has two components. Primary is the policy or rules governing content management. Secondary is the technology solutions that implement the policy in an automated systematic environment. The policy determines who is eligible to access what. The technology is neutral and incapable of recognizing undefined parameters such as when public release information crosses into the realm of controlled unclassified or classified information. DoD content management control policies are: DoDI 5200.1 DoD Information Security and Protection of Sensitive Compartmented Information. DoDD 5230.24 Distribution Statements on Technical Documents DoDI 5230.25 Withholding Unclassified Information from Public Release. DoDI 5230.29 Security and Policy Review for Public Release There are really three categories of protection CLASSIFIED: At one end of the spectrum is Classified which includes Confidential, Secret and Top Secret, the unauthorized disclosure could cause damage to national security as defined in Executive Order 13526, "Classified National Security Information" December 29 2009 . PUBLIC RELEASE: At the other end is Public Release which is unclassified information that “may be made available or sold to the public and foreign nationals companies, governments, including advisarial governments, and may be exported. [DoDD 5230.24 Distribution Statements on Technical Documents] Public Release information is approved for “ Public Disclosure” ; e.g., making technical data available without restricting its dissemination or use. [DoDD 5230.25 Withholding Unclassified Information from Public Release] and has been “ Cleared for Open Publication”; e.g. may be released without restriction by the originating component or authorized agent. [DoDI 5230.29 Security and Policy Review for Public Release]. This is the ONLY category of software that may be distributed to the broad OSS community and by definition is not export controlled. Also note that Public Release does not equal or mean "public domain" for intellectual property/copyright purposes. CONTROLLED UNCLASSIFIED: This is the in-between and more difficult category to manage. CUI is defined as information owned by, produced by or for, or under the control of the executive branch of the United States Government that is withheld from public release where disclosure would compromise legitimate interests, such as privacy, business proprietary information, law enforcement, export-control, etc. Safeguarding measures or limits on dissemination are required by statute, regulation or approved written agency policy. Note that FOUO is a CUI dissemination marking. It applies only to UNCLASSIFIED Information that may be exempt (no guarantee) from mandatory release to the public under the Freedom of Information Act (FOIA) exceptions. FOUO is an appropriate marking for working papers, predecisional drafts and other information which has not been through a public release review. Federal agencies have different policies for FOUO access and distribution, but generally authorize use within the Agency and between its officials, contractors, consultants, grantees and partners in the conduct of official business.

-----------------------------------------------------------

John Scott

 240.401.6574

< jms...@gmail.com >

http://powdermonkey.blogs.com

tweets @johnmscott

Have you joined MIL-OSS: 

http://mil-oss.org/

http://groups.google.com/group/mil-oss

WG 3 mtg in Atlanta August, 2011

[Gunnar Hellekson]

The clincher though, as I read it, is that the new rules apply to all the categories described below, *and*:

"...technical data, computer
software, and any other technical
information covered by DoD Directive
5230.24, Distribution Statements on
Technical Documents, at http://
www.dtic.mil/whs/directives/corres/pdf/
523024p.pdf, and DoD Directive
5230.25, Withholding of Unclassified
Technical Data from Public Disclosure,
at http://www.dtic.mil/whs/directives/
corres/pdf/523025p.pdf; or"

That's where the problem is. I think we're indifferent to the stuff that's classified or quasi-classified, like CUI. The trouble is when technical information more broadly is subject to these rules. I think. Any DAU graduates out there?

g

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

"a new member" said:
> Proposed Change in DFARS: Bad for us? The change is not bad for OSS if
> folks take the time to understand the policy behind it.

"A new member," I understand the different controls placed on
information, and some of the reasons why they exist. The original
article Gunnar brought up appears to say that the DoD wants to make sure
its contractors are following some of the same laws it has to. That's
not bad on its face.

The problem with the proposed change is that it changes the default
status of a piece of data held by a contractor (like a file full of
source code) from sharable to secret. Instead of having to prove that a
piece of data is a secret, one must prove that it isn't.

To guard a secret, it takes lots of time and money; but you can bill
those to the government. No risk. But to let a piece of data out, in
this culture, is a risk: what if it is a secret of some sort? The cost
of mitigating that risk seems to be incurred by the person who wants to
release the data, not the government. The residual risk, of accidentally
letting out a secret despite the process, is borne by the person or
group who wants to release the data, not by the government.

(To be clear, by "secrets" I mean controlled unclassified information,
not any kind of classified information.)

As a Linux admin on a military base, I've tracked down and fixed several
bugs in open-source software, and tried to send them back to the
authors. In trying to do that, I've seen first-hand what a hindrance
this policy can be to open-source software in particular. I wouldn't
even think about hosting an open-source project from here.

Security incidents are reported and counted, and the costs estimated,
but who in the DoD counts the cost of lost collaboration and buggy
software?

[Gunnar Hellekson]

Well said. So the first problem is that any technical data subject to 5230.24 and 5230.25 falls under the proposed rules. I see that in 5230.25, section 2.2.3 (http://www.dtic.mil/whs/directives/corres/pdf/523025p.pdf):

" Does not introduce any additional controls on the dissemination of
technical data by private enterprises or individuals beyond those specified by export
control laws and regulations or in contracts or other mutual agreements, including
certifications made pursuant to paragraph 3.2., below. Accordingly, the mere fact that the
Department of Defense may possess such data does not in itself provide a basis for
control of such data pursuant to this Directive. "

So any software that originated outside DOD seems exempt. A small business or OSS project would only have to worry about the new rules if they're handling CUI data or export controlled for some other reason, and that makes perfect sense to me.

But for software written in-house, it looks to be a different story, as Jared points out.

> Security incidents are reported and counted, and the costs estimated,
> but who in the DoD counts the cost of lost collaboration and buggy
> software?

I wish I knew.

g

[B.Klein]

For the genesis of the DFARS change: See

Directive-Type Memorandum (DTM) 08-027
Security of Unclassified DoD. Information on Non-DoD Information
Systems, July 31, 2009
www.dtic.mil/whs/directives/corres/pdf/DTM-08-027.pdf


DON CIO
DTM 08-027 Frequently Asked Questions
http://www.doncio.navy.mil/ContentView.aspx?ID=1313


This policy applies to software and tech data that is produced by or
for the Department of Defense.

Contractors generally come to possess CUI tech data if it is (1)
government furnished in performance of a contract or if (2) created by
them under government contract. Although a contractor may make a
recommendation, the government sponsor has the inherently governmental
responsibility for determining classification and controls for its
tech data. This determination is based on a number of considerations
including but not limited to: public release security review; export
controls; intellectual property and government data rights licenses.
Multiple reasons for control may apply and may have different
enforcement times. Protected tech data must be marked with the
appropriate notices and legends to advise or warn recipients and users
of the data of its nature, purpose, origin and of the conditions for
release and disclosure without additional approvals by the government
sponsor or controlling office.

What that means is that contractors should not have to guess, but
should look for and abide by the markings on the tech data. And
everyone needs to be aware of those caveats that carry legal penalties
and fines; e.g -- export control, PII and infringement of proprietary
rights. If the information is not marked, do not assume it is
"approved for public release" or decide on your own. Ask the
government sponsor to live up to their responsibility.

bgk

On Aug 2, 4:42 pm, Gunnar Hellekson <gunnar.hellek...@gmail.com>
wrote:

[Gunnar Hellekson]

Thanks for the writeup, bgk. That's very helpful.

So you don't see a chilling effect on gov-produced OSS in these new regs?

g