Category Archives: work

What needs an ATO? (Update)

In 2013, I wrote a post that traced the definitions in DoD policy on what things need an ATO (then Approval-To-Operate, now known as Authorization-to-Operate).  Since that time, much policy has been reissued, so here’s an update:

DoD Instruction 8510.01 (Change 2, July 28, 2017) “Risk Management Framework (RMF) for DoD Information Technology (IT)”, says “Each DoD IS, DoD partnered system, and PIT system must have an authorizing official (AO) responsible for authorizing the system’s operation based on achieving and maintaining an acceptable risk posture.”

“DoD IS”, above, is a DoD “Information System”.  The glossary section of 8510.01 says “Information System” is defined in CNSS Instruction 4009, “Committee on National Security Systems (CNSS) Glossary”:  “Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information.”

This doesn’t help, in terms of determining what doesn’t need an ATO.  However, DoD Instruction 8500.01, “Cybersecurity”, says this:

(a) DoD ISs are typically organized in one of two forms:

1. Enclave
2. Major Application (Formerly Automated Information System Application)

a. Certain applications, because of the information in them, require special management oversight due to the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application and should be treated as major applications. A major application may be a single software application (e.g., integrated consumable items support); multiple software applications that are related to a single mission (e.g., payroll or personnel); or a combination of software and hardware performing a specific support function across a range of missions (e.g., Global Command and Control System, Defense Enrollment Eligibility Reporting System). 

b. Major applications include any application that is a product or deliverable of an Acquisition Category I through III program as defined in Enclosure 3 of Reference (av). When operationally feasible all new major applications will be hosted in a Defense Enterprise Computing Center. c. All applications, regardless of whether they rise to the level of major application or not, require an appropriate level of protection. Adequate security for other than major applications may be provided by security of the environment in which they operate. d. When possible, capabilities should be developed as applications hosted in existing authorized computing environments (i.e., enclaves) rather than designated as major applications requiring new and separate authorizations. e. DoD Component CIOs will resolve disputes regarding whether an application rises to the level of a major application. 

c. All applications, regardless of whether they rise to the level of major application or not, require an appropriate level of protection. Adequate security for other than major applications may be provided by security of the environment in which they operate.

d. When possible, capabilities should be developed as applications hosted in existing authorized computing environments (i.e., enclaves) rather than designated as major applications requiring new and separate authorizations.

e. DoD Component CIOs will resolve disputes regarding whether an application rises to the level of a major application.

Galaxy Chart in D3

When I first started working in for the Deputy CIO for Business Process & Systems Review, I was exposed to a data visualization called a “galaxy chart“. The version I saw was developed by Technomics, Inc., who (interestingly) do a lot of work for my former organization, PA&E (now CAPE).

While Technomics seemed to claim (when I met them) that they “invented” the galaxy chart, I think this is probably an overstatement, since there seems to be plenty of prior art.

Anyhow, I built a D3 plugin for a galaxy-chart layout.

Example galaxy chart

Example galaxy chart displaying a view of the United States Federal Budget for Fiscal Year 2011

How to apply an Open Source License to a US Government Work

This article is also posted to my Intelink blog.


Every so often, a government project manager asks me a question like this:

I’m looking to hire some government guys and I’m interested in young folks hacking on [my project].

So, here’s my predicament:  if they work on the code, their work becomes ‘public domain’ and not something that could be restricted by licenses (at least according to some legal advice I’ve been given).  If the work is the in public domain, I have no way of ensuring that someone won’t take the code and sell it back to the government as their own (because they could modify it and put a proprietary seal on it).

Here’s my question: is there some legal structures that can be put in place to restrict modification, use and distribution like typical software licenses for government-created works?

Here’s some ways this has been done before. Continue reading

Hellekson’s Law: How did I do?

This article is also posted to my Intelink blog.


I learned the other day about Hellekson’s Law, which states that more specific policy can be improved for the general case by removing delimiters that narrow the policy scope.

In particular, the thought was originally formulated with respect to government policies regarding Open Source Software: if there is an agency policy about open source software, then it could be improved by removing the words “open source”.  Whatever policy statement applies to open source software, probably applies to software in general.

This makes sense to me… although I suspect that it doesn’t apply in all cases.  Sometimes there may be specific statements that apply uniquely to open source software, specifically because of it’s open-sourciness.  As the original author of the Department of Defense policy statement on open source software, I’m intrigued:  how did I do?

Let’s analyze the policy/guidance section of the DoD memo and see if it articulates policy that should apply to all software, not just OSS:
Continue reading

…the hope that Congress will recognize a “moral obligation”…

This article is also cross-posted to my intelink blog.


Part of the Antideficiency Act (codified at 31 U.S.C. § 1342) reads as follows:

An officer or employee of the United States Government or of the District of Columbia government may not accept voluntary services for either government or employ personal services exceeding that authorized by law except for emergencies involving the safety of human life or the protection of property. . . .

I have heard this admonition at various times in the context of Open Source Software: if the government cannot accept “voluntary services”, then presumably it cannot allow people to volunteer to write open-source software for the government. Maybe it can’t even use open source software, since it was either written by volunteers or at least licensed for use voluntarily…?

These concerns are, of course, completely wrong, as I will endeavor to show:
Continue reading

They vs. We

A colleague recently said to me:

There is no “they.”
There is only “we.”

There is no “them.”
There is only “us.”