My presentation slides from Sector 2009.  This was a really fun conference, the Ontario people are really, really nice.

Presentation Abstract:

The US Federal Government is the world’s largest consumer of IT products and, by extension, one of the largest consumers of IT security products and services. This talk covers some of the problems with security on such a massive scale; how and why some technical, operational, and managerial solutions are working or not working; and how these lessons can be applied to smaller-scale security environments.

• A Layered Model for Massively-Scaled Security Management
• Metricon 5 Wrapup
• DojoCon 2009 Presentation
• Where is Rybolov?
• Building A Modern Security Policy For Social Media and Government

A phenomenal cartoon that reflects the true depth of discussion on S.773.  You may now return to your regularly-scheduled hacking.

Hat tip to Dan Philpott.

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

So we all know the OSI model by heart, right?   Well, I’m offering up my model of technology management. Really at this stage I’m looking for feedback

• Layer 7: Global Layer. This layer is regulated by treaties with other nation-states or international standards.  I fit cybercrime treaties in here along with the RFCs that make the Internet work.  Problem is that security hasn’t really reached much to this level unless you want to consider multinational vendors and top-level cert coordination centers like CERT-CC.
• Layer 6: National-Level Layer. This layer is an aggregation of Federations and industries and primarily consists of Federal law and everything lumped into a “critical infrastructure” bucket.  Most US Federal laws fit into this layer.
• Layer 5: Federation/Community Layer. What I’m talking here with this layer is an industry federated or formed in some sort of community.  Think major verticals such as energy supply.  It’s not a coincidence that this layer lines up with DHS’s critical infrastructure and key resources breakdown but it can also refer to self-regulated industries such as the function of PCI-DSS or NERC.
• Layer 4: Enterprise Layer. Most security thought, products, and tools are focused on this layer and the layers below.  This is the realm of the CSO and CISO and roughly equates to a large corporation.
• Layer 3: Project Layer. Collecting disparate technologies and data into a similar piece such as the LAN/WAN, a web application project, etc.  In the Government world, this is the location for the Information System Security Officer (ISSO) or the System Security Engineer (SSE).
• Layer 2: Integration Layer. Hardware, software, and firmware combine to become products and solutions and is focused primarily on engineering.
• Layer 1: Code Layer. Down into the code that makes everything work.  This is where the application security people live.

There are tons of way to use the model.I’m thinking each layer has a set of characteristics like the following:

• Scope
• Level of centralization
• Responsiveness
• Domain expertise
• Authority
• Timeliness
• Stakeholders
• Regulatory bodies
• Many more that I haven’t thought about yet

Chocolate Layer Cake photo by foooooey.

My whole point for this model is that I’m going to try to use it to describe the levels at which a particular problem resides at and to stimulate discussion on what is the appropriate level at which to solve it.  For instance, take a technology and you can trace it up and down the stack. Say Security Event and Incident Monitoring:

• Layer 7: Global Layer. Coordination between national-level CERTs in stopping malware and hacking attacks.
• Layer 6: National-Level Layer. Attack data from Layer 5 is aggregated and correlated to respond to large incidents on the scale of Cyberwar.
• Layer 5: Federation/Community Layer. Events are filtered from Layer 4 and only the confirmed events or interest are correlated to determine trends.
• Layer 4: Enterprise Layer. Events are aggregated by a SIEM with events of interest flagged for response.
• Layer 3: Project Layer. Logs are analyzed in some manner.  This is most likely the highest in the model that we
• Layer 2: Integration Layer. Event logs have to be written to disk and stored for a period of time.
• Layer 1: Code Layer. Code has to be programmed to create event logs.

I do have an ulterior motive.  I created this model because most of our security thought, doctrine, tools, products, and solutions work at Layer 4 and below.  What we need is discussion on Layers 5 and above because when we try to create massively-scaled security solutions, we start to run into a drought of information at what to do above the Enterprise.  There are other bits of doctrine that I want to bring up, like trying to solve any problem at the lowest level for which it makes sense.  So in other words, we can use the model to propose changes to the way we manage security… say we have a problem like the lack of data on data breaches.  What we’re saying when we say that we need a Federal data breach law is that because of the scope and the amount of responsibility and competing interests at Layer 5, that we need a solution at Layer 6, but in any case we should start at the bottom and work our way up the model until we find an adequate scope and scale.

So, this is my question to you, Internet: have I just reinvented enterprise public policy, IT architecture (Federal Enterprise Architecture) and business blueprinting, or did I create some kind of derivative view of technology, security, and public policy that I can now use?

• More on the Rybolov Information Security Management Model
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4
• Massively Scaled Security Solutions for Massively Scaled IT
• In Response to “Cyber Security Coming to a Boil” Comments….
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3

So let me give you a hypothetical job:

• You have to give up your high-paying private-sector job to be a Government employee
• You have tons of responsibility
• You have no real authority
• You have no dedicated budget
• You have no staffers
• The job has had half a dozen people filling it in the last 7 years
• The job has been open longer than it’s been staffed over the past 7 years

And yet this is what we’re asking candidates to do in order to even be a candidate for the Cybersecurity Coordinator.  Yes, this is the exact same problem that all CISOs have with having a huge helping of responsibility and none of the authority to get things done, only we scaled it up and out to a national-level CISO position.

Somebody’s even gone as far to say that the lack of candidates for the job is the security field’s way of sending the message that you didn’t scope the job right.  I think this opinion has much merit.  CISOs being what they are, they’re usually pretty astute at walking into an ambush, and this job has all the makings of a good one.

I’ll even turn it around the other way and say that the security industry has yet to produce a CISO’s CISO–somebody who can do politics, budget, security, IT, and consensus-building all in one person.  We have lots of people who can manage the enterprise and below, but it’s that additional little bit of political intrigue that is what we’re missing.  Security people usually avoid politics like the bubonic plague because we’re an industry full of people who say it like it really is.  This is a detriment in sales and politics.

So in true Guerilla-CISO fashion of not pointing out problems without offering something as a fix (no matter how much of a strawman arguement it really is), this is what we need to do to get people interested in being the Cybersecurity Czar^wCoordinator:

• A really well-defined scope.  One person cannot do everything that we are asking for at this price (or any price for that matter).
• A budget for an operating staff where the number is more than than 8 digits.
• Statutory authority over the various departments and agencies responsible for cybersecurity: NCSD, S&T, DoJ, FBI, Commerce.  Indirect influence doesn’t work here, never has.
• The direct ear of the President.  Councils are OK, but puhlease, you want to get the job done, this is what it will take.

Then I read back through my list and realized that we really do need a law to create the Cybersecurity Czar position with everything that I just mentioned.  But here’s the rub: legislation is slow, the bills to make the Cybersecurity Czar aren’t even going to be looked at until the next congressional session because we’re still trying to figure out the budget for last year.

I also think that what we’re calling the Cybersecurity Czar is really 2 jobs.  You need somebody working for the Government CIO Vivek Kundra as the executive-branch CISO and you need a more senior person who worries about the military-industrial base, the critical infrastructure, the support to American commerce, and the protection of little old grandmas who represent the end-users.

Tsar’s Cannon photo by Siyad Ma.  Now that’s some teeth for the position.

• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 5
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4
• Next Up in Security Legislation: S3474
• Cyber Security coming to a boil
• A Layered Model for Massively-Scaled Security Management

Saturday, June 20, 2009 from 8:00 AM – 5:00 PM (ET) in downtown DC.

I’ll be going.  This will be a “Bar Camp Stylie” event, where you’re not just an attendee, you’re also a volunteer to make it all happen.  You might end up running a conversation on your favorite privacy topic, so you have been warned. =)

*Most* of the folks going are of the civil libertarian slant.  With my background and where I work, I usually “bat for the other team on this issue”.  The organizers have assured me that I’ll be welcome and can play the heretic role.

How to play:

• Sign up here.
• Check out the wiki, help out with preparation.
• Follow @PrivacyCampDC on twitter
• Be a sponsor.

Some themes that I’ve seen develop so far:

• How some concepts (System of Record) from the Privacy Act are outdated or at least showing their age
• How the open government “movement” and the push for raw data means we need to look at the privacy concerns
• FOIA and privacy data
• Ending the political robocalls

See Y’all there!

• Privacy Camp DC–April 17th
• Certification and Accreditation Seminar, March 30th and 31st
• NIST Framework for FISMA Dates Announced
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3

And by “We”, I mean the security industry as a whole.  And yes, this is your public-policy lesson for today, let me drag my soapbox over here and sit for a spell while I talk at you.

By “Survive”, I mean that we need some kind of self-regulatory framework that fulfills the niche that PCI-DSS occupies currently. Keep reading, I’ll explain.

And the “Why” is a magical phrase, everybody say it after me: self-regulatory organization.  In other words, the IT industry (and the Payment Card Industry) needs to regulate itself before it crosses the line into being considered for statutory regulation (ie, making a law) by the Federal Government.

Remember the PCI-DSS hearings with the House Committe on Homeland Security (AKA the Thompson Committee)?  All the Security Twits were abuzz about it, and it did my heart great justice to hear all the cool kids become security and public policy wonks at least for an afternoon.  Well, there is a little secret here and that is that when Congress gets involved, they’re gathering information to determine if they need to regulate an industry.  That’s about all Congress can do: make laws that you (and the Executive Branch) have to follow, maybe divvy up some tax money, and bring people in to testify.  Other than that, it’s just positioning to gain favor with other politicians and maybe some votes in the next election.

Regulation means audits and more compliance.  They go together like TCP and IP.  Most regulatory laws have at least some designation for a party who will perform oversight.  They have to do this because, well, if you’re not audited/assessed/evaluated/whatever, then it’s really an optional law, which doesn’t make sense at all.

Yay Audits photo by joebeone.

Another magical phrase that the public policy sector can share with the information security world: audit burden.  Audit burden is how much a company or individual pays both in direct costs (paying the auditors) and in indirect costs (babysitting the auditors, producing evidence for the auditors, taking people away from making money to talk to auditors, “audit requirements”, etc).  I think we can all agree that low audit burden is good, high audit burden is bad.  In fact, I think that’s one of the problems with FISMA as implemented is that it has a high audit burden with moderately tangible results. But I digress, this post is about PCI-DSS.

There’s even a concept that is mulling around in the back of my head to make a metric that compares the audit burden to the amount of security that it provides to the amount of assurance that it provides against statutory regulation.  It almost sounds like the start of a balanced scorecard for security management frameworks, now if I could get @alexhutton to jump on it, his quant brain would churn out great things in short order.

But this is the lesson for today: self-regulation is preferrable to legislation.

• Self-regulation is defined by people in the industry.  Think about the State Bar Association setting the standards for who is allowed to practice law.
• Standards ideally become codified versions of “best practices”.  OK, this is if they’re done correctly, more to follow.
• Standards are more flexible than laws.  As hard/cumbersome as it is to change a standard, the time involved in changing a law is prohibitive most of the time unless you’re running for reelection.
• Standards sometimes can be “tainted” to force out competition, laws are even more so.

The sad fact here is that if we don’t figure out as an industry how to make PCI-DSS or any other forms of self-regulation work, Congress will regulate for us.  Don’t like PCI-DSS because of the audit burden, wait until you have a law that requires you to do the same controls framework.  It will be the same thing, only with bigger penalties for failure, larger audit burdens to avoid the larger penalties, larger industries created to satisfy the market demand for audit.  Come meet the new regulatory body, same as the old only bigger and meaner. =)

However, self-regulation works if you do it right, and by right I mean this:

• The process is transparent and not the product of a secret back-room cabbal.
• Representation from all the shareholders.  For PCI-DSS, that would be Visa/MasterCard, banks, processors, large merchants, small merchants, and some of the actual customers.
• The standards committee knows how to compromise and come to a consensus.  IE, we can’t have both full hard drive encryption, a WAF, code review, and sacrificing of chickens in the server room, so we’ll make one of the 4 mandatory.
• The regulatory organization has a grievance process for its constituency to present valid (AKA “Not just more whining”) discrepencies in the standards and processes for clarification or consideration for change.
• The standard is “owned” by every member of the constituency.  Right now, people governed by PCI-DSS are not feeling that the standard is their standard and that they have a say in what comprises the standard and that they are the ones being helped by the standard.  Some of that is true, some of that is an image problem.  The way you combat this is by doing the things that I mentioned in the previous bullets.

Hmm, sounds like making an ISO standard, which brings its own set of politics.

While we need some form of self-regulation, right now PCI-DSS and ISO 27001 are the closest that we have in the private sector.  Yeah, it sucks, but it sucks the least, just like our form of government.

• Observations on PCI-DSS and Circular Arguments
• Metricon 5 Wrapup
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3
• Preliminary Findings on Cybersecurity Review Now Out
• “Machines Don’t Cause Risk, People Do!”