Dear Project Team

Effective immediately and due to recent events , you are forbidden to utter the following phrases:

Direct Connection. In our world, nothing connects directly.  I have many pieces of expensive kit between your webserver and the users out on the Internet.  They don’t connect directly at all, but when you use this phrase, we have to give the SOC Manager an adrenaline shot to get his heart restarted.  It’s a series of tubes with some valves in the way, get it?

What are Oracle CPUs. Look, one more time with this:  these are the quarterly patches that Oracle puts out.  No idea why they call them Critical Patch Updates except maybe because they’ve been reading their own “unbreakable” literature a bit too much.  I don’t care if you call them “Late to Supper” as long as you keep me happy by testing them in the lab as soon as they’re released.

System. Let’s just suffice it to say that in my world, a “System” is something different than what you call it.  Think 2 layers abstracted and larger than your idea.

Security Waiver. Please don’t ask the security staff directly about waivers.  They’ll only send you on a huge journey to circumnavigate a huge amount of paperwork.

Remote Access. Yep, we have it.  But look, you guys are database and applications geeks, leave the drawings to me because you keep drawing the Internet users inside of our network.

Missing. OK, so we have 200 laptops that we don’t know right now where they’re at.  But if we use the word “missing”, then I have to spin up the laptop SWAT team from US-CERT.  Henceforth and forever more throughout the world of IT, I am the person who can declare something as “missing”.  In the mean time, feel free to use the phrase “unaccounted for”.

Wireless, Bluetooth, WiFi. You need to know where I’m coming from on this one.  Whenever we have project meetings, there’s an auditor dialed into the phone call, just waiting for us to say any of these words.  Then they wake and pounce on us.  Mayhem ensues.

Financial Data. Yes, I understand you think of it as financial data but to me, your spreadsheet is a non-authoritative, non-source analytical tool for numbers that just happen to be derived from authoritative financial system sources.  When you claim that it’s financial data, you just made a ton of work in integrity controls that is just plain ludicrous.

Tons of Custom Code. When you talk to the user community, talk up your epic slaying of code dragons and the myriad pitfalls of doing so.  But when you talk to the security team, custom code implies that we need to do a ton of code review. The official phrase is “automation scripts to assist the users with their workflow” or “glue code to string together existing applications”.

Offshore Developers. I can barely get the security team to allow me to have developers at all, much less developers at a contractor site.  Yes, they might be people who happen to live not in the US who get paid to write code.  But when you talk to the auditor, we have a word for this stuff: COTS software.

Love you guys.  No, really, quit laughing.

–The BSOFH

• Everything I know about security, I learned from Ghostbusters…
• The BSOFH On Dorky, Auditor-Friendly Policies
• Some Thoughts on POA&M Abuse
• Beware the Cyber-Katrina!
• Your Security “Requirements” are Teh Suxxorz

Ah yes, the BSOFH is deep down inside every security manager doing all the things that we wish we could.  And so today we present a BSOFH in lolcat form.

For more BSOFH, check out posts here on guerilla-ciso and on layer8.

• The Authorizing Official and the Lolcat
• CIO Council Guidelines on Social Media Meet IKANHAZFIZMA
• Lolcats Coming to you from the Cloud
• LOLCATS Take on POA&Ms
• Exhaustive Security Testing is Bad For You

Our BSOFH meets a Crazy Homeless Guy on the street just outside the Pentagon City metro station.

Crazy Homeless Guy: (walks up to BSOFH) Can I ask you a question?

BSOFH: (Somewhat startled, nobody really talks to him unless they’re trying to sell him something) Uhhhh, sure.

Crazy Homeless Guy: You know that there are people who claim to be able to say… take that truck over there and just by moving their finger make it fly into the Washington Monument.  Don’t you think that this is a threat to national security?

BSOFH: (Realizes that Crazy Homeless Guy is crazy and homeless) Not necessarily, you see.  I would definitely classify it as a threat.  However, when you’re looking at threats from people, you have to look at motives, opportunity, and motives.  Until you have all three, it’s more of an unrealized threat.

Crazy Homeless Guy: But what if these same guys could kill the President the same way, isn’t that a national threat?

BSOFH: Um, could be.  But then again, let’s look at a similar analogy:  firearm ownership.  Millions of people safely own weapons and yet there isn’t this huge upswell to shoot the President now is there?  Really, we have laws against shooting people and when somebody does that, we find them and put them in jail or *something*.  We don’t criminalize the threat, we criminalize the action.  Flicking a finger doesn’t kill people, psycho people kill people.

Crazy Homeless Guy: Or even if these same people could use the same amount of effort to kill everybody on the planet.  You know the <censored, I don’t like being sued by cults> people claim to have this ability.

BSOFH: (Jokingly, realizing that somebody has been taking 4chan too seriously) Well, I wouldn’t care too much because I would be… well, dead.  But yes, possibly.  But then again, since the dawn of the nuclear age and all through the Cold War we’ve had similar threats and people with capabilities created by technology instead of word study and the power of the human mind.  You have to look at these things from a risk standpoint.  While yes, these people have the capability to do something of high impact such as kill every human on the face of the earth, the track record of something like this happening is relatively small.  I mean, is there any historical record of a <censored, I don’t like being sued by cults> actually killing anybody through sheer force of their mind?  In other words, this is a very high impact, low probability event–something some people call a black swan event.  While yes, this is a matter of national security that these people potentially have this capability, we only have so many resources to protect things and we have our hands full dealing with risks that actually have occured in recent history.  In other words, risk management would say that this event you’re speaking of is an acceptable risk because of more pressing risks.

Crazy Homeless Guy: (Obviously beaten into oblivion by somebody crazier than himself) Well, I’ve never thought about it that way.  I’m really scared by these people.  Hold me, BSOFH.

BSOFH: Um, how about no?  You’re a Crazy Homeless Guy after all.  I have to get back to work now.  Come hang out sometime if you want to talk some quantitative risk analysis and we’ll start attaching dollar figures to the risks of <censored, I don’t like being sued by cults> killing all of humanity.  Doesn’t that sound like fun?  If we can get you cleared to get into the building, we can have a couple of whiteboarding sessions to determine the process flow and maybe an 800-30-stylie risk assessment just to present our case to the DHS Psychic Warfare Division.

Crazy Homeless Guy: Uh, I gotta find a better corner to stand on.  Maybe over by 16th and Pennsylvania I can find somebody more sympathetic to my cause.

BSOFH: You’re crazy, man!

Crazy Homeless Guy: You’re crazy, too, man!

And the moral of the story is that no matter how crazy you think you are, somebody else will always show up to prove you wrong.  And yeah, black swan events where we all die are dumb to prepare for because we’ll all be dead–near total fatalities only matter if you’re one of the survivors.

This story is dedicated to Alex H, David M, and some guy named Bayes.

OMG It’s a Psychic Black Swan photo by gnuckx cc0.

• Working with Interpreters, a Risk Manager’s Guide
• Web 2.0 and Social Media Threats for Government
• “Machines Don’t Cause Risk, People Do!”
• Security Assessments as Fraud, Waste, and Abuse
• Everything I know about security, I learned from Ghostbusters…

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
• Opportunity Costs and the 20 Critical Security Controls
• 20 Critical Security Controls: Control-by-Control
• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• NIST Cloud Conference Recap

Ack, Plans of Action and Milestones.  I love them and I hate them.

For those of you who “don’t habla Federali”, a POA&M is basically an IOU from the system owner to the accreditor that yes, we will fix something but for some reason we can’t do it right now.  Usually these are findings from Security Test and Evaluation (ST&E) or Certification and Accreditation (C&A).  In fact, some places I’ve worked, they won’t make new POA&Ms unless they’re traceable back to ST&E results.

Functions that a POA&M fulfills:

• Issue tracking to resolution
• Serves as a “risk register”
• Used as the justification for budget
• Generate mitigation metrics
• Can be used for data-mining to find common vulnerabilities across systems

But today, we’re going to talk about POA&M abuse.  I’ve seen my fair share of this.

Conflicting Goals: The basic problem is that we want POA&Ms to satisfy too many conflicting functions.  IE, if we use the number of open POA&Ms as a metric to determine if our system owners are doing their job and closing out issues but we also turn around and report these at an enterprise level to OMB or at the department level, then it’s a conflict of interest to get these closed as fast as possible, even if it means losing your ability to track things at the system level or to spend the time doing things that solve long-term security problems–our vulnerability/weakness/risk management process forces us into creating small, easily-to-satisfy POA&Ms instead of long-term projects.

Near-Term v/s Long-Term:  If we set up POA&Ms with due dates of 30-60-90 (for high, moderate, and low risks) days, we don’t really have time at all to turn these POA&Ms into budget support.  Well, if we manage the budget up to 3 years in advance and we have 90 days for high-risk findings, then that means we’ll have exactly 0 input into the budget from any POA&M unless we can delay the bugger for 2 years or so, much too long for it to actually be fixable.

Bad POA&Ms:  Let’s face it, sometimes the one-for-one nature of ST&E, C&A, and risk assessment findings to POA&Ms means that you get POA&Ms that are “bad” and by that I mean that they can’t be satisfied or they’re not really something that you need to fix.

Some of the bad POA&Ms I’ve seen, these are paraphrased from the original:

• The solution uses {Microsoft|Sun|Oracle} products which has a history of vulnerabilities.
• The project team needs to tell the vendor to put IPV6 into their product roadmap
• The project team needs to implement X which is a common control provided at the enterprise level
• The System Owner and DAA have accepted this risk but we’re still turning it into a POA&M
• This is a common control that we really should handle at the enterprise level but we’re putting it on your POA&M list for a simple web application

Plan of Action for Refresh Philly photo by jonny goldstein.

Keys to POA&M Nirvana:  So over the years, I’ve observed some techniques for success in working with POA&Ms:

• Agree on the evidence/proof of POA&M closure when the POA&M is created
• Fix it before it becomes a POA&M
• Have a waiver or exception process that requires a cost-benefit-risk analysis
• Start with”high-level” POA&Ms and work down to more detailed POA&Ms as your security program matures
• POA&Ms are between the System Owner and the DAA, but the System Owner can turn around and negotiate a POA&M as a cedural with an outsourced IT provider

And then the keys to Building Good POA&Ms:

• Actionable–ie, they have something that you need to do
• Achievable–they can be accomplished
• Demonstrable–you can demonstrate that the POA&M has been satisfied
• Properly-Scoped–absorbed at the agency level, the common control level, or the system level
• They are SMART: Specific, Manageable, Attainable, Relevant, and within a specified Timeframe
• They are DUMB: Doable, Understandable, Manageable, and Beneficial

Yes, I stole the last 2 bullets from the picture above, but they make really good sense in a way that “know thyself” is awesome advice from the Oracle at Delphi.

• Security Assessments as Fraud, Waste, and Abuse
• Observations on SP 800-37R1
• Reinventing FedRAMP
• How to Not Let FISMA Become a Paperwork Exercise
• NIST Cloud Conference Recap

“Drawn” by an infosec engineer known simply as “TomBot” and passed down in email for years.  Click the diagram to get a bigger version.

Network Diagram by TomBot.

• Et Tu, TIC?
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• When Standards Aren’t Good Enough
• Security Assessment Economics
• A Step Inside the Guerilla CISO’s Mind