The 800-123 Guide to General Server Security came out this week, and really who needed this. I am sure this would have been helpful in 1995, when people had just started putting servers on the Internet. But who is seriously going to sit down with this and say "I hadn't thought of that!"
What I think we need now in the age of government *sourcing is some NIST guidance around Cloud, Managed and Virtualized systems.
My personal belief is that vendors are trying to get management/operation of government systems out of the government's hands so that there isn't as much bureaucracy.
Here is the thing, it is still the government's data. The system still must be certified.
To the Honorable Karen Evans: Please issue a memo stating unequivocally that: outsourced, managed, clouded virtualized, SaaS, shared whatevers need controls implemented to the same level that they would be if the government had built it themselves.
Quoteth the FISMA 3544(a)(1):
More on this later (I keep saying this, but will it ever happen?).
What I think we need now in the age of government *sourcing is some NIST guidance around Cloud, Managed and Virtualized systems.
My personal belief is that vendors are trying to get management/operation of government systems out of the government's hands so that there isn't as much bureaucracy.
Here is the thing, it is still the government's data. The system still must be certified.
To the Honorable Karen Evans: Please issue a memo stating unequivocally that: outsourced, managed, clouded virtualized, SaaS, shared whatevers need controls implemented to the same level that they would be if the government had built it themselves.
Quoteth the FISMA 3544(a)(1):
"(A) providing information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of—So for those of you out there who keep saying "Chris, it isn't in the agency's physical boundary". Stop it. You know who you are.
"(i) information collected or maintained by or on behalf of the agency; and
"(ii) information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency;
More on this later (I keep saying this, but will it ever happen?).
2 comments:
"To the Honorable Karen Evans: Please issue a memo stating unequivocally that: outsourced, managed, clouded virtualized, SaaS, shared whatevers need controls implemented to the same level that they would be if the government had built it themselves."
Ack, please no. A blanket statement like what you're asking for means that the Government loses economy of scale because all the service providers would build dedicated-mode services. IE, we would drop MPLS and stick with leased lines and instead of shared-seat MSSP operators you end up with dedicated contract staff. That gets way pricey.
As a contractor, there are some things that I cannot do. I cannot accredit systems. I cannot accept risk. I cannot report to OMB/GAO. However, I can support the client agencies who do--and that's a key difference.
Back in my CISO days (last year), the policy statement for us was to provide a "level of protection equivalent or superior to client government agencies".
You're highly vindicated though--there is a huge need for guidance. The official NIST line is "Make a risk-based decision and consider compensating controls".
Scope creep on the Government's behalf means that service providers, state and local government, and software vendors will some day reside within our scope of responsibility.
It doesn't mean that the government loses its economies of scale. It just means that the shared platforms they build need to be apply controls.
It is a common misconception that the government's data and commercial data can't be on the same system. But the government's data must be protected. If that contractor can provide that assurance, then there is no problem. Just an Interconnection Agreement and/or Memorandum of Understanding.
It may mean that some companies would build government-specific and commercial-specific systems. But that may not be to the company's benefit, they could one set of documentation for FISMA and another for ISO 27001 on the same system.
FISMA and the Risk Acceptance Process is inherently flawed in favor of mission success, but still I think that the service provider can derive value from system certification. Just doing it better and planning it out.
Post a Comment