Shifting

Landscape

Strategic Security Model

presents...

Salsa-CSI2 c/o Brian Smith-Sweeney bsmithsweeney@nyu.edu @bsmithsweeney

Previously on the Shifting Landscape...

What the hell's going on here? Cosmo, what... what happened?

The world changed on us, Marty.

And without our help.

ESA

NIST

ITIL
COBIT

CMMI
(zomg)

You'd like to be here This is more likely

You are here

Thankfully, we've got lots in Common

Common drivers Common environment Common interest

The Plan?

Model Document Library Web 2.2.5-15 interface Recipes Maintenance & support

The Issues

Need Common Language Need Enterprise Threat Modeling Complex Compliance Landscape Tie Business to Security Diverse Needs Need Some Tools

Threats

Compliance

Driver Driver

Business Requirements

Threats
Description

Compliance

Driver Driver

Failure penalty

Requirements

Business Requirements

Driver Projects Name Time Goal Monetary cost Deliverables Political cost Success criteria Experience Milestones Risks

Driver

Project Project Project Project Category: Crypto

Project Project Project Project Category: Operations

Driver

Project Project Link Project Project Category: Operations

Salsa-CSI2 Home Page

http://security.internet2.edu/csi2

Shifting Landscape on the web (coming soon)

https://spaces.internet2.edu/display/SalsaCSI2WG/Shifting+Landscape

....and on Twitter!
@landscapeshift

Educause/Internet2 Information Security Guide

https://wiki.internet2.edu/confluence/display/itsg2/Home

Thanks to the artists!

Loan Boat, http://www.sxc.hu/photo/710974 Compass 1, http://www.sxc.hu/photo/649876 precaution http://www.sxc.hu/photo/1033084 Info Sign Question Mark, Alistair Williamson. http://www.sxc.hu/photo/594095

Shifting

Landscape

Strategic Security Model

presents...

Salsa-CSI2 c/o Brian Smith-Sweeney bsmithsweeney@nyu.edu 1 @bsmithsweeney

Who am I? Brian Smith-Sweeney, Project Lead New York University, Technology Security Services What is Salsa-CSI2? From http://security.internet2.edu/csi2: The Computer Security Incidents - Internet2 (CSI2) Working Group will organize activities to identify how security incidents can be better identified and the information about the incidents to be shared to improve the overall security of the network and the parties connected to the network. What is the Shifting Landscape? Read on, and see previous presentations at SPC08 and 09. What is the Matrix? http://xkcd.com/566/

Previously on the Shifting Landscape...

The Shifting Landscape Strategic Security Model is a new project we're launching to answer a significant meta problem faced by the higher-education security community: the question of where to put our limited resources to most effectively and efficiently improve the security posture of our networks and the Internet as a whole.

What the hell's going on here? Cosmo, what... what happened?

The world changed on us, Marty.

And without our help.
3

For several years Salsa-CSI2 has presented in various forums on the concept of the Shifting Landscape in IT security, specifically as it relates to higher-education. We have demonstrated that attacker methods and motivations have changed, as has the default security posture on many systems on the Internet, resulting in a significantly different threat landscape than was present when many information security professionals began working in higher education. Salsa-CSI2 has also identified a key problem - that security programs have not nearly kept pace with this shift. Many schools are operating in a manner strategically similar to the way they did 10 years ago, with minor tactical or operational changes. Wherever possible, however inefficient or ineffective, old tools and processes have been shoehorned in to solve new problems.

ESA

NIST

ITIL
COBIT

CMMI
(zomg)
4

To address this Salsa-CSI2 encouraged, in presentations to our peers, higher-ed security programs to approach IT security differently, and move from focusing on firefighting to developing coherent security strategies that most effectively leverage available resources. There are a number of frameworks and control structures for aiding in this process but they all have one or more of the following failings: * Closed development and maintenance process * High barrier to entry and cost of implementation * Lack of specific guidance for implementing an information security program

You'd like to be here This is more likely

You are here

Of course, as we have been studying these shifts other key factors have come into play. IT Security is maturing as an industry, and as such is expected to participate more in the overall IT structure. Mature means formalized budget, documented planning, metrics, and gasp strategic plans. Anyone who's ever been involuntarily pushed to develop strategic planning documentation knows how difficult it can be to produce useful documentation that accurately represents what you might actually be doing for the next few years. Documents created this way tend to be long, wordy, meandering, and painful to produce. But what if you could make something that was actually useful, both to your executive management and your operations staff?

Thankfully, we've got lots in Common

IT professionals, particularly information security professionals in higher-education, have faced this kind of problem before, and there's a solution that's worked reasonably well: package up the knowledge work produced by those that have the resources to do so, make it generally accessible, and give it back to the community. It works for code, it's worked reasonably well for policy issues, and I think we can do it for strategic planning.

Common drivers Common environment Common interest

Drivers are the reasons we do our jobs the things that make IT security important. These tend to be relatively consistent in higher-education: similar compliance issues, similar threat landscape, similar business drivers. More on this later Our environments are also quite similar many highereducation institutions run more open, heterogeneous networks than our peers in the commercial sector. This is largely due to the key principle of highereducation institutions: academic freedom. Thankfully we have a common interest highereducation IT professionals understand intuitively that by helping each other we are forwarding the mission of our own institutions. Educause, Internet2, the REN-ISAC are all excellent examples of organizations built around this concept.

The Plan?

Model Document Library Web 2.2.5-15 interface Recipes Maintenance & support

So, what do we do with all this commonality? First, we need a model a common language for describing the various components of an information security program, and how they fit together. We've begun a projectbased model which we'll talk more about later. Once we have the model we need a library of documentation (project plans) that implement the model, to create a knowledge repository other folks can use. A large repository like that will of course require an interface of some kind something better organized than other similar documentation efforts. Highly interactive, highly customized reports. Think kayak.com. Recipes could then be crafted via this interface that group together projects to solve common problems. Someone could then come to the site and say I don't really want to turn all the knobs here, but I need a series of projects to help me deal with PCI, and the system would provide them a map of what's worked at other institutions. Finally any large software project and documentation effort needs to have a maintenance model built-in at the very beginning. Many projects, particularly documentation efforts, fail in the maintenance stage. Some ideas have been floated to work this into existing process like having every Educause SPC speaker submit a SLSM project plan representing their talk. Incidentally, 2.2.5-15 is the first kernel (thanks redhat) I worked on regularly as a professional sysadmin. I'm a big proponent of using the kernel naming convention for descriptions of web technology, with odd numbers being dangerous and broken.

The Issues

Need Common Language Need Enterprise Threat Modeling Complex Compliance Landscape Tie Business to Security Diverse Needs Need Some Tools

We definitely want to charge forward as best we can, but there are some clear challenges here. Namely: * Lack of a generalized and reasonably accessible enterprise IT security threat model. Existing models tend to operate runway-level or 50k ft view we need something in between. * Lack of a generally accepted method for tying business process to security operations * No comprehensive list of regulatory issues relevant to higher-education. Navigating the compliance landscape in the US is nearly impossible. * No structured language enabling correlation and description of various IT security components. * No easily accessible tool for modeling and reporting on this data * Diverse IT security needs and resources of higher-education institutions With this in mind, let's move on to the state of the current (very theoretical) model.

Threats

Compliance

Driver Driver

Business Requirements

10

There are four components to the model. The first component is drivers (borrowed from NAC's now defunct Enterprise Security Architecture document.) Drivers are the "whys" of an infosec program. There are three kinds of drivers (listed around the triangle). Most of us are used to dealing with threats and compliance issues, but traditionally view security and business requirements at odds with each other. I believe this is a false contradiction and that instead security must encompass business requirements. This is a view that seems to be gaining ground in the security community and I won't work to prove it here, but rather take that to be a given for the model.

Threats
Description

Compliance

Driver Driver

Failure penalty

Requirements
11

Business Requirements In the model drivers have three key attributes:

The description provides an overall summary of the driver, its purpose, its scope, and pointers relevant reference material. Requirements indicate what one needs to do to address the driver. For compliance issues this might be a simple checklist, for threats it might be a more complex measure of risk and mitigation. There may also be auditing requirements. The failure penalty indicates the impact on the organization if the driver is not appropriately addressed. This can be used in risk calculation which we'll discuss later. For compliance issues this could involve legal ramifications, business requirements might mean some key business process fails, and for threats the failure state could be compromise and data ex-filtration

Driver Projects Name Time Goal Monetary cost Deliverables Political cost Success criteria Experience Milestones Risks

12

Projects are the "whats" and "hows" of an infosec program. Projects have an extensive amount of structured data associated with them. We're not interested in reinventing the wheel for projects and will likely leverage the extensive existing material from places like the PMI on appropriate metadata for projects (see slide above). Some metadata elements will be used to capture the kind of operational experience that we try to gather today via mailing list postings and hallway conversations with our peers in other higher-ed security groups. These currently include: * Known project risks what did you discover during your rollout that endangered the success of the project, and that another school might want to be aware of? This can include anything from the vendors we looked at weren't up to the taks to there were significant political hurdles to implementing network DLP at my institution. * Operational experience notes that might not have been an obvious part of the project at the outset, but which made the project more effective or efficient. * Resources here we'll try to capture information about traditional costs like hardware, software, and man hours, as well as less obvious costs like impact on the community or depleted political capital. * Worth it? - A flag and accompanying comments field summarizing the institutions' experience with the project and whether or not, knowing what they know now, they would do the project again.

Driver

Project Project Project Project Category: Crypto

Project Project Project Project Category: Operations

13

Project groups are a simple, default way to organize projects for folks that just want to walk a project library without a specific question in mind. The model will not enforce a specific group behavior one might, for example, allow projects to belong to multiple groups but instead would allow for contributors to enforce their own rules for grouping. For example, one might imagine a project group taxonomy based off the CISSP Common Body of Knowledge, or the Educause/Internet2 Security guide, or any other grouping structure. There are a number of existing documentation efforts that have a taxonomy or group structure in place.

Driver

Project Project Link Project Project Category: Operations

14

The last object to discuss are links. Links are a simple but powerful concept in this model and will likely be where most of the intelligence in the system is implemented. Put simply links connect other kinds of elements. Drivers might be linked to projects via a link that indicates how much that project meets the requirements of the driver (a met by link). Links of that form might provide a measure of how much the project meets the requirement in the case of a compliance requirement driver, or mitigates in the case of a threat driver. Projects can be linked to each other to demonstrate a prerequisite relationship, or a just a simple note indicating these project are related, you might one to consider both if you're considering either (a related link).

15

Here's a more complete diagram of what the overall model might look like. Note the inclusion of risk assessment with an outstanding question. We're not yet sure how to implement risk assessment in the model. It might be a type of link, a bit of calculation that exists outside the model but uses the model to generate a report, or something else entirely. Also note: this model is specifically scoped to planning rather than operations at this time. We may work to include operations once we have the planning stuff down.

16

Questions? Comments? Interested in getting involved? Feel free to reach out to the Salsa-CSI2 group, latest contact information can be found at: http://security.internet2.edu/csi2/

Salsa-CSI2 Home Page

http://security.internet2.edu/csi2

Shifting Landscape on the web (coming soon)

https://spaces.internet2.edu/display/SalsaCSI2WG/Shifting+Landscape

....and on Twitter!
@landscapeshift

Educause/Internet2 Information Security Guide

https://wiki.internet2.edu/confluence/display/itsg2/Home
17

Also referenced in this document is the NAC Enterprise Security Model. NAC no longer exists and has been subsumed by the Open Group. The NAC ESA can now be found at: http://www.opengroup.org/pubs/catalog/h071.htm The NAC ESA influenced some of the sample text included in this presentation. Thanks to the Open Group for continuing to make this document available.

Thanks to the artists!

Loan Boat, http://www.sxc.hu/photo/710974 Compass 1, http://www.sxc.hu/photo/649876 precaution http://www.sxc.hu/photo/1033084 Info Sign Question Mark, Alistair Williamson. http://www.sxc.hu/photo/594095

18

Images from this presentation are taken from www.stockxchng.com, following their Image license agreement here: http://www.sxc.hu/help/7_2