A Layered Model for Massively-Scaled Security Management
Posted August 24th, 2009 by rybolovSo 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?
Similar Posts:
Posted in Public Policy | 6 Comments »
Tags: categorization • compliance • Cyberwar • dhs • fisma • government • infosec • infosharing • law • legislation • management • publicpolicy • scalability • security