Can we whitelist certain projects?

[ckaran]

There are certain projects where there is a strong belief that it will not violate any laws or regulations. Examples of this might be things like the C standard library. If there are projects within ARL that fall into this category, is it possible to whitelist them so that there is no need for OPSEC review on minor releases? Are there rules or regulations preventing this? If not, are there any process adjustments that would need to be made to make this possible?

[andrewgdunn]

A permanent pass-through and future bypass of OPSEC review would be essential for many of the projects we work on. The very nature of seeing OPSEC approval requires some legal weigh in on the payload, which would make development in the open significantly cumbersome.

Passing through a manuscript, which is human readable, can take days. Passing through a codebase, which is machine parse-able and not lawyer readable becomes a trust proxy type event that necessitates the internal legal council has both a relationship with, and bandwidth for, interacting with people who are at a significantly lower level of detail than what is typical for counsel interactions.

[ckaran]

This wouldn't be a complete drop of OPSEC; it is just for the minor reviews. That said, under ARL's policy there is only ONE person that has to read the complete code; the level-1 OPSEC officer. Everyone else reads the 1-2 page abstract as described here. If this is not clear in the policy, then that is a bug and I need to fix it. If you read through the whole document, what does it imply to you, that everyone needs to read the code, or only the level-1 OPSEC officer?

ARL's plan is that all developers will become level-1 OPSEC officers, and then this turns into a pair-programming exercise. If we get approval for the whitelisting part, then the pair-programming part will go away.

[fulldecent]

I like this recommendation from a license/patent review perspective. I am not a fan of this recommendation from an OPSEC perspective.

Issues:

• Who creates the whitelist?
• Is the person that puts glibc on the whitelist qualified to evaluate glibc?
• Is the level of review of glibc consistent with the amount of trust we put into it?
• Is the level of review of incremental changes to glibc consistent with the amount of trust we put into it?
• The whitelist will represent opportunities for the enemy to introduce malware that will have reduced level of review -- will the list be public?

Proposed solution:

(Maybe this is exactly what you were thinking but in different words.)

To reduce duplication of efforts, ARL will maintain a "preapproved list" of non-ARL projects. ARL OPSEC officers will perform identical review of this software as is performed for ARL public release (or maybe there is a stronger policy for internal, non-public projects). OPSEC officers may add their approval of a non-ARL project to this list by submitting to (some type of higher-level OPSEC officer):

• Positive identification of the project, version and files they are reviewing (hash)
• Statement of the level of involvement of their review
  • Did they consider the project as a whole or only the incremental changes?
  • Did they rely on statements by e.g. Google Zero or assurances made by other parties as to the security of the project?
• Statement of how the officer believes that the project is being used in other projects (impact analysis)
• Recommended classification level for their review (considering if they used any non-public techniques to perform their evaluation)
• Review outcome and caveats

Duplicate entries in the preapproved list are allowed and encouraged. This especially applies in different classification levels.

When an ARL OPSEC officer is evaluating a project for public release (and this policy may also apply for internal project OPSEC review) then that OPSEC officer may consider entries from the preapproved list.

Discussion

The information added to the preapproved list gives the OPSEC officer the information they need to become comfortable with, and trust, the other OPSEC officer's review of that project.

The list itself is sensitive and should probably not be published.

[ckaran]

@fulldecent actually, the purpose is to whitelist certain ARL initiated and controlled projects. For example, BRL-CAD is a very long running ARL Open Source project. It is already whitelisted, but this was done on an individual, special-case basis. There are likely to be a large number of similar projects that require only a reduced level of oversight. I want to know if there is a way of creating a process whereby project owners can request that their projects be whitelisted. I'm not sure if there is a way under current laws, regs, and rules though.

[andrewgdunn]

The use case I was chiming in about was more for things that we have an ultimate intent to do continued development out in the open. If all contributions have the intent to be benign/open/academic in nature, can there be a set of internal checklists for contributors so that their work can happen seamlessly without a cumbersome OPSEC process.

If I'm working on a project where we are trying to optimize something where the payload of the optimization should not be shared due to OPSEC concerns, but the implementation of the optimization strategy can be decoupled from the domain specific sensitive information... I'd like to move that work out in the open.

We also just have a bunch of benign projects that could easily pass a sniff test for sensitivity and be pushed in the open for continued development, but it would be cumbersome to work on them if we'd have to seek OPSEC approval for each commit.

[andrewgdunn]

Sorry, I never chimed back in for @ckaran about the level-1 OPSEC officer "hack". That actually would be aligned with what I was lamenting for above. It's a formalized transferal of trust to let the developer themselves review and release the work that they've been recognized to have some dominion over.

It'd be minimally cumbersome to facilitate individual enablement. I'd be in favor of a model like this.

[ckaran]

@storrgie OK, just so I'm clear, this means you're comfortable with the way minor reviews are setup right now, right? The way I see this happening is that all developers become level 1 OPSEC officers, and then they pair off so they can check each other's work. This should help catch bugs, and generally improve the quality of code as well, so it's not just for OPSEC.

That said, even this amount of OPSEC review is annoying, so if it's possible to do so legally, it may be worth it to drop it on certain whitelisted projects. That's all this issue was about originally.