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.
Similar Posts:
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 September 21st, 2009 by
rybolov
Due to the the CIO Council’s Guidelines on Social Media being carried by, well, just about everybody out there who can spell “Gov 2.0” (including the crazy folks at GovTwit), we here at the Guerilla CISO have decided to release an out-of-cycle lolcat to commemorate the event.
Similar Posts:
Posted in IKANHAZFIZMA | 1 Comment »
Tags: gov20 • government • infosec • lolcats • publicpolicy • socialnetworking
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?
Similar Posts:
Posted in Public Policy | 6 Comments »
Tags: categorization • compliance • Cyberwar • dhs • fisma • government • infosec • infosharing • law • legislation • management • publicpolicy • scalability • security
Posted July 22nd, 2009 by
rybolov
Somedays I feel like people are reading this blog and getting ideas that they turn around and steal. Then I take my pills and my semi-narcisistic feelings go away. =)
So anyway, B|A|H threw me for a loop this afternoon. They released a report on the cybersecurity workforce. You can check out the article on The Register or you can go get the report from here. Surprise, we don’t have anywhere near enough security people to go around. I’ve been saying this for years, I think B|A|H is stealing my ideas by using Van Eck phreaking on my brain while I sleep.
Some revelations from the executive summary:
- The pipeline of potential new talent is inadequate. In other words, demand is growing and the amount of people that we’re training is not growing to meet the demand.
- Fragmented governance and uncoordinated leadership hinders the ability to meet federal cybersecurity workforce needs. Nobody’s so far been able to articulate how we build an adequate supply of security folks to keep up with demand and most of our efforts have been at the execution level.
- Complicated processes and rules hamper recruiting and retention efforts. It takes maybe 6 months to hire a government employee, this is entirely unsatisfactory. My current project I was cleared for for 3 years, took a 9-month break, and it took me 6 months to get cleared again.
- There is a disconnect between front-line hiring managers and government’s HR specialists. Since the HR folks don’t know what the real job description is, hiring information security people is akin to buzzword bingo.
These are all the same problems the private sector deals with, only in true Government stylie, we have it on a larger scale.
He’s Part of the Workforce photo by pfig.
Now for the things that no self-respecting contractor will admit (hmm, what does this say about me? I’m not sure yet)….
If you do not have an adequate supply of workers in the industry, outsourcing cybersecurity tasks to contractors will not work. It works something like this:
- High Demand = High Bill Rate.
- High Bill Rate = More Contractor Interest
- More Contractor Interest + High Bill Rate + Low Supply = High Rate of Charlatans
Contractors do not have the labor pool to tap into to satisfy their contracts. If you want to put on your cynic hat (all the Guerilla-CISO staff have theirs permanently attached with wood screws), you could say that the B|A|H report was trying to get the Government to pump more money into workforce development so that they could then hire those people and bill them back to the Government. It’s a twisted world, folks.
Current contractor labor pools have some of the skills necessary for cybersecurity but not all. More info in future blog posts, but I think a simple way to summarize it is to say that our current workforce is “tooled” around IT security compliance and that we are lacking in large-scale attack and defense skills.
Not only do we need more people in the security industry, but we need more security people in Government. There is a set of tasks called “inherent government functions” that cannot be delegated to contractors. Even if you solely increase the contractor headcount, you still have to increase the government employee headcount in order to manage the contractors.
Similar Posts:
Posted in Outsourcing, Public Policy | 9 Comments »
Tags: cashcows • clearances • Cyberwar • government • infosec • moneymoneymoney • publicpolicy • pwnage • risk • scalability • security • training