CIA Software Developer Goes Open Source, Instead(wired.com)
wired.com
CIA Software Developer Goes Open Source, Instead
http://www.wired.com/dangerroom/2010/08/cia-software-developer-goes-open-source-instead/
2 comments
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).
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.
It's an interesting approach I've noticed in a certain kind of deployed-in-practice AI system--- rather than trying to solve the problem in an ideal correct sense (in the sense of statistics, decision theory, etc.), deploy systems that instead aim to just make sure the most obvious mistakes don't happen. The reasoning seems to be that if you keep people from making the 5 or 8 or 10 or whatever most common kinds of errors, you get a huge win for relatively little cost, whereas deploying a system that actually solves the problem fully is much harder. It also integrates more easily with the human decision processes--- a system that just says, "hey, have you thought of this pitfall?" is easier to get people to at least accept input from than a system that says, "AI has determined that the right answer is X".
Moreover, whenever you are searching a problem space there is not guarantee that a solution is optimal. All you have is this heuristic that it is good enough. This is quite acceptable if it's an industrial process, but when's people's lives are at stakes it gets harder to stomach. The what-ifs would still remain.
By the way, have you seen Palantir's solution? (see: http://www.palantirtech.com/) It's really, really interesting. It is described as a search based solution that shows the interconnections between data from different govt. databases and allows for real-time analysis. I wonder what it must be like to run it.
By the way, have you seen Palantir's solution? (see: http://www.palantirtech.com/) It's really, really interesting. It is described as a search based solution that shows the interconnections between data from different govt. databases and allows for real-time analysis. I wonder what it must be like to run it.
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.
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.
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.
[deleted](1)
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...
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.
https://www.cia.gov/library/center-for-the-study-of-intellig...
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."