Going Off the Deep End

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.

• 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!”

OK, since everybody seems to think that FISMA is some evil thing that needs reform, this is the version of events on “Planet Rybolov”:

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.

• “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

A few weeks back I read an article on an apparent shift in emphasis in government security… “OMB outlines shift on FISMA” take a moment to give it a read. I’ll wait….

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.”

• 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

OK, I know you’re shocked…I’m saying something controversial.  But hear me out on this one, I’ll explain.

Now this is my major beef with the way we write SSPs today:  this is all information that is contained in other artifacts that I have to pay people to do cut-and-paste to get it into a SSP template.  As practiced, we seriously have a problem with polyinstantiation of data in various lifecycle artifacts that is cut-and-pasted into an SSP.  Every time you change the upstream document, you create a difference between that document and the SSP.

This is a practice I would like to change, but I can’t do it all by myself.

This is the skeleton outline of an SSP from Special Publication 800-18, the guide to writing an SSP:

1. Information System Name/Title–On the investment/FISMA inventory, the Exhibit 300/53, etc
2. Information System Categorization–usually on a FIPS-199 memorandum
3. Information System Owner–In an assignment memo
4. Authorizing Official–In an assignment memo
5. Other Designated Contacts–In an assignment memo
6. Assignment of Security Responsibility–In assignment memos
7. Information System Operational Status–On the investment/FISMA inventory, the Exhibit 300/53, etc
8. Information System Type–On the investment/FISMA inventory, the Exhibit 300/53, etc
9. General System Description/Purpose–In the design document, Exhibit 300/53
10. System Environment–Common controls not inside the scope of our system
11. System Interconnections/Information Sharing–from Interconnection Security Agreements
12. Related Laws/Regulations/Policies–Should be part of the system categorization but hardly ever is on templates
13. Minimum Security Controls–800-53 controls descriptions which can easily be done in a Requirements Traceability Matrix
14. Information System Security Plan Completion Date–specific to each document
15. Information System Security Plan Approval Date–specific to each document

Now some of this has changed in practice a little bit–# 10 can functionally be replaced with a designation of common controls and hybrid controls.

So my line of thinking is that if we provide a 2-6-page system description with the names of the “guilty parties” and some inventory information, controls-specific Requirements Traceability Matrix, and a System Design Document, then we have the functional equivalent of an SSP.

Why have I declared an InfoSec fatwah against SSPs as currently practiced?

Well, my philosophy for operation is based on some concepts I’ve picked up through the years:

• Why run when you can walk, why walk when you can sit, why sit when you can lay down.  There is a time to spend effort on determining what the security controls are for a project.  You need to have them documented but it’s not cost-effective to be worried about format, which we do probably too much of today.
• Make it easy to do the right thing.  If we polyinstantiate security information, we have made something harder to maintain.  Easier to maintain means that it will get maintained instead of being shelfware.  I would rather have updated and accurate security information than overly verbose and well-polished documents that are inaccurate.
• Security is not a “security guy thing”–most problems are actually a management and project team problem.  My idea uses their SDLC artifacts instead of security-specific versions of artifacts.  My idea puts the project problems back in the project space where it belongs.
• If I have a security engineer who has a finite amount of hours in a day, I have to choose what they spend their time on.  If it’s a matter of vulnerability mitigation, patching, etc, or correcting SSP grammar, I know what I want him to do.  Then again, I’m still an infantryman deep down inside and I realize I have biases against flowery writing.

Criticisms to not writing a dedicated SSP document:

“My auditors are used to seeing the information in the same format at someplace they worked previously”. Believe it or not, I hear this quite a bit.  My response is along the lines of the fact that if you make your standard be what I’m suggesting for a security plan, then you’ve met all of the FISMA and 800-53 requirements and my personal requirement to “don’t do stupid stuff if you can help it”.

“My auditors will grill me to death if they have to page back and forth between several documents”.  This one also I’ve heard.  There are a couple of ways to deal with this.  One way to deal with this is that in your 800-53 Requirements Traceability Matrix you reference the source document.  Most auditors at this point bring up that you need to reference the official name, date of publication, and specific page/section of the reference and I think they need to get a life because they’ve taken us back to the maintainability problem.

“This is all too new-school and I can’t get over it”. Then you are a dinosaur and your kind deserves extinction.  =)

.

This blog post is for grecs at novainfosecportal.com who perked up instantly when I mentioned the concept months ago.  Finally got around to putting the text somewhere.

How to Plan the Perfect Dinner Party photo by kevindooley.

• Old Saint NIST: Ho Ho Hold on, what’s this?
• How to Not Let FISMA Become a Paperwork Exercise
• When the Feds Come Calling
• OMB Wants a Direct Report
• Opportunity Costs and the 20 Critical Security Controls

Eh? What’s that mean?  Developer Days is a weeklong conference where they get down into the weeds about the various SCAP schemas and how they fit into the overall program of security automation. 

Highlights and new ideas:

Remedial Markup Language: Fledgeling schema to describe how to remediate a vulnerability.  A fully automated security system would scan and then use the RML content to automagically fix the finding… say, changing a configuration setting or installing a patch.  this would be much awesome if combined with the CVE/CWE so you have a vulnerability scanner that scans and fixes the problem.  Also needs to be kept in a bottle because the operations guys will have a heartattack if we are doing this without any human intervention.

Computer Network Defense: There is a pretty good scenario slide deck on using SCAP to automate hardening, auditing, monitoring, and defense.  The key from this deck is how the information flows using automation.

Common Control Identifier:  This schema is basically a catalog of controls (800-53, 8500.2, PCI, SoX, etc) in XML.  The awesomeness with this is that one control can contain a reference implementation for each technology and the checklist to validate it in XCCDF.  At this point, I get all misty…

Open Checklist Interactive Language: This schema is to capture questionaires.  Think managerial controls, operational controls, policy, and procedure captured in electronic format and fed into the regular mitigation and workflow tools that you use so that you can view “security of the enterprise at a glance” across technical and non-technical security.

Network Event Content Automation Protocol:  This is just a concept floating around right now on using XML to describe and automate responses to attacks.  If you’re familiar with ArcSight’s Common Event Format, this would be something similar but on steroids with workflow and a pony!

Attendance at developer days is limited, but thanks to all the “Powar of teh Intarwebs, you can go here and read the slides!

• Comments on SCAP 2008
• Save a Kitten, Write SCAP Content
• NIST and SCAP; Busting a cap on intruders Part 1
• Ed Bellis’s Little SCAP Project
• Federated Vulnerability Management

Face it, your security requirements suck. I’ll tell you why.  You write down controls verbatim from your catalog of controls (800-53, SoX, PCI, 27001, etc), put it into a contract, and wonder how come when it comes time for security testing, we just aren’t talking the same language.  Even worse, you put in the cr*ptastic “Contractor shall be compliant with FISMA and all applicable NIST standards”.  Yes, this happens more often than I could ever care to count, and I’ve seen it from both sides.

The problem with quoting back the “requirements” from a catalog of controls is that they’re not really requirements, they’re control objectives–abstract representations of what you need in order to protect your data, IT system, or business.  It’s a bit like brain surgery using a hammer and chisel–yes, it might work out for you, but I don’t really feel comfortable doing it or being on the receiving end.

And this is my beef with the way we manage security controls nowadays.  They’re not requirements, functionally they’re a high-level needs statement or even a security concept of operations.  Security controls need to be tailored into real requirements that are buildable, testable, measurable, and achievable.

Requirements photo by yummiec00kies.  There’s a social commentary in there about “Single, slim, and pleasant looking” but even I’m afraid to touch that one. =)

Did you say “Wrecks and Female Pigs’? In the contracting world, we have 2 vehicles that we use primarily for security controls: Statements of Work (SOW) and Engineering Requirements.

• Statements of Work follow along the lines of activities performed by people.  For instance, “contractor shall perform monthly 100% vulnerability scanning of the $FooProject.”
• Engineering Requirements are exactly what you want to have build.  For instance, “Prior to displaying the login screen, the application shall display the approved Generic Government Agency warning banner as shown below…”

Let’s have a quick exercise, shall we?

What 800-53 says: The information system produces audit records that contain sufficient information to, at a minimum, establish what type of event occurred, when (date and time) the event occurred, where the event occurred, the source of the event, the outcome (success or failure) of the event, and the identity of any user/subject associated with the event.

How It gets translated into a contract: Since it’s more along the lines of a security functional requirement (ie, it’s a specific functionality not a task we want people to do), we brake it out into multiple requirements:

The $BarApplication shall produce audit records with the following content:

• Event description such as the following:
  • Access the $Baz subsystem
  • Mounting external hard drive
  • Connecting to database
  • User entered administrator mode
• Date/time stamp in ‘YYYY-MM-DD HH:MM:SS’ format;
• Hostname where the event occured;
• Process name or program that generated the event;
• Outcome of the event as one of the following: success, warn, or fail; and
• Username and UserID that generated the event.

For a COTS product (ie, Windows 2003 server, Cisco IOS), when it comes to logging, I get what I get, and this means I don’t have a requirement for logging unless I’m designing the engineering requirements for Windows.

What 800-53 says: The The organization configures the information system to provide only essential capabilities and specifically prohibits and/or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined list of prohibited and/or restricted functions, ports, protocols, and/or services].

How It gets translated into a contract: Since it’s more along the lines of a security functional requirement, we brake it out into multiple requirements:

The $Barsystem shall have the software firewall turned on and only the following traffic shall be allowed:

• TCP port 443 to the command server
• UDP port 123 to the time server at this address
• etc…..

If we drop the system into a pre-existing infrastructure, we don’t need firewall rules per-se as part of the requirements, what we do need is a SOW along the following lines:

The system shall use our approved process for firewall change control, see a copy here…

So what’s missing, and how do we fix the sorry state of requirements?

This is the interesting part, and right now I’m not sure if we can, given the state of the industry and the infosec labor shortage:  we need security engineers who understand engineering requirements and project management in addition to vulnerability management.

Don’t abandon hope yet, let’s look at some things that can help….

Security requirements are a “best effort” proposition.  By this, I mean that we have our requirements and they don’t fit in all cases, so what we do is we throw them out there and if you can’t meet the requirement, we waiver it (live with it, hope for the best) or apply a compensating control (shield it from bad things happening).  This is unnerving because what we end up doing is arguing all the time over whether the requirements that were written need to be done or not.  This drives the engineers nuts.

It’s a significant amount of work to translate control objectives into requirements.  The easiest, fastest way to fix the “controls view” of a project is to scope out things that are provided by infrastructure or by policies and procedures at the enterprise level.  Hmmm, sounds like explicitly stating what our shared/common controls are.

You can manage controls by exclusion or inclusion:

• Inclusion:  We have a “default null” for controls and we will explicitly say in the requirements what controls you do need.  This works for small projects like standing up a pair of webservers in an existing infrastructure.
• Exclusion:  We give you the entire catalog of controls and then tell you which ones don’t apply to you.  This works best with large projects such as the outsourcing of an entire IT department.

We need a reference implementation per technology.  Let’s face it, how many times have I taken the 800-53 controls and broken them down into controls relevant for a desktop OS?  At least 5 in the last 3 years.  The way you really need to do this is that you have a hardening guide and that is the authoritative set of requirements for that technology.  It makes life simple.  Not that I’m saying deviate from doctrine and don’t do 800-53 controls and 800-53A test procedures, but that’s the point of having a hardening guide–it’s really just a set of tailored controls specific to a certain technology type.  The work has been done for you, quit trying to re-engineer the wheel.

Use a Joint Responsibilities Matrix.  Basically this breaks down the catalog of controls into the following columns:

• Control Designator
• Control Title
• Provided by the Government/Infrastructure/Common Control
• Provided by the Contractor/Project Team/Engineer

• When Standards Aren’t Good Enough
• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• Opportunity Costs and the 20 Critical Security Controls
• 20 Critical Security Controls: Control-by-Control
• NIST Cloud Conference Recap