{"id":187,"date":"2013-02-25T17:17:52","date_gmt":"2013-02-25T22:17:52","guid":{"rendered":"https:\/\/risacher.org\/jfdi\/?p=187"},"modified":"2013-03-04T12:56:02","modified_gmt":"2013-03-04T17:56:02","slug":"the-90s-called-they-want-their-ca-process-back","status":"publish","type":"post","link":"https:\/\/risacher.org\/jfdi\/2013\/02\/the-90s-called-they-want-their-ca-process-back\/","title":{"rendered":"The ’90s called, they want their C&A process back"},"content":{"rendered":"

\"michael-douglas-wall-street\"<\/a>[This is mirrored on Intelink-U<\/a>]<\/em><\/p>\n

In a previous post<\/a>, I traced through the various policy documents that describe the certification and accreditation processes for the Department of Defense, ultimately tracing back to OMB Circular A-130<\/a>.\u00a0 In summary, “systems” need accreditation, while “applications” do not, and the distinction (per A-130) turns on the highly subjective decision of whether it is a “major” application.<\/p>\n

In tracing this definitional tangle, I unwittingly provided a roadmap for how to get your system<\/del> “application” on a DoD network without a full-blown Approval To Operate (ATO).\u00a0 I was not<\/em> trying to\u00a0 provide an easy-out for getting operational without being accredited … although the method is a well-trodden path with a lot of history.\u00a0 I’m was <\/em>trying to show that our C&A policy is at-least-slightly broken, and we generally don’t even understand it ourselves.<\/p>\n

Again, to summarize, this is what not<\/em> to do:\u00a0 since network enclaves are “systems”, (which do<\/em> require accreditation) you find a network that is already accredited.\u00a0 You then host your system<\/del> application on that enclave, which generally means annotating the presence of your “application” in the security documentation for that network enclave.\u00a0 In many cases, this also means going through an “Approval To Connect” (ATC) process, which is generally defined by the owner\/operator of that network enclave.\u00a0 This is\u00a0 easier than a full ATO.\u00a0 If anyone ever asks questions, such as, “Do you have an ATO?” or “Who is your DAA?”\u00a0 You gleefully point to the Enclave ATO and the Enclave DAA, and say “Yep, right there.”<\/p>\n

A friend of mine (Hi, Alex) characterized this as “weasely.”\u00a0 Okay.\u00a0 Perhaps.<\/p>\n

When I became the IT Operations guy for the Office of the Director for Program Analysis & Evaluation<\/a> – now Cost Analysis & Program Evaluation (CAPE) – I inherited many such systems<\/del> applications.\u00a0 I was responsible for hosting all the web-based “applications” that are used to collect the long-range budget proposals for the DoD (the POM), the data-warehousing and business intelligence tools used to analyze that data, and collection and reporting tools for ancillary reporting data.\u00a0 None of these systems<\/del> applications had their own ATO – but the network enclave did.\u00a0 In my opinion, they all should<\/em> have had an ATO, but it was impossible to make this happen.\u00a0 As the hosting provider, I couldn’t write the SSAA for the system<\/del> application owners (because I didn’t have the information necessary), and I couldn’t simply disconnect the application servers without hosing over my own customers.<\/p>\n

Later, when I was responsible for something called the “DoD Storefront” project, I tried hard to get my system accredited.\u00a0 We were writing the SSAA, registering in VMS, eMASS…\u00a0 I wrote the designation memo to get my SES designated as the DAA, signed him up for DAA training, etc.\u00a0 The designation memo was to be signed by my boss’s boss – the DoD Deputy CIO, Mr. Dave Wennergren.\u00a0 I never got that far.<\/p>\n

I got stopped by Wennergren’s deputy – who asserted, “Why do you need an ATO?\u00a0 This isn’t really a ‘system’.\u00a0 I think it’s just an application.\u00a0 Go talk to the Director of the DIAP<\/a>(*) and see what she thinks.”\u00a0 (* Defense-Wide Information Assurance Program)<\/p>\n

So I march off to talk to the Director of the DIAP.\u00a0 She asks me a few questions.\u00a0 One of the first questions she asks is: “Are you buying any servers?”<\/p>\n

I say, “Of course not!\u00a0 Why, in the name of history, would I do that?!?\u00a0 That’s datacenter stuff.\u00a0 I mean, there will be servers – but I’m<\/em> not gonna buy them.\u00a0 If I bought servers, where would I put them?\u00a0 I just want to be hosted somewhere.\u00a0 Datacenter guys buy the servers.”<\/p>\n

This puzzles her.\u00a0 She thinks for a moment and says, “You sound like you know how the world actually works.”\u00a0 This puzzles me…\u00a0 I’m not sure what to say about that: “I don’t know about that, ma’am.\u00a0 I’m just trying to get my system on the net.”<\/p>\n

She asks, “Could you go talk to Eustace King?\u00a0 He works for me.\u00a0 He’s responsible for re-writing the instruction on DIACAP.\u00a0 I’m a little concerned he doesn’t know how the world really works.”<\/p>\n

Which is how I ended up having a 2-hour long conversation with the author\/editor of DIACAP – which I’ve partly described elsewhere<\/a>.\u00a0 Long-story-short, even though I really believed I needed an ATO – the author of DoDI 8510.01 told me Storefront was “just an application.”\u00a0 (With seven servers, it’s own firewalls, accessible to the entire Internet.)\u00a0 Suffice it to say, near the end of the conversation, I said something like, “You know, the world keeps on changing…”, and Eustace sighed, “Yeah, and I wish it wouldn’t.”<\/p>\n

Both the conversation with Eustace and the text of OMB Circular A-130 led me to believe that many of our C&A concepts are rooted in an outdated view of how IT systems work.\u00a0 We expect “small systems” to be on a “LAN” and therefore low risk – and so the “enclave” will protect them.\u00a0 In the age of cloud computing and the web, this view is almost totally nonsensical.\u00a0 The problems with this approach go both ways – we over-protect some things, and under-protect others.\u00a0 In a “LAN mentality”, protecting the network boundary is really important, because the LAN is assumed “soft on the inside”, and we (reasonably) assume that if bad actors compromise one system, the whole network is compromised.\u00a0 But in the age of the “cloudy web”, we actually know how to isolate systems with significant efficacy.\u00a0 A well-designed DMZ isolates systems from the business network as well as from each other.\u00a0 On the other hand, being hosted on a secure “enclave” is meaningless if the firewall is configured to allow access from the entire enterprise, or worse, the entire Internet.<\/p>\n

Likewise, our C&A processes don’t seem to have much provision for division of responsibility … an infrastructure service provider can be responsible for the security of the infrastructure, and the application service provider responsible for the application, but we require the ATO to address end-to-end risk.\u00a0 Hence the question, “Are you buying any servers?”\u00a0\u00a0 In the old days, if you were fielding a system, you would be buying servers… maybe routers, switches and firewalls too.\u00a0 Those things are commoditized today – the datacenter operator does not want your non-standard server that doesn’t fit in his racks or with his management software, and as an app provider, you don’t want to worry about that cruft.\u00a0\u00a0\u00a0 I do not want to ever know or care what kind of physical server my apps run on.\u00a0 (I’ve done that. It sucks.)<\/p>\n

In some future post, I’ll try to lay out a few of my ideas of how the policy should<\/em> work.<\/p>\n","protected":false},"excerpt":{"rendered":"

[This is mirrored on Intelink-U] In a previous post, I traced through the various policy documents that describe the certification and accreditation processes for the Department of Defense, ultimately tracing back to OMB Circular A-130.\u00a0 In summary, “systems” need accreditation, while “applications” do not, and the distinction (per A-130) turns on the highly subjective decision […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,5,12],"tags":[],"class_list":["post-187","post","type-post","status-publish","format-standard","hentry","category-ca","category-it","category-work"],"_links":{"self":[{"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/posts\/187","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/comments?post=187"}],"version-history":[{"count":26,"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/posts\/187\/revisions"}],"predecessor-version":[{"id":285,"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/posts\/187\/revisions\/285"}],"wp:attachment":[{"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/media?parent=187"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/categories?post=187"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/risacher.org\/jfdi\/wp-json\/wp\/v2\/tags?post=187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}