OK, the title is for hyperbole purposes, but I think that the current Government security model doesn’t work with the way we do Software as a Service (SaaS) today. =)

Karen Evans has officially thrown her hat in the ring to support Software as a Service. I agree, but I think it’s also harder to accomplish than OMB might think. I’ve said this before, but information sharing, security, and SaaS doesn’t fit into The Government Way of Doing Things ™, and that needs to get fixed.

Hurdles that the government needs to overcome for SaaS (and I guess Lines of Business as a whole):

• Personnel Security: How do I know that my user population is cleared to view the information that I’m providing, and how do I ensure that I get notification when they leave? (note: HSPD-12 in theory could fix this)
• Trustworthiness of Service Provider: How do I trust a server and/or application operated by another agency?
• Interconnectivity: Can we route SaaS traffic over the Internet or do we need to interconnect our LAN/WANs to get to the resources?
• Assurance: How do I prove to a customer agency that my solution meets their security needs without running into “Not Invented Here” problems?
• Certification and Accreditation: If this is a mission-critical system for me, how do I account for the security of it when it’s a low-impact system for the service provider? What do I do if I want the service provider to increase some of the security on the system?
• Guidance: We have OMB telling us what they want to see accomplished (which is SaaS in general) but there isn’t any formal guidance on how to do this and still stay within the bounds of our security framework.

All of the current guidance for information sharing between IT systems is based on IP connectivity between 2 LAN/WANs. The process (SP 800-47 if you want to research) breaks down like this:

• Certify and Accredit the networks of both agencies.
• Do a Risk Assessment of the connection.
• Establish a Memorandum of Understanding (manager-level, we like you, you like us, these are the rules on what you can do with our data).
• Make a “firewall sandwich with circuits betwixt” with each side owning their own firewall so if they decide they don’t want to play anymore, they can unilaterally kill the connection.
• Establish an Interconnect Agreement (technical level, routing and firewall configuration, technical POCs, etc)
• Make the connection.

Nowhere in there is anything we can use for SaaS. Believe it or not, I’ve seen well-intentioned IA analysts trying to get people to sign an interconnect agreement for an RSS feed out on a website when in all actuality, the interconnect is with the Internet and it’s your responsibility as a feed customer to sanitize the input before you do anything with it.

SP 800-95 covers web services but from a Service-Oriented Architecture (SOA) angle but doesn’t talk about the interaction between the players and processes.

Hence, the Guerilla CISO’s guide to SaaS in the government:

• Determine that you want to be a vendor for SaaS. You can be G2G or C2G.
• Pick a security baseline. I usually recommend a Moderate FIPS-199 because it will apply in most contexts.
• Build your SaaS system.
• Certify and Accredit your SaaS system.
• Provide a SaaS kit to your supported agencies containing the following information:
  • Service delivery options (interconnect or via Internet)
  • API/Service Specifications
  • System Security Plan
  • Security Test and Evaluation Report
  • Sign a Memorandum of Agreement that is basically an Acceptable Use Policy at a department level.
• Perform security upgrades at a partial cost to the supported client agency.
• Periodic client agency meetings with the service provider.

• HR 5983–DHS Now Responsible for Contractor Security
• Lines of Business, Relationships, and Trustability
• Alternative Uses for System Security Plans
• Response to “What is Information Assurance – The Video”
• Compensating Controls