Do I really need to say this?  As a government agency outsourcing some of its IT functionality, you did not outsource your responsibilities to provide adequate security to the outsourced systems.  OMB, the GAO, and your IG don’t care if you outsourced the system or not–they expect a certain level of security performance.

What you did do when you made a decision to outsource, however, was enter into a partnership with a vendor.  Yes, sometimes it feels like an abusive relationship. =)  But the key here is that it is a partnership.

The key to this partnership is open communication and understanding of the nature of this relationship.  The crux of the problem with outsourcing in the government is that it amplifies the operations-cost-paranoia triangle that you manage on a daily basis.  Where you used to be able to handle security problems internally, now you have several layers of abstraction (contracting officers, funding, 2 political structures) to work through.

So, for example, the life-cycle of a vulnerability looks something like this (everybody does it differently, so don’t cut-n-paste this into a process document unless you’re happy with it):

• Vulnerability discovered by vendor’s security team during monthly scanning
• Vulnerability reported to government ISSO and System Owner
• ISSO requests vendor to provide a rough order of magnitude (ROM) as a cost estimate
• Vendor provides ROM to ISSO through contracting
• System Owner and ISSO make a risk-based decision to mitigate and approve a budget for mitigation
• Mitigation plan transfered through contracts officer to require the vendor to mitigate
• Vendor mitigates the vulnerability and reports completion through contracts officer
• ISSO contacts vendor security team to validate mitigation through a “regression scan”

That’s pretty complex if you think about it, and there are numerous handoffs that could be missed if we don’t have a healthy, communicating relationship.

The conclusion you should have come to by now is that in order to succeed in outsourcing engagements, both sides of the contracting “fence” need to figure out tactics, techniques, and procedures to effectively manage this new layer of complications.

One thing that you’ll notice with outsourcing is that you have to have at least one knowledgeable security person on both sides.

One thing that works is to add a contract clause that lets the contractor’s security people talk to your security people.  The first ground rule is that you decide on what is the security-correct thing to do first, then figure out how to manage the business and contract end of things.

Another thing that works is to decide on a firm delineation of responsibilities before you put the RFP out on the street.  Look at your strengths and weaknesses as an agency.  It could be that you need a full turnkey solution from the vendor along with a large security team to support it because you only have one security practitioner on your project staff (for example, a large LAN/WAN rollout) or you just need a small team from the vendor to dovetail into your already-existing staff.  More on division of labor later this week….

You might want to consider a second, smaller, contract, for security support if you have a small staff on both sides of the contracting relationship.  This adds complexity to our relationship, but it also fixes some conflict-of-interest issues.  An even better way to use a second contractor is for a short engagement to perform a “gap analysis” to tell you what support you need the outsourcing vendor to provide.

Ultimately, though, the thing to remember is that as the government, it is your system, and you have a responsibility to provide adequate security .  Outsourcing just changes the nature of the business, not the endstate.

• How Much Security Should the Outsourcer Do?
• Keys to the Outsourcing Kingdom
• What the Government Looks for in a Product
• Compensating Controls
• Always Behind