Now for the search string:, “enter document marking here” site:agency.gov filetype:rtf | filetype:ppt | filetype:pptx | filetype:csv | filetype:xls | filetype:xlsx | filetype:docx | filetype:doc | filetype:pdf looks for typical document formats on the agency.gov website looking for a specific caveat.  You could easily put in a key phrase used for marking sensitive documents in your agency.  Obviously there will be results from published organizational policy describing how to mark documents, but there will also be other things that should be looked at.

Typical document markings, all you have to do is pick out key phrases from your agency policy that have the verbatim disclaimer to put on docs:

• “This document contains sensitive security information”
• “Disclosure is prohibited”
• “This document contains confidential information”
• “Not for release”
• “No part of this document may be released”
• “Unauthorized release may result in civil penalty or other action”
• Any one of a thousand other key words listed on Wikipedia

Other ideas:

• Use the “site:gov” operator to look for documents government-wide.
• Drop the “site” operator altogether and look for agency information that has been published on the web by third parties.
• Chain the markings together with an “or” for one long search string: “not for release” | “no part of this document may be released” site:gov filetype:rtf | filetype:ppt | filetype:pptx | filetype:csv | filetype:xls | filetype:xlsx | filetype:docx | filetype:doc | filetype:pdf

If you’re not doing this already, I recommend setting up a weekly/daily search looking for documents that have been indexed and follow up on them as an incident.Similar Posts:

• Database Activity Monitoring for the Government
• Clouds of CAG Confusion
• Ed Bellis’s Little SCAP Project
• Some Words From a FAR
• How to Not Let FISMA Become a Paperwork Exercise

Similar Posts:

• Lolcats and QR Codes
• Redundant Lolcats
• Lolcats Protect the End Users
• Lolcats Coming to you from the Cloud
• Lolcats, Capital Hill, and a Haiku

Just starting a collection, feel free to add more:

• Compliant doesn’t mean secure.
• You can always go above the minimum baseline.
• You don’t know what you don’t know.
• Security is a journey, not a destination.
• We all know that $Foo is dying/dead/failing/stillborn.
• There is no silver bullet.
• It’s security, it’s supposed to be hard.

Similar Posts:

• On Government Employees, Culture, and Survivability
• The Press has Me all Confused
• Now ISC2 Blogs have an Opinion on FISMA
• Inside the Obama Administration’s Cyber Security Agenda
• Beware the Cyber-Katrina!

• GAO’s 5 Steps to “Fix” FISMA
• Old Saint NIST: Ho Ho Hold on, what’s this?
• A Funny Thing Happened Last Week on Capital Hill
• “Machines Don’t Cause Risk, People Do!”
• The 10 CAG-egorically Wrong Ways to Introduce Standards

One of the things the program committee worked on was more of a practitioner focus.  I think the whole event was a good mix between theory and application and the overall blend was really, really good. Talking to the speakers before the event was much awesome as I could give them feedback on their talk proposal and then see how that conversation led to an awe-inspiring presentation.

I brought a couple security manager folks I know along with me and their opinion was that the event was way awesome. If you’re one of my blog readers and didn’t hunt me down and say hi, then whatcha waitin’ for, drop me an email and we’ll chat.

You can go check out the slides and papers at the Security Metrics site.

My slides are below.  I’m not sure if I was maybe a bit too far “out there” (I do that from time to time) but what I’m really looking for is a scorecard so that we can consciously build regulation and compliance frameworks instead of the way we’ve been doing it. This would help tremendously with public policy, industry self-regulation, and anybody who is trying to build their own framework.

Similar Posts:

• Massively Scaled Security Solutions for Massively Scaled IT
• Why We Need PCI-DSS to Survive
• Building A Modern Security Policy For Social Media and Government
• DojoCon 2009 Presentation
• Professor Rybolov’s Guide to InfoSec and Public Policy Analysis

Similar Posts:

• SCAP in Lulz
• Oh to be a Program Manager
• Preliminary Findings on Cybersecurity Review Now Out
• Cyber-Ninja Lolcats Caught on Film
• IKANHAZFIZMA Finds Caution Tape

Similar Posts:

• Lolcats Attend B-Sides
• Look Out, Sir Bruce, IKANHAZFIZMA is Coming for You
• Preparing for Cybergeddon
• Lolcats Coming to you from the Cloud
• Super Secret Security Control You Were Never Meant To See

Or is it just that all the security management frameworks suck and auditors remind us of that on a daily basis.  =)

However, it seems that there are 3 ways that people approach frameworks:

• From the Top–starting at the organization mission and working down the stack through policy, procedures, and then technology.  This is the approach taken by holistic frameworks like the NIST Risk Management Framework and ISO 27001/27002.  I think that if we start solely from this angle, then we end up with a massive case of analysis paralysis and policy created in a vacuum that is about as effective as it might sound.
• From the Bottom–starting with technology, then building procedures and policy where you need to.  This is the approach of the 20 Critical Security Controls.  When we start with this, we go all crazy buying bling and in 6 months it all implodes because it’s just not sustainable–you have no way to justify additional money or staff to operate the gear.
• And Then There’s Reality–what I really need is both approaches at the same time and I need it done a year ago. *sigh*

Similar Posts:

• SP 800-53A Now Finally Final
• Opportunity Costs and the 20 Critical Security Controls
• 20 Critical Security Controls: Control-by-Control
• A Niche to a Niche is Still Hard to Staff
• 20 Critical Security Controls: What They Did Right and What They Did Wrong

Agenda is here, I think there is still time to sign up and come as long as you’re not going to be a wallflower.  =)Similar Posts:

• Draft of SP 800-37 R1 is Out for Public Review
• Oh Lookie, Somebody’s Doing What I Said To Do….
• Federal Computer Week and S.773
• A New Take on Continuous Controls Monitoring
• CISOin’ Ain’t Easy, But It’s a Living

So I was thinking the other day (this is the part where people who know me in person usually go “oh cr*p”), partially spurred by a conversation I had with @csoandy and @secbarbie a couple of months ago.  I’ll get the idea out there: as an industry we need to embrace the concept of split-horizon assessments.

Two Purposes for Assessments

Because this is an insane approach that I’m just feeling out, let me go on a solo riff and explain what I’m talking about.  You see, I have two distinct purposes for getting a security assessment, both of which are in contention with each other:

• I want to fix my security by asking for money to fix the things that need attention.  When I get an assessment for this purpose, enumeration of my badness/suckness is good.  If I have a set of results that say that everything is great, then there’s no need for me to be given any more resources (time, money, people, gear).  Short-term, I’m fine, but what about my infrastructure-type long-term projects?  The net effect of a highly-scored annual assessment just might kill my program in 2 years as my funding and people are shifted elsewhere, especially in a .
• I want to keep my job and help my {company|agency|group} stay out of trouble by showing my zero-defects face and by demonstrating my due-diligence in protecting what has been given to me.  While the assessor has helped me short-term by identifying my problems and being a total hardass, if I’m not around in 6 months to adopt the recommendations into my security program, has the assessor actually helped me?

And this is the dilemma for just about every security manager out there.  One of the strategies is to alternate assessment types, but then your management wonder just what the heck it is you’re doing because you’re on top one year, then on the bottom the next.

Split Rock Lighthouse and Horizon photo by puliarf.

Assessor Window-Shopping

Now for the dirty little secret of the testing business:  there are really good testers who are the ninjas of the InfoSec world and there are really bad testers who don’t even validate their unlicensed Nessus scan.  I know, you’re shocked and it’s so blindingly obvious that Bruce Schneier will blog it 3 years from now.  =)

But there’s the part that you didn’t know:  security managers pick their assessor depending on the political mood inside their organization.  This is nowhere near a science, from what I’ve seen it involves a lot of navel-gazing on the part of the security team to see which is the lesser evil: having everybody think you’re incompetent or never getting anything new ever again?

Building a Better Rat Race

In order to accomplish both of the goals that I’ve listed, what I really need is a split-horizon assessment.  In other words, I need 2 reports from one assessment with different views for different audiences.  I know this sounds highly cynical, but it’s something we’ve been doing for some time now but just informally.  Might as well make it formal.

So are you sold on this concept yet?  In true form, I have an idea on how to get to a world of split-horizon assessments.  You can take any catalog of controls and divide it into “gotta have it” and “nice to have” (I almost divide these along the lines of “vulnerability mitigation” and “sustainable security program” or the “CISO” and “OMB and Congress”) buckets.  Then in your compliance assessment standard, require 2 reports for each assessment.  One is reported to the regulating authority and the other stays with the organization.

Indecision Strikes

I don’t know if I’ve solved the problemspace or not, but I’m looking for feedback “from the Peanut Gallery” so leave some comments.Similar Posts:

• Security Assessment Economics
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Security Assessments as Fraud, Waste, and Abuse
• A Funny Thing Happened Last Week on Capital Hill
• “Machines Don’t Cause Risk, People Do!”

I’ll even admit to having my own opinions from time to time, although I’m not in it for the filthy lucre, just trying to help.  =)

Similar Posts:

• Preliminary Findings on Cybersecurity Review Now Out
• Aurora and LOLCATS
• The InfoSec D-List and IKANHAZFIZMA
• Cyber-Workforce Training?
• Lolcats take on Laws, Sausage, Cyberwhatzits, and PCI

You can go watch the video and read the written testimonies here.  This is mandatory if you’re working with FISMA, critical infrastructure, or large-scale incident response.  I do have to warn you, there are some antics afoot:

• Senator Collins goes all FUD on us.
• Senator McCain grills Phil Reitinger if DHS can actually execute a cybersecurity mission.
• Alan Paller gets all animated and opens up boxes of paperwork.  I am not amused.

Similar Posts:

• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• In Response to “Cyber Security Coming to a Boil” Comments….
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 5

As is true for technological solutions, security controls and security policy must also be subject to the concepts and process found in life-cycle methodologies. As security professionals we must be constantly aware of these cycles as in some cases this means that controls and policies can outlive their usefulness. In other cases it means that security policies, concepts, and policies can evolve or mutate until they are no longer viable or meaningful.

It is the later phenomena that that caught my attention recently. But, first let me set the stage…

A Tragic History

Back in 1983 the American people were made aware of the concept of a truck bomb in a dramatic and tragic fashion. In late October of that year, truck bombers attacked the compounds housing U.S. and French peacekeepers in Lebanon. The loss of life was shocking.

In the aftermath of this tragedy there was a great deal of political finger pointing. Notably, security professionals had expressed concerns about the vulnerability of the deployment and had made several recommendations to improve the security of the facility. Some of the recommendations were followed, others that would have greatly mitigated the against the damage and loss of life in the subsequent attack were not implemented. In addition, security professionals were also asked to rise above all of the politics and examine the situation from a, “lessons-learned” perspective and develop generally applicable counter-measures. One obvious and immediate response was the introduction of the bollards or jersey barriers around public and government buildings. While experts agreed that this wasn’t a complete solution to the problem of the vehicular bomb, it was and still is seen as a useful and essential tool.

Two criticisms to the use of these physical barriers were quickly voiced. The first criticism focused on the aesthetics of these barriers. Critics correctly pointed out that the barriers that were initially introduced were ugly and made public building buildings and spaces protected by these barriers take on an unfriendly fortress-like appearance. After a time the response to this was the introduction of barriers that were masqueraded as sculpture, large planter boxes and even seats or benches.

The second criticism focused on the fact that many public building and spaces were constructed in such a fashion such that it was difficult, expensive, and in some cases even impossible to effectively employ these barriers. A common problem noted was that building was often constructed with little or no “set-back” between the building and streets. This meant that there is no meaningful way in which to erect barriers at a sufficient distance from the building in question to afford it any meaningful protection.

Within the limits of always constrained budgets, the Federal government began erecting vehicular barriers all over the country and even overseas. The government also began a program that developed a risk and vulnerability assessment or classification of all Federal facilities and buildings.

History Repeats Itself With a New Twist

Ten years later, the US was horrified again by the bombing of Federal Building in Oklahoma City. While the bombing and loss of life was a terrible tragedy in the truest sense of the word, the similarities of this incident to the 1983 incident made it all that much more painful. The fact that the Oklahoma City tragedy took place domestically and resulted from entirely domestic terrorist plotters made the situation even more sobering.

Even worse, because the above mentioned security assessment classified the Oklahoma City Federal Building as being a relatively low risk facility. There were two significant consequences to this security assessment/classification. The first was that the use of extensive anti-vehicle barriers or bollards were seen as being unnecessary. The second was that the building was seen as safe enough that a day care facility was approved for the building. This decision added an additional element of heartbreak to the general feeling of horror and grief in response to the bombing.

A Thoughtful Response

In the aftermath of this terrible act the Federal government develop a rather extensive set of building specification that were required in all new construction. When implemented, these specifications greatly increase a building ability to resist a similar attack. Moreover, this risk-based specification focuses considerable attention on reducing the risks to the people in the building. For example, protective films are required for all windows, thus reducing the risks from flying fragmented glass.

Because of the extended thought that went into this specification, many of the technologies and approached embraced in the specification are also available as affordable retrofits to existing building. This is especially useful in the case of leased building or office space.

Having had an opportunity to work with these codes and specification, my impression is that there is a good deal of sound thinking behind these measures. Moreover, these specifications are constantly reviewed and updated taking into account the latest threats and the technical developments.

Security Meets the Street

A few weeks ago I was walking down Pennsylvania Avenue, in Washington D.C. I was a beautiful day and I was just a few blocks from the White House. I was a little surprised when I saw one of bollards that I mentioned earlier. The bollard itself isn’t all that surprising; they are a pretty common site around the nations’ capital. The fact that this particular barrier was masquerading as a planter box for a small tree was also not all that unusual. However, the barrier was damaged.. At a casual glace a damaged bollard also isn’t all that unusual a sight either. But, with a quick glance at this bollard something in the back of my mind whispered that there was something odd about this barrier. I looked at the damaged area and noticed that the bollard was filled with Styrofoam. That seemed odd enough to catch my attention and motivated me to investigate a bit further.

The first thing I did was to take a quick snap-shot of the bollard (see below). I can’t say it’s likely that I will ever will a Pulitzer Prize for photo journalism, but if you examine my snapshot closely you can clearly identify the Styrofoam grains in the damaged section photographed. I also had a bit of luck. Just as I was looking at the barrier one the incredibility efficient and effective D.C. Parking Enforcement Offices just happened by plying their trade. I asked them I they were aware of what happened to the barrier in question. I was in luck; the officer was an eye-witness to a minor fender bender in which the bollard was damaged. I pointed out the foam filling and asked if what the point of the foam was. She informed me that the barriers had to be moved all the time. Older planter boxes were constructed from solid poured cement or aggregate but, they were heavy and difficult to move. So, in response to this problem, they introduced the “improved” lighter weight barriers. I pointed out that it didn’t seem to be very durable and therefore didn’t seem to be a very effective barrier to a vehicle driven by a determined individual. She laughed and shared with me they were so fragile that the crews that moved them often damaged or destroyed them just by moving them.



Styrofoam in Concrete Barrier photo by Ian.

I guess at that point my incredulous look was obvious on my face and the officer responded to my unasked question by say, “I just write tickets; have a nice day!”

Conclusion

Perhaps I’m over-reacting to what I saw and heard. However, this seems to be a good example of how an essential security control can be compromised for reasons completely unrelated to security. In this case, it isn’t clear what the role of the security professionals involved in this process was. They could have fought the weakening of this security control to the limits of their ability. It is also possible that the warning of the security-types were lost in the shuffle between the various Federal and city jurisdictions involved in this situation. Convenience and practicality are often the enemy of security policy and security implementation. On the surface of it, this seems to be a good case study making that point.

This is perhaps an example of one of the most difficult and frustrating aspects of the responsibilities of the security community — especially for security leaders. We must hold the line and do the right thing. We will never be thanked for it. And, we constantly risk having our jobs or reputations put at risk for doing the right thing and fighting the good fight. But, it is important to remember that the consequences of ignoring this responsibility are even larger and potentially graver that job security. I know that Vlad is a hard-nosed security professional who will not compromise. If he is over-ruled, and that happens, he still sleeps well at night.Similar Posts:

• William Jackson on FISMA: It Works, Maybe
• When Standards Aren’t Good Enough
• A Funny Thing Happened Last Week on Capital Hill
• How to Not Let FISMA Become a Paperwork Exercise
• “Machines Don’t Cause Risk, People Do!”

Anyway, our IKANHAZFIZMA lolcats have finally found a control worth monitoring:  the world’s supply of overstuffed cheeseburgers.  This continuous monitoring thing is serious business, just like the Internets.

Similar Posts:

• Federal Computer Week and S.773
• Metricon is Next Week
• Oh Lookie, Somebody’s Doing What I Said To Do….
• CISOin’ Ain’t Easy, But It’s a Living
• Draft of SP 800-37 R1 is Out for Public Review

So there I am having a beer at my favorite brew pub Dogfish Head Alehouse, in Fairfax, when my phone vibrates to this ditty…. I couldn’t get past the “breaking news.”

From: <The SANS Institute>

Sent: Friday, May 28, 2010 4:05 PM

To:Vlad_the_Impaler@myoldisp.net

Subject: SANS NewsBites Vol. 12 Num. 42 : House attaches FISMA corrections to Defense Authorization Bill for rapid action

* PGP Signed by an unmatched address: 5/28/2010 at 2:52:21 PM

Breaking News: US House of Representatives attaches new FISMA rewrite to Defense Authorization Bill. The press hasn’t picked it up yet, but NextGov.Com will have a story in a few minutes. This puts one more nail in the coffin of the Federal CISOs and security contractors who think they can go on ignoring OMB and go on wasting money on out of date report writing contracts.

Alan

Yet another millstone (pun intended) piece of legislation passed on a Friday with… a cheerleader?!?!??? Whoa.

This ruined what was turning out to be a decent Friday afternoon for me…

My beef is this — I guess I really don’t understand what motivates someone who vilifies Federal CISOs and security contractors in the same sentence? Does the writer believe that CISOs are in the pocket of contractors? Even I am not that much of a cynic… Which CISO’s are “ignoring OMB?” All of them except NASA? Are all of our Government CISOs so out of touch that they LIKE throwing scarce IT dollars away on “out of date report writing contracts?” (sic.) (Vlad – Are hyphens too costly?)

I could drop to an ad hominem attack against the writer, but that’s pretty much unnecessary and probably too easy. I’ll leave that to others.

Suffice to say that what is motivating this newsbit appears IMHO to be less about doing things the right way, and more about doing things their way while grabbing all the headlines and talking head interviews they possibly can. (See “self-licking Ice Cream Cone” in my last post)

Yeah, I’m a cynic. I’m a security professional. What’s yer point?Similar Posts:

• Next Up in Security Legislation: S3474
• No, FISMA Doesn’t Require That, Silly Product Pushers
• In Other News, I’m Saying “Nyet” on S.3474
• Ooh, “The Word” is out on S 3474
• “Machines Don’t Cause Risk, People Do!”

Goals to surviving FISMA, based on all the criticisms I’ve read:

• Reduce paperwork requirements. Yes, some is needed.  Most is not.
• Reduce cost. There is much repetition in what we’re doing now, it borders on fraud, waste, and abuse.
• Increase technical effectiveness. IE, get from the procedural and managerial tasks and get down into the technical parts of security.

“Uphold our Values-Based Compliance Culture photo by kafka4prez.

So now, how do you keep from letting FISMA cripple you or turn into death-by-compliance:

• Prioritize. 25% of your controls need to not fail 100% of the time.  These are the ones that you test in-depth and more frequently.  Honestly, how often does your risk assessment policy get updated v/s your patch management?  Believe it or not, this is in SP 800-53R3 if you interpret it in the correct context.  More importantly, do not let your auditors dictate your priorities.
• Use common controls and shared infrastructure. Explicitly tell your system owners and ISSOs what you are providing as the agency CISO and/or the GSS that they are riding on.  As much as I hate meetings, if you own a General Support System (GSS), infrastructure (LAN/WAN, AD Forest, etc), or common controls (agency-wide policy, budget, Security Operations Center, etc), you have a fiduciary, legal, and moral obligation to get together with your constituency (the people who rely on the security you provide) and explain what it is you provide and allow them to tell you what additional support they need.
• Share Assessment Results. I’m talking about results from service providers with other agencies and systems.  We’re overtesting on the high-level stuff that doesn’t change and not on the detailed stuff that does change.  This is the nature of security assessments in that you start at the top and work your way down into the details, only most assessments don’t get down into the details because they’re busy reworking the top-level stuff over and over again.  Many years ago as a contractor managing infrastructure that multiple agencies used, it was unbelievably hard to get one agency to allow me to share security documents and assessment results with other agencies.  Shared assessment results mean that you can cut through the repetitious nature of what you’re doing and progressively get deeper into the technical, frequently-changing security aspects.
• Simplify the Paperwork. Yes, you still need to document what you’re doing, but the days of free-text prose and being graded on grammar and punctuation need to be over.  Do the controls section of System Security Plans as a Requirement Traceability Matrix.  More important than that, you need to go by-control by-component.  If you are hiring contractors and their job is to do copypasta directly from NIST documents and change the pronouns and tenses, you’re doing it wrong.  Don’t stand for that in your security policy or anything else that you do.
• Automate Wherever Possible. Note that the controls that change frequently and that need to not fail usually fit into this group.  It’s one of those “Things that make Rybolov go ‘Hmmmm’”.  Technology and automation provide both the problem and the solution.  Also see my first point up above.
• Fire 50% of Your Security Staff. Yes, I’m serious.  Those people you didn’t need anyway, primarily because they’re violating all the points I’ve made so far.  More importantly, 25 clueless people can mess things up faster than 5 clueful people can fix them, and that’s a problem for me.  Note that this does not apply to @csoandy, his headcount is A-OK.

The incredible thing to me is that this stuff is already there.  NIST writes “hooks” into their Special Publications to allow the smart people the room to do all these things.

And now the part where I hop up on my soapbox:  reforming FISMA by new legislation will not make any achievements above and beyond what we have today (with the exception of creating a CISO-esque position for the Exective Branch) because of the nature of audit and compliance.  In a public policy sense, the more items you have in legislation, the more the audit burden increases and the amount of repetition increases, and the amount of nonsense controls (ie, AntiVirus for Linux servers) increases.  Be careful what you ask for, you just might get it.Similar Posts:

• “Machines Don’t Cause Risk, People Do!”
• Security Assessments as Fraud, Waste, and Abuse
• When the Feds Come Calling
• GAO’s 5 Steps to “Fix” FISMA
• Observations on SP 800-37R1

Similar Posts:

• Snowmageddon Meets the IKANHAZFIZMA Lolcats
• Incident Response and Lolcats
• LOLCATS: Defending our Cyber-Turf
• IKANHAZFIZMA and Transparency
• Aurora and LOLCATS

Come to think of it, I haven’t blogged about FedRAMP, maybe it’s time to.

FedRAMP is a way to do security authorization (formerly certification and accreditation, get with the times, man) on a cloud then let tenant projects use that authorization.  Hmmm, sounds like…. a General Support System with common controls and Major Applications that inherit those controls.  This isn’t really anything new, just the “bread and butter” security management concepts scoped to a cloud.  Basically what will happen with FedRAMP is that they have 3 standards: DoD, DHS, and GSA (most stringent first) and cloud providers get authorized against that standard.  Then when a project wants to build on that cloud, they can use that authorization for their own authorization package.

All things considered, FedRAMP is an awesome idea.  Now if we can get the holdout agencies to actually acknowledge their internal common controls, I’ll be happy–the background story being that some number of months ago I was told by my certifier that “we don’t recognize common controls so even though you’re just a simple web application you have to justify every control even if it’s provided to you as infrastructure.”  No, still not bitter at all here, but I digress….

And then there are the pieces that I haven’t seen worked out yet:

• Mechanism of Sharing: As a service provider, it’s hard enough to keep one agency happy.  Add in 5 of them and it gets nearly impossible.  This hasn’t really been figured out, but in Rybolov’s small, myopic world, a panel of agencies owning an authorization for a cloud provider means that the cloud never gets authorized.  The way this has been “happening in the wild” is that one agency owns the authorization and all the other agencies get the authorization package from that agency.
• Using FedRAMP is Optional: An agency or project can require their own risk assessment and authorization even though a FedRAMP one is available.  This means that if the agency’s auditors don’t understand the process or the “risk monkeys” (phrase courtesy of My Favorite Govie) decree it, you lose any kind of cost savings and time savings that you would get by participating in FEDRAMP.
• Cloud Providers Rule the Roost: Let’s face it, as much as the Government wants to pretend that the cloud providers are satisfying the Government’s security requirements, we all know that due to the nature of catalogs of controls and solution engineering, the vendor here has the advantage.  Nothing new, it’s been happening that way with outsourcing, only now it’s immediately evident.  Instead of trying to play ostrich and stick our heads in the sand, why don’t we look at the incentives for the cloud providers and see what makes sense for their role in all this.
• Inspector General Involvement: I don’t see this happening, and to be honest, this scares the hell out of me.  Let me just invoke Rybolov’s Law: “My solution is only as good as my auditor’s ability to understand it.”  IE, if the IGs and other auditors don’t understand FedRAMP, you don’t really have a viable solution.

The Big Ramp photo by George E. Norkus.  FedRAMP has much opportunity for cool photos.

Similar Posts:

• Cloud Computing and the Government
• Categories of Security Controls in Outsourcing
• When the Feds Come Calling
• Some Thoughts on POA&M Abuse
• Observations on SP 800-37R1

• I Accidentally
• Marcus Ranum’s Ultimate Firewall

Similar Posts:

• LOLCATS Take on MS08-67
• LOLCATS and Firewalls
• Redundant Lolcats
• Lolcats Protect the End Users
• LOLCATS and #CapSec

That was followed by NASA’s “bold move” to change the way they manage risk…

Once again the over-emphasis and outright demagoguery on “compliance,” “FISMA reports,” “paper exercises,” and similar concepts that occupy our security geek thoughts have not given way to enlightenment. (At least “compliancy” wasn’t mentioned…) I was saddened by a return to the “FISMA BAD” school of thought so often espoused by the luminaries at SANS. Now NASA has leapt from the heights… At the risk of bashing Alan Paller yet again, I am often turned off by the approach of “being able to know the status of every machine at every minute, ” – as if machines by themselves cause bad security… It’s way too tactical (incorrect IMHO) and too easy to make that claim.

Hence the title of this rant – Machines don’t cause risk, people do!

The “people” I’m talking about are everyone from your agency director, down to the lowliest sysadmin… The problem? They may not be properly educated or lack the necessary skills for their position – another (excellent) point brought forth in the first article. Most importantly, even the most seasoned security veteran operating without a strategic vision within a comprehensive security program (trained people, budget, organizational will, technology and procedures) based upon the FISMA framework will be doomed to failure. Likewise, having all the “toys” in the world means nothing without a skilled labor force to operate them and analyze their output. (“He who dies with the most toys is still dead.”) Organizations and agency heads that do not develop and support a comprehensive security program that incorporates the NIST Risk Management Framework as well as the other facets listed above will FAIL. This is nothing new or revolutionary, except I don’t think we’ve really *done* FISMA yet. As I and others have said many times, it’s not about the paper, or the cost per page – it’s about the repeatable processes — and knowledgeable people — behind what the paper describes.

I also note the somewhat disingenuous mention of the risk management program at the State Department in the second article… As if that were all State was doing! What needs to be noted here is that State has approached security in the proper way, IMHO — from a Strategic, or Enterprise level. They have not thrown out the figurative baby with the bath water by dumping everything else in their security program in favor of the risk scoring system or some other bright, shiny object. I know first-hand from having worked with many elements in the diplomatic security hierarchy at State – these folks get it. They didn’t get to the current level of goodness in the program by decrying (dare I say whining about?) “paper.” They made the organizational commitment to providing contract vehicles for system owners to use to develop their security plans and document risk in Plans of Action and Milestones (POA&Ms). Then they provided the money to get it done. Is the State program a total “paragon of virtue?” Probably not, but the bottom line is that it’s an effective program.

Mammoth Strategy, Same as Last Year image by HikingArtist.com.

Desiring to know everything about everything may seem to some to be a worthy goal, but may be beyond many organization’s budgets. *Everything* is a point in time snapshot, no matter how many snapshots you take or how frequently you take them. Continuous, repeatable security processes followed by knowledgeable, responsible practitioners are what government needs. But you cannot develop these processes without starting from a larger, enterprise view. Successful organizations follow this–dare I say it–axiom whether discussing security governance, or system administration.

Government agencies need to concentrate on developing agency-wide security strategies that encompass, but do not concentrate on solely, what patch is on what machine, and what firewall has which policy. Likewise, system POA&Ms need to concentrate on higher-level strategic issues that affect agencies — things like changes to identity management schemes that will make working from home more practical and less risky for a larger percentage of the workforce. Or perhaps a dashboard system that provides the status of system authorization for the agency at-a-glance. “Burying your head in a foxhole” —becoming too tactical — is akin to burying it in the sand, or like getting lost in a bunch of trees that look like a forest. When organizations behave this way, everything becomes a threat, therefore they spray their resource firepower on the “threat of the day, or hour.”

An organization shouldn’t worry about patching servers if its perimeter security is non-existent. Developing the larger picture, while letting some bullets strike you, may allow you recognize threats, prioritize them, potentially allowing you to expend minimal resources to solve the largest problem. This approach is the one my organization is following today. It’s a crawl first, then walk, then run approach. It’s enabled management to identify, segregate, and protect critical information and resources while giving decision-makers solid information to make informed, risk-based decisions. We’ll get to the patches, but not until we’ve learned to crawl. Strangely, we don’t spend a lot of time or other organizational resources on “paper drills” — we’re actively performing security tasks, strategic and tactical that follow documented procedures, plans and workflows! Oh yes, there is the issue of scale. Sorry, I think over 250 sites in every country around the world, with over 62 different government customers tops most enterprises, government or otherwise, but then this isn’t about me or my organization’s accomplishments.

In my view, professional security education means providing at least two formal paths for security professionals – the one that SANS instantiates is excellent for administrators – i.e., folks operating on the tactical level. I believe we have these types of security practitioners in numbers. We currently lack sufficient seasoned professionals – inside government – who can approach security strategically, engaging agency management with plans that act both “globally” and “locally.” Folks like these exist in government but they are few. Many live in industry or the contractor space. Not even our intelligence community has a career path for security professionals! Government as a whole lacks a means to build competence in the security discipline. Somehow government agencies need to identify security up-and-comers within government and nurture them. What I’m calling for here is a government-sponsored internal mentorship program – having recognized winners in the security game mentor peers and subordinates.

Until we security practitioners can separate the hype from the facts, and can articulate these facts in terms management can understand and support, we will never get beyond the charlatans, headline grabbers and other “self-licking ice cream cones.” Some might even look upon this new, “bold initiative” by NASA as quitting at a game that’s seen by them as “too hard.” I doubt seriously that they tried to approach the problem using a non-academic, non-research approach. It needed to be said. Perhaps if the organization taking the “bold steps” were one that had succeeded at implementing the NIST guidance, there might be more followers, in greater numbers.

Perhaps it’s too hard because folks are merely staring at their organization’s navel and not looking at the larger picture?

Lastly, security needs to be approached strategically as well as tactically. As Sun Tzu said, “Tactics without strategy is the noise before defeat.”Similar Posts:

• A Funny Thing Happened Last Week on Capital Hill
• How to Not Let FISMA Become a Paperwork Exercise
• When the Feds Come Calling
• In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security
• Ooh, “The Word” is out on S 3474

• Controls that I provide to all customers as part of my baseline. In other words, these are things that I do for all of my customers because it’s either part of the way that I do business or it makes sense to do it once and scale it out to everybody.  Typically these are holistic information security program things (ISO 17799/27001/27002 or similar) matched up with my service-delivery architecture.
• Controls that I provide as an add-on service. Not all of my customers need these but I want to offer them to my customers to help them with their security program.  Usually these are services and products supporting a regulatory framework specific to one industry:  PCI-DSS, FISMA, GLBA, etc fit in here if my market is not exclusive to customers governed by those regulations.  In order to keep the base cost for the other customers low, these aren’t included in the base service but are available for a price.
• Controls that I am planning on building. I don’t have them yet but they’re on my roadmap.  Sometimes this is how I get into new markets by building the products and services that match up against the regulatory framework for that market, then build to that as a specification.
• Controls that I will not provide. Maybe this control doesn’t apply to my products and service (The “We don’t actually own a Windows/HP-UX/AIX server” problem).  Maybe the controls framework didn’t scope my solutions into its assumptions.  Maybe the economics of this didn’t work out.  Maybe I don’t provide this because it’s dishonest for both myself and you as my customer for me to say I provide this–think along the lines of accepting risk on your behalf which puts me into a conflict of interest.  This is why any vendor who says they provide 100% compliancy against FooFramework is lying.

Transparency ties it all together.  The good providers will tell you upfront which controls belong in which buckets.

Tool Bucket photo by tornatore.

Similar Posts:

• Security Assessment Economics
• When the Feds Come Calling
• NIST Cloud Conference Recap
• How to Not Let FISMA Become a Paperwork Exercise
• Split-Horizon Assessments and the Oversight Effect

Similar Posts:

• Senate Homeland Security Hearings and the Lieberman-Carper-Collins Bill
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 5
• A Funny Thing Happened Last Week on Capital Hill
• Why We Need PCI-DSS to Survive
• In Other News, I’m Saying “Nyet” on S.3474

It’s a small group (attendance is capped at 60), but if you’re managing security in Government, I want to encourage you to do 2 things:

• Submit a paper!
• Attend and learn.

I’ll be there doing a bit of hero-worship of my own with the Security Metrics folks.Similar Posts:

• Metricon 5 Wrapup
• NIST Framework for FISMA Dates Announced
• Certification and Accreditation Seminar, March 30th and 31st
• “Machines Don’t Cause Risk, People Do!”
• C&A Seminar in August, Instructor-to-Coolness Ratio Goes Up!

• Problemspace Definition: Give a point-of-view on a particular subject and why it is important.  Thinking more conventionally, what is it exactly that is your thesis statement?
• History of Incident: prove the problem is worth time to solve.  Usually this involves identifying a handful of large-scale incidents that can serve as the model for your analysis.  Looking at these incidents, what worked and what didn’t work? Start to form some opinions.  You will revisit these incidents later on as models.
• Regulatory Bodies: beginning of stakeholder definition.  Identify responsible Government or industry-specific organizations and their history of dealing with the problem.  What existing strategic plans and reports exist that you can use to feed your analysis.
• Private Sector Support: more stakeholders.  How much responsibility does private industry have in this issue and what is the impact on them?  They can be owners (critical infrastructure), vendors (hardware, software, firmware), maintainers, etc.
• Other Stakeholders: Consider end users, people who depend on the service that depends on the IT and the information therein.
• Trend and Metrics: what do we know about the topic given published metrics or our analysis of themes across our key incidents?  If you notice a lack of metrics on the subject, what would be your “wish list” and what plan do you have for getting these metrics?  For information security, this typically a huge gap–either we’re creating metrics to show where we’ve succeeded at the tactical level or we’re generating metrics with surveys which are notoriously flawed.
• Options and Alternatives Analysis: pros and cons, what evidence suggests each might succeed.  Take your model incidents and run your options through them, would they help with each scenario?  Gather up more incidents and see how the options would affect them.  As you run through each option and scenario, consider each of the following:
  • Efficacy of the Option–does it actually solve the root cause of the problem?
  • Winner Stakeholders
  • Loser Stakeholders
  • Audit Burden
  • Direct Costs
  • Indirect Costs
• Build Strategic Plan and Recommendations: Based on your analysis of the situation (model incidents, metrics, and power dynamics), build recommendations from the high-performing options and form them into a strategic plan.  The more specific you can get, the better.

Note that for the most part these are not exclusive to information security but to public policy analysis in general.  There are a couple parts that need emphasis because of the immature nature of infosec.

Analysis of Hound Dog Behavior graph by MShades. Our analysis is a little bit more in-depth.  =)

Then the criteria for evaluating the strategic plan and the analysis leading up to it:

• Has an opinion
• Backs up the opinion by using facts
• Has models that are used to test the options
• Lays out a well-defined plan

As usual, I stand on the shoulders of giants, in this case my Favorite Govie provided quite a bit of input in the form of our joint syllabus.Similar Posts:

• A Layered Model for Massively-Scaled Security Management
• Metricon 5 Wrapup
• Cyber Security coming to a boil
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4
• The World Asks: is S.773 Censorship?

Similar Posts:

• Beware the Audit Hammer
• Incident Response and Lolcats
• LOLCATS: Defending our Cyber-Turf
• IKANHAZFIZMA and Transparency
• Exhaustive Security Testing is Bad For You