
CIA Software Developer Goes Open Source, Instead - iamelgringo
http://www.wired.com/dangerroom/2010/08/cia-software-developer-goes-open-source-instead/
======
notaddicted
If you follow a few links you'll end up here:

[https://www.cia.gov/library/center-for-the-study-of-
intellig...](https://www.cia.gov/library/center-for-the-study-of-
intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-
analysis/art11.html)

This is the chapter on Analysis of Competing Hypotheses in Richard Heuer's
book Psychology of Intelligence Analysis.

"Analysis of competing hypotheses, sometimes abbreviated ACH, is a tool to aid
judgment on important issues requiring careful weighing of alternative
explanations or conclusions. It helps an analyst overcome, or at least
minimize, some of the cognitive limitations that make prescient intelligence
analysis so difficult to achieve.

ACH is an eight-step procedure grounded in basic insights from cognitive
psychology, decision analysis, and the scientific method. It is a surprisingly
effective, proven process that helps analysts avoid common analytic pitfalls.
Because of its thoroughness, it is particularly appropriate for controversial
issues when analysts want to leave an audit trail to show what they considered
and how they arrived at their judgment."

~~~
whatwhat
Also check out the book "The Thinker's Toolkit" by Morgan Jones. He was a
former CIA analyst. It contains 14 different analytical tools in the book that
were taught to CIA analysts (including an extensive discussion on testing
hypotheses).

~~~
notaddicted
Thanks for the suggestion. I started the book this weekend and I'm 100 pages
in. What I've seen so far isn't necessarily impressive, but there are some
good common-sense techniques.

------
aswanson
I've consulted for dod contractors and have witnessed such stupidity as buying
a half -written ipv6 stack from a vendor rather than taking it from the Linux
codebase because 'a foreigner may have touched that code.' Never mind the fact
that the vendor was free to hire foreigners. Or that Linux is already used by
dod. Or that the vendor is clueless and charging you out the ass.

~~~
tptacek
It's no doubt a very clumsily-executed policy that has a net effect of
decreasing the quality and increasing the cost of all software DoD buys, but
"a foreigner touched it" is not a crazy security control. You wouldn't
necessarily know just by looking at the code whether it it fatally compromised
security, and the IP stack is among the more security critical components of
the system.

Please don't take this comment the wrong way. Can DoD meaningfully control for
this risk? No. What they're doing is no doubt stupid and unhelpful. But the
original notion, that maybe "foreigners" shouldn't be touching the IPv6 stack
of something DoD depends on, is valid.

~~~
jrockway
It's probably more likely, though, that bugs are introduced by Good Old
Americans that are simply incompetent. If only the government had a policy
about not hiring incompetent people...

~~~
tptacek
Agreed. The US may have the right idea regarding not adopting foreign-tainted
code, but they don't have the stones to follow up on the other half of the
policy, which is "we're not allowed to run any code whose origin isn't
traceable and that hasn't been validated line-by-line and in simulated fault
injection by NSA". They want to have it both ways; the might as well just
contract the crypto engine out to China.

