Posted December 1st, 2009 by
rybolov
If you're new here and would like to see more of what I'm saying, you may want to subscribe to my RSS feed (I can even email my blog posts to you when I publish a new one) or have a look at my papers and presentations page for downloads of stuff that you can share or "borrow heavily from". You also might find my guidelines for posting comments interesting, especially if you're a government employee. If you want to see me blog about anything in particular, drop me a private email on how you think I'm completely full of myself, extend me an invitation to speak at your next security meeting/event, or just to ship a huge bag of money in my direction, you can do that through my contact page. Thanks for visiting and happy hacking!
OK, so it’s been a couple of months of thinking about this thing. I threw together a rainbow-looking beast that now occupies my spare brain cycles.

Rybolov’s Information Security Management Model
And some peculiarities of the model that I’ve noticed:
Regulation, Compliance, and Governance flows from the top to the bottom. Technical solutions flow from the bottom to the top.
The Enterprise (Layer 4) gets the squeeze. But you CISOs out there knew that already, right? It makes much sense in the typical information security world to focus on layers 3, 4, and 5 because you don’t usually own the top and the bottom of the management stack.
The security game is changing because of legislation at layers 5 and 6. Think national data breach law. It seems like the trend lately is to throw legislation at the problems with information security. The scary part to me is that they’re trying to take concepts that work at layers 3 and 4 and scale them up the model with very mixed results because there isn’t anybody doing studies at what happens above the Enterprise. Seriously here, we’re making legislation based on analogies.
Typically each layer only knows about the layer above and below it. This is a serious problem when you have people at layers 5 and 6 trying to create solutions that carry down to layers 1 through 4.
At layers 1 and 2, you have the greatest chance to solve the root causes of security problems. The big question here is “How do we get the people working at these layers the support that they need?”
Posted in Public Policy |
7 Comments »
Tags: government • infosec • legislation • management • publicpolicy • scalability • security
Posted October 16th, 2009 by
rybolov
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.
Posted in FISMA, NIST, Public Policy, Speaking, The Guerilla CISO, What Works |
No Comments »
Tags: catalogofcontrols • certification • compliance • fisma • government • infosec • infosharing • law • legislation • management • publicpolicy • scalability • scap • security • speaking
Posted August 24th, 2009 by
rybolov
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?
Posted in Public Policy |
5 Comments »
Tags: categorization • compliance • Cyberwar • dhs • fisma • government • infosec • infosharing • law • legislation • management • publicpolicy • scalability • security
Posted August 4th, 2009 by
rybolov
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.
Posted in Cyberwar, Public Policy, Rants, What Doesn't Work |
1 Comment »
Tags: Cyberwar • infosec • itsatrap • law • legislation • management • security
Posted June 11th, 2009 by
rybolov

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:
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!
Posted in Public Policy, Speaking |
No Comments »
Tags: collusion • datacentric • government • infosec • infosharing • law • legislation • privacy • publicpolicy • security • seminar • speaking • training