OK, everybody take a deep breath and have a seat.  I’m going to tell you something that is either so obvious to you that you’ll pass out laughing or is so unethical to you that you are going to have an aneurysm and the cops will come beating down my door asking why you died looking at my blog.

So here it is:

When it comes to outsourcing, you cannot own all of the system, even if it’s in your contract.

Let me say that another way:  although you require the contractor to be compliant with FISMA and NIST standards and guidelines and your information security policy and anything else you feel necessary to bind them to, there will be a part of the contract that you are paying money for as a service that will be out of your Certification and Accreditation boundary and that you will not be able to control.

Calmed down yet?  Let me explain what I mean.

For example, consider the circuits that the telcos run to your facilities.  You don’t want to manage them both from a capabilities standpoint and from a risk management standpoint.  If you go and try to manage “your” circuits, and they break, then you have no recourse with the vendor–you have accepted the risk in their eyes.
Quite a few agencies nowadays use MPLS.  You don’t even need to know what the acronym means.  You just need to know that it’s a virtual private Internet that is owned and operated by the telcos.  You can take all your facilities, give them circuits to the MPLS cloud, and you have all the good redundancy of paths that the Internet provides, but in a more-controlled environment.  Deep down inside, you don’t really care how the cloud gets managed, you care that data that enters one end eventually makes it out the other end.
Now you’re contracting for server collocation with a vendor who provides you rackspace in their data center.  They have 20 different agencies with equipment in the data center.  The vendor maintains a common controls package that you now have to rely on for assurance.

Or you have contracted a vendor for end-user support, ie, on-site IT technicians.  These people need to be able to share trouble-ticket information with both people inside their company and the government agency that they support and to interface the trouble-ticket system with their billing, staffing, and cost systems.  Looking at all the requirements for a trouble-ticket system like this, about the only viable way to do it right is to have it on the vendor’s network and accessible from the government LAN/WAN.

I’ve talked to numerous people on how to manage these shared environments.  One Big 4 auditing firm told me that what I needed to do was to determine which agency had the majority of their data on the shared system.  They then would “own” the system with management of the system being a collaborative effort between all the agencies.

I had to wonder, what kind of crack was this guy smoking?  Seriously, most of the time I can’t get people in the same agency to agree with each other, much less people from different agencies with different missions and different risk cultures.  There is bound to be disagreement over how the system is run, with the end result is that the system will not be provided adequate security because it is bogged down in bureaucracy.

Yes, this is what the Lines of Business initiative will provide once it’s working, but even then, you have the same considerations.  Who really owns the various components of the system?

The thing to remember is that the vendors use shared systems because they work–this is the model that commercial providers use whether they tell you or not.  They also provide a significant cost savings to the government through economy of scale.  Inside our NOC, if we have 5 clients, wouldn’t it be nice (not to mention cheaper) to watch one screen instead of 5?  Let’s see, $14000 times 4 equals a nice chunk of currency that I just saved and can carry through to the client.  Beyond 5, and my business doesn’t scale–I can’t have 20 screens to watch, and I can’t afford to hire enough people to watch them all.  This goes the same for data centers, trouble ticket queues, security incident and event monitoring infrastructure, network monitoring systems–the list goes on and on.

I have basic architectural principles I use everyday at work as a managed services provider.  One of the most key principles is segregation of impact: that one client cannot be allowed to affect the service that I provide to another client.  I don’t let all 20 of them make decisions that affect you, and in exchange, I don’t let you affect them.  It’s really how people have coexisted with each other for bazillions of years, only now we’re talking IT security, which gets everybody’s heart pumping.

Part of this principle of segregation of impact means that I have some parts of my service offerings that I can’t give to the government from a boundary perspective.  Because if I do that, then I will have clients managing each other’s space.  It’s not only wrong from a service provider’s standpoint, but somewhere in there, I’ve double-charged the government for services.

The second principle that I use is that of transparency.  I tell you how I do it.  I manage the shared systems just like they are a government system, only I own them.  Our security policy executive statement states that we will meet or exceed government security requirements, keeping in mind that we are not a government agency, so some of the requirements don’t apply to us (reporting to OMB and the government style of CPIC in particular).  However, I do security planning, risk management, contingency planning, all the key points that the government does.

On the government side, what they get is a fairly simple risk management decision:  do we do it ourselfves with whatever costs it entails, do we keep the cost savings of the shared systems and give up some control, or do we want to pay more for something that we now “own”?  That really is the best of both worlds, because the government can determine which option they want based on cost/benefit/risk comparisons.

By providing transparency, I make that decision much easier.

The third principle is transference.  By providing a shared service attached to a service-level agreement (this works very well for the telco examples), the government has effectively transfered the risk to me as a vendor.  The problem is that SLAs for a very complicated outsourcing engagement are harder to define due to the complexity of the solution.  The other caveat is that the government still bears ultimate responsibility when things go wrong, so you still have a certain amount of residual risk.

Notice what I didn’t explicitly say here, but I did describe it in detail… we use compensating controls to manage the risk of the shared infrastructure from the perspective of the government.  That’s the only viable way to manage the risk of outsourcing.

The lastest revision of Special Publication 800-53 talks about this in section 2.4.  Sadly, though, most people don’t read that part.  They usually get to the catalog of controls and start making a checklist out of it.  However, if you are doing any kind of outsourcing in the US government, you need to read and re-read that section.

• Lines of Business, Relationships, and Trustability
• How Much Security Should the Outsourcer Do?
• Always Behind
• Effective Inventory Management
• Feds to Embrace SaaS, End is Nigh for Security!