In a news article at The Register, the US Government is going to have a standard hardened set of settings of Windows OS’s that they will require vendors to install.

From TFA:

“The purchasing power attached to the $65bn federal IT spending budget means that suppliers will have no choice but to take notice.”

Right on!  I’ve been waiting for this for a long time.  You have the 8000-lb gorilla of IT budgets sitting back, buying all this junk from people and then not doing anything about the poor quality of it.  About a year ago, I started teaching government employees in my classes that they had the power to ask for better software, and I think the idea is starting to sink in.

Now they have to do me proud and not make the settings a watered-down weak version of what they should be.  My one fear is that this will be hardening by committee, where you have all these people who show up out of nowhere to complain that one hardening setting or another breaks the functionality they absolutely need to not harden that part of the OS.  The problem with that is you end up with hardening holes.

• Do You Know What FISMA Is?
• Rebuilding C&A
• Power Outages Do Happen
• And Now for Something Completely Different…
• SCAP for Dummies

This is an exceptionally well-written piece at CSOOnline.  I still reread it from time to time.

For the record, I’m a geek at heart but a soldier and cop functionally and a mandarin and banker only when I’m forced to. =)

• Core Beliefs Series
• More Tollroad Follies
• A Story About Potatoeseses
• I’m Addicted to the Hans Reiser Trial
• Blame it all on John Hughes….

Want me to take a stab at what the information security management world will look like in 5 years?  I think I’m starting to see the start of it, and I’ll tell you about it if you sit for awhile and listen.

The US government does some things right.  Yes, you heard me correctly.

You probably think by now that all I do now is whine about huge levels of gross incompetence I see on a daily basis and how I could singlehandedly run the government all while sitting at home, sipping on a coke, and crunching data on my own personal cluster of beowulf clusters.

But really, the government does some things right.  The folks at the NIST FISMA project do some very amazing things, and I’m not just saying that to suck up to Ron and Marianne.

One thing that the government does right is to make their guidelines available for free to anyone over the internet.  And some of them beat the pants off what you would find in the commercial world.  Inside ISM-Community, when we started the Risk Assessment Methodology Project, I personally found it hard to ignore the fact that Special Publication 800-30 was staring me in the face.  How really do you improve on it?  Well, for starters you take 800-30 as a base process and then add more specific guidelines, examples, and templates, which is pretty much what our methodology started out as.
One of the things that NIST does really well is to provide you with a framework.  It’s extensible to include various standards (PCI, 7799, and the government’s home-grown 800-53), tailorable, and is designed to hook security into the system development life cycle (SDLC).  It’s entirely free as in beer and free as in you have the ability to import into your own processes.

Would you be surprised if I told you the framework was certification and accreditation?

Yes, I’ve criticized certification and accreditation a bazillion times.  Well, I haven’t really criticized the process–personally I think it’s really strong.  Instead, I criticize the implementation of the process and how the people who are tasked with C&A usually do not have the technical skills to accomplish what they are trying to do.

I’ve seen 2 RFPs out on the street in the past couple of months for C&A services for local governments.
This is driven by auditors and practitioners coming from the federal government who are making recommendations on joint systems, like RealID will end up if the states don’t rebel like it seems they are starting to do.

The future will bring along C&A, and it might even turn out to be the vehicle for needs determination and risk assessment, but C&A has to adapt and lose some of it’s heavy baggage along the way.

• FISMA Fellows Spring Cohort
• What the Government Looks for in a Product
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• Build a Security Program
• Remembering Accreditation

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

I have a unique vantage point on how security, outsourcing, consulting, and the public sector work.  While I am a contractor who works for a company that provides outsourcing services, most of the time I end up arguing the government’s standpoint to my company, and I end up arguing my company’s standpoint to the government.

In short, I argue a lot.  =)  So much, in fact, that most of the time people have to ask who I work for and they’re shocked to find out the truth.

One issue that I hold close to my heart is how to manage security in outsourcing.  I’ve seen what works, and I’ve seen what doesn’t work, but usually more of the latter.

The truth is that while the government is getting smarter about outsourcing, we still have miles to go.  For example, more often than not a government contract nowadays contains a clause that “the contractor must be compliant with FISMA and NIST standards and guidelines”.  On one hand, I like this, it shows that “The Word” (TM–thanks, Joe) is slowly sinking in.  However, it’s not enough, and I’ll explain why.

The problem is that if you are wearing a contractor hat, what you are looking at is a simple problem: “How do I estimate the cost to me for providing security support to the government as part of this contract?”  This is a problem because “compliant with FISMA and NIST standards and guidelines” runs an entire range of situations from horrible Bataan-death-march malicious compliance contracts to well-managed common controls shops, and unless I have prior experience with this particular agency, I don’t know which side of the spectrum they are on.

As a contractor, when it comes to security, we are almost always responding reactively to security requirements.  This might mean that we have to significantly change the solution mid-stream in order to satisfy what the government wants.  Contractors don’t like this because it means we have to fight with the government over costs, which is just no fun for either of us.  On the government side, we’re wondering why the contractors don’t just Do What I Mean, since I obviously said “be compliant or else”.

Just thinking back, I know what to expect from a handful of agencies, but if they’ve experienced key personnel changes or were suddenly born-again security-wise because of a bad report card, then suddenly my crystal ball has gone black.  Wouldn’t it be nice if we could ask them in advance on which side of the teeter-totter they are sitting on?

Well, I have a partial answer.  You cynics were waiting for this, weren’t you?

How about the government starts their System Security Engineering process and their Certification and Accreditation before they send out the Request for Proposal or Request for Information?  That way, when we send out something for the industry to respond to, they have something to base their security estimates on.  According to the fancy manuals, this is how we should be running the Capital Planning and Investment Control Process all along.  You’re not that mature as an agency?  Don’t worry, you’re not alone.
We have the tools already built to do this.

We have FIPS-199 (ratings for Confidentiality, Integrity, and Availability) which can provide a contractor with a very rough order of magnitude on how much security to build into their response.  As soon as we know what we want to use the system for, we can determine data types and, by extension, criticality.

And we have FIPS-200/SP 800-53 which, although we don’t want to build the entire set of controls, we can select controls out of the catalog which absolutely need to be implemented.  We base this on, take a seat for this one… risk assessment.  We can then put these controls (a dozen or so of the high-priority controls at the most, otherwise you’re defining the solution space and limiting the flexibility of the vendor to be cost-effective) as security requirements or even functional requirements.

Now isn’t that better than a blanket FISMA/NIST clause?

• Keys to the Outsourcing Kingdom
• Imagine that, System Integrators Doing Security Jointly with DoD
• Your Security “Requirements” are Teh Suxxorz
• How Much Security Should the Outsourcer Do?
• Compensating Controls

Maybe it’s just the DC area.  Every good security person I know here is very confrontational.  We just like to argue.  Some days I feel like it’s a slow morning, so I just walk around and stir the pot, knowing that some good conflict will rise to the top.

I think it has to do with the following factoid: security is the conflict between economics, paranoia, and useability.  We have to be able to manage the tradeoffs between these 3 corners of the triangle.  The good people understand the nature of this and realize that sometimes it’s not really a security problem–its a client education problem, it’s an auditor problem, it’s a personality conflict, etc.

So how do we conclude an argument?  Well, I know 2 people right now that when I’m around both of them, we can talk for hours debating the particular merits of one viewpoint or another.  The way we stop the disagreement is to mention risk.  Once we do that, the game is over.  Once I can pin the actual risk (versus the perceived risk, but that’s another story), then there is nothing to talk about anymore–we have rounded the corner on that topic and there isn’t anything else to debate.

• Core Belief #2 — Risk Management Uber Alles
• MREs and Bad News
• You Didn’t Outsource Your Responsibilities
• Another Day, Another Vendor
• Security Assessment Economics