This Week in Gov't Computing

And by this week I mean today, yesterday and part of last week.

It has been exciting though. Agency CIOs will now be required to report to OMB via CyberScope by November 15th. This is all laid out in Memoranda 10-15. My take away: Significant weaknesses don't need to be reported. WTF is that? You have to maintain it on file of course, so that you can provide it upon request.

CIOs are going to report the following:

• Inventory
• Systems and Services
• Hardware
• Software
• External Connections
• Security Training and
• Identity Management and Access

That's super, right? There's instructions available here. Eventually, Vivek and Howard want it all in an Excel spreadsheet or XML format and then uploaded. You'll need to submit it monthly starting in January 2011. Sounds to me like someone has bought into the SANS Critical Consensus Whatever. But we know how I feel about that one already.

IGs will also need to report through the old system but on this set of categories:

• Certification and Accreditation
• Configuration Management
• Security Incident Management
• Security Training
• Remediation/Plans of Actions and Milestones
• Remote Access
• Identity Management
• Continuous Monitoring
• Contractor Oversight
• Contingency Planning

I'm not saying that the old process didn't need to be overhauled, but here again the Feds are moving away from a risk-based approach to control monitoring. Bejtlich seems to agree.

In other news, my Dad's agency (Bureau of Engraving and Printing) has had their web site HACKED! OMFG!

Oh wait, not so much. More on it at the Register and the AVG blog. Most importantly, Dad doesn't work on the external web site or in IT for that matter.

The first thing to consider is that the BEP external web site probably got a Low baseline assigned to it. It has also been reported in the Register article that it may be related to the Network Solutions Wordpress hacks of last month. Could very well be, but let us remember that someone should have run a pen test. If they did run a pen test, well then may be its time for a new testing vendor. Panda gives a detailed breakdown.

This is the kind of thing that doesn't inspire confidence in the government's ability to protect information. And while there isn't any data leakage or loss from the site itself, the A portion of CIA has fallen down severely. The web site is still off line as of May 4th, 2010 at 21:45 GMT.

Lastly, there is a new GAO report out on the Federal Housing Finance Agency say that the info sec controls could be better. This is important because FHFA is the agency that: "... regulates Fannie Mae, Freddie Mac and the 12 Federal Home Loan Banks." So that's what's happening there.

Federal Gov hearts Cloud Computing (maybe)

And by maybe, I mean if the new Obama pick for the new E-Gov person is confirmed.

I am a regular reader of Christofer Hoff over at Rational Suvivability and have been convinced that Cloud Computing is almost as evil as Dick Cheney.

Which is why this article on Obama's pick for E-Gov chief has me more than a little worried. The article spends a few paragraphs near the end talking about moving information "into the Cloud".

Cloud Computing is not a good idea, unless the government can build its own Cloud. This would involve the entire government knowing who owns and operates the infrastructure (probably GSA). In a perfect world, it would be like the ultimate General Support System (GSS, see the 800-37 [pdf]). All the agencies would sign MOUs and SLAs. They would use common APIs and there would be coding standards. Regular security checks and web application assessments. Oh the glory of it all!

But this isn't what will happen, one or many agencies will get pissed, take their ball and go home. They'll stand up their own solutions with the help of a prime and 500 sub contractors.

A single infrastructure would help some of the initiatives that are underway. Like Trusted Internet Connections, enforcement of policies on end point systems, encrypted off-site backups, IPv6, among others.

So that's something, but the risk is not worth the reward. A single infrastructure means that the whole government could be out when a targeted attack is underway. Or that a simple misconfiguration could lead to what Google faced with its badware miscategorization. How to design to be redundant and available? Would there need to be one for classified and unclassified? Who's going to support incidents? All the usual questions that go along with a shared infrastructure.

So I don't know, I would love to put applications onto a common supportable infrastructure and have the government save a crap load of money. On the other hand, doing it correctly will take years or decades to implement and there is no guarantee that everyone will be on board.

But to even get started, the current government guidance and regulations aren't clear on the best ways to execute a cloud implementation. The new 800-37 was supposed to address this, but there doesn't seem to be any clarity there. If data is shared between two agencies on the common platform (and they both make edits), who will own the data. Lastly, there are some agencies out there trying to get an HTML page with an email address secured, let alone putting all OUR data across the Internet over a VPN.

They are going to do what ever they want though, because the appearance of competent financial management outweighs competent security practices. Until there's an incident.

OMB Memo 08-22

It is about FDCC compliance, which and it offers no new content for me. I am also a day or two late.

http://www.whitehouse.gov/omb/memoranda/fy2008/m08-22.pdf

The interesting part is on page 4:

Revised Part 39 of the Federal Acquisition Regulation (FAR) On February 28, 2008, revised Part 39 of the Federal Acquisition Regulation (FAR) was published which reads:
PART 39-ACQUISITION OF INFORMATION TECHNOLOGY
1. The authority citation for 48 CFR part 39 continues to read as follows: Authority: 40 U.S.C. 121(c); 10U.S.C. chapter 137; and 42 U.S.C. 2473(c).
2. Amend section 39.101 by revising paragraph (d) to read as follows:
39.101 Policy.
* * * * *
(d) In acquiring information technology, agencies shall include the appropriate IT security policies and requirements, including use of common security configurations available from the NIST's website at http://checklists.nist.gov. Agency contracting officers should consult with the requiring official to ensure the appropriate standards are incorporated.

I think that this has been implied for quite some time, but this is the first time that I have personally taken notice of it. Take note of the first four words in the paragraph "In acquiring information technology". Not software, not hardware, that's everything. Outsourcers, be prepared!

In other events, the C5 auditing platform by Secure Elements has built in some functionality to be "green", and that isn't President Management Agenda green - it is TreeHugger green. For which I am happy. Why? I compost, I recycle, I garden organic and I have TerraPass for 25 tons of carbon per year to offset the cars and house. I bought a laptop based on its energy rating, all my lightbulbs are CFLs and I am currently on a quest to reduce my vampire power consumption. So yea!

That's all I have for now.

The part where my dreams come true

Today was not expected to be extraordinary. A day trip to New York yesterday, a little sleeping in today, and then I was provided with this gem. M08-21

On the surface it is really nothing; the same memo that comes out every year that tells the agencies how they need to do their FISMA reporting. I then came to page 13 (13 by page numbers, page 16 by adobe).

Question 35: Must Government contractors abide by FISMA requirements?

The short answer: yes. Which is what I said previously. You be the judge though.

My read is that if you process, store or use privileged Federal information then you must certify the system. This means everything. You can't hide behind "its too hard" or "its in the cloud" or my personal favorite "its our equipment".

It does also say that you can share certification packages for agencies using the same system. What a novel idea! An idea I had two years ago. I have witnesses.

I would say this, if you intend to work with the Federal government, certify your systems or at be least prepared. What does this mean? I will give you a plan.

• Review your corporate policies - Are they up to date? Are they crap? Probably. Recommend changes, gain input from people who need to use it. Get buy-in from people who matter.
  
• Compare and trace your policies and procedures to 800-53 and relevant guidance - Match your proprietary policies to the 800-53. Does the 800-53 have controls that your policies don't address? Do your procedures contradict Federal guidelines? i.e. Your desktop configurations or images are not even close to the FDCC settings, event logs settings don't line up to 800-92 recommendations, etc.
• Roll changes - Now you know where you are and with input where you will be going. Break up control implementation into short term and long term goals (upgrade tape libraries, schedule incident response and contingency drills, annual refresher training buying some of those crazy posters of reminding people they should be secure, etc).
  

Now what? By this point, you have started writing a comment that tells me I am crazy. I am. But I am not wrong either. Now you can launch into creating a generic Certification package for your system that is based on your corporate policy. At this point, you can't know which agencies your sales guy is going to bring back. But at least know what you have and the package you create is the one that your organization can live with.

Now you have to start acting like you are running Federal data. Sticking to the SSP, conducting risk assessments, following your configuration management plan, etc. Because the govies can now show up, look you over, maybe conduct their own audit and sign off on your package.

They may not like what your package says, they always find something. You will need to convince the Authorizing Official to accept some findings. The hope is that these are simple policy and procedures deviations between yours and theirs. You may find a hard ass that wants to document a finding when your policy is stronger than theirs. It happens.

But at least it is one package, not three with a bunch of inconsistencies. And then having to run three different incident response drills for three customers at three different times during the year. Or three different training courses all tailored to different policies.

Your system is probably FISMA-ready and you are most likely a lot closer than you think. Because this is what FISMA is all about. Knowing your system, managing your risks, communicating with the government, operating the system as securely as possible.

Remember that the system is what is being certified, not the customer.