I support Wim Remes for ISC(2) Board of Directors. I agree with his vision for the organization and his views on infosec in general. If you do too, follow the directions on his page to have him placed on the ballot for election.
Do this soon as the deadline for him to submit is September 19th, 2011. In fact, do it by the 18th so that there is no confusion.
That is all.
Hi. I'm Chris and I'm an AWS addict. <Crowd>Hi Chris</Crowd>
That's right, I am using an EC2 as a development platform for RedSpartan as a code repository, wiki and issue tracker (in the form of a RedMine instance). I am also using a Windows instance to host the development and alpha instances of the tool itself. *gasp*
I am telling you this because I am totally confident in my ability to encrypt the sensitive information in the database and on the file system. I also feel that I have created an environment for my application to run where (if even Amazon were to fail at protecting my instance) that an attacker would have limited success in capturing any data.
I use AWS because the VM is mine to manage. I deploy patches. I install software. I configure the firewall. I take images when I want. When I want a restore, I get one. I want a reboot, the box is rebooted.
The downside: It is mine to screw up. But I do not fear because I have been managing servers for nearly 15 years.
I don't want this to end up sounding like a sales pitch for RedSpartan, my professional services or AWS. However, virtual machines, cloud and XaaS is the future of enterprise computing. As a result, I feel that applications need to be built in a robust manner. Does this mean that I spent extra time on reducing my vulnerability count? Yes. Does it mean that I scrapped many, many lines of code because I architected it incorrectly? Yes. Does it mean that I am a paranoid, crazy person? Perhaps.
The point I am trying to make is that you can put your data and applications anywhere (like AWS) but it still needs to be protected. As part of Amazon's recent announcement that they can comply with FISMA in their new government region, there is still significant work to ensure that data is protected. I don't know anything about the controls in place at Amazon, but I will say that nowhere is 800-53 mentioned in their press release or the baseline they expect to meet. They also mention SAS 70, which to my knowledge is being sunset in favor of SSAE 16. This tells me that Amazon is not wholly up to date on what is happening in the compliance space. Given that ITAR is mentioned 3 times, I think that this is more about ensuring that the government's data is in Northern Virginia or California (or both).
A friend of mine said that he recently worked on an authorization package that was not in the GovCloud region but that was hosted with Amazon. His words where something like: Amazon's crap is wired and their kung fu is strong. I believe him. But I would also not document controls for Amazon, I would mark them as inherited and put them on the hook via their own SSP. I expect by now that Amazon would have a standard SSP with the controls they are providing with all the usual things that go into an SSP. That way they aren't reinventing the wheel for each new Federal customer.
So I say: Cloud it up govies. But do it in a way that protects the government, citizens and whoever you are keeping files on.
I did not get a chance to read 800-128 during the draft phase, mainly because I was too busy. But also because I wasn't all that worried. I did however have one of the analyst I work with read it and he had some positive things to say. So if this comes across as not news to you or something akin to a 12 year old girl saying "Duh!", then please excuse me for just now catching up.
Pros (in no particular order):
A consolidated place for information on Configuration Management.
Control References - in section 2.3 there is a description of the activity to be performed and THEN the control reference.
The Appendices.
Very Nearly The Holy Grail of Federal IT Systems Compliance (keep reading).
Cons (also in no particular order):
The introduction of Security-Focused Configuration Management (SecCM).
Tries to make it an organizational problem with limited dealings when it pertains to system.
Limited to no mention of outsourced systems OR how to handle "cloud" environments.
This document contains how configuration management should be done in and around the Federal government. This has been needed for a long time, especially since many places do configuration management incorrectly and/or half-assed. Some of which rely on the 800-53 controls as their implementation guide. But the document does mention SDLC in the document with pointers to things like 800-64.
If you do not know what you are doing, or simply want some place to start, then 800-128 is for you. If you have a decent program or want some tips on how to improve it; I don't know that you'll find any of the answers that you seek in 800-128. It will not fix personality problems with co-workers, but there are some explicit recommendations that you could use as a bat to beat them with.
The key point that NIST is driving here is the SecCM concept. SP 800-128 is not "transforming" configuration management but (as the name implies) wants everything relating to configuration management to be security centric. This may conflict with those who believe that configuration management is all about making it easy for IT administrators and developers. Especially if the security and operations staff don't get along with each other. I think it would be best to continue selling it as a performance and efficiency enhancement, while reaping the rewards of better documentation and system configuration monitoring.
What you will find is some decent appendices that have templates for a Configuration Management Plan and a Security Impact Analysis. Two things that desperately need consistency between departments and agencies. Some people may find the work-flows in Appendix G somewhat helpful for visual learners. However, Appendix F is the least helpful in that it regurgitates everything we know about securing a system and points you to a number of the other 800-series documents.
You may remember from above that I mentioned that you may find the Holy Grail of Federal IT Systems Compliance in this document. No it is not, "The Definitive Guide on How to Establish an Authorization Boundary". Attachment 1 (part of the SIA template - not even in the Table of Contents) at the very end of 800-128 has 10 questions that ask whomever is filling out the SIA template to identify the significance of a change. I believe that it is a worksheet that concisely identifies whether a change is significant enough to require a re-authorization event. Which is kind of a big deal. This is in fact my version of trumpeting it from the mountain tops. I think that it will need to be customized to the individual agency or department that is using it. Also, PLEASE let me know if you have seen this gem before and I have just missed it.
Now for the bad news. The document is almost fanatical about the need for something to come from the organization (Section 3.1.1) as it should be. The problem is that with service purchases, outsourced systems and clouded systems, there really isn't a super way to have software run on those components for it to report back to the mother ship. This is the part where you say: "Chris, I can just upload my SCAP results at the end of the month". OK, fine you got me. Have your junior squirrels or security monitoring staff upload some properly formatted XML results every month or setup a scheduled job to do it for you. My experience is that sending that level of granularity to an agency or department leads to information overload OR having to track and approve many, many waivers and exceptions. That isn't to say that you shouldn't try. I would say that there may be pieces of what 800-128 puts on the organization that needs to be pushed to the system or that things that are the system's responsibility need to be addressed by the organization.
I think that it is also a little naive to expect that the SIA is going to be conducted in the manner described in Section 3.3.3 given the release cycle of some systems (especially those that are behind or late).
Lastly, it wouldn't be a NIST document if there weren't an allusion to the use of software tools to improve efficiency. This one is no exception. SCAP would be nothing without scanning and assessing tools, but tools are not going to fix the problem. Without a clearly defined policy -> procedure -> process -> document trail, then you are trying to row upstream on a quickly moving river. On larger systems, tools definitely need to be used. That doesn't mean that you need to stand up something separate from what operations is doing to manage the systems.
As always, 800-series documents are recommendations not requirements. Develop your processes in a way that works for where you are and build in tools and technology around it. But the 800-128 is very good at helping with the bulk of the work that Continuous Monitoring is trying to accomplish.
