Security and Risk Management Strategies Blog

Operationalizing Security

Blogger: Trent Henry

Although friends and family would say otherwise, and tend to berate my penchant for sesquipedalianism (look that one up), I prefer to avoid a word as long as "operationalization."

However, we received an important question from a client lately: "What are the top security tasks that can be operationalized?" Put another way: "What tasks can be offloaded to network-, desktop-, or other operations groups?"

We've observed a trend over the last several years of enterprises moving certain day-to-day "security" functions to operational teams. This frees the security group to focus on more strategic matters, such as policies and architecture. It's a good management practice and creates natural separation among those who carry out tasks, those who provide oversight, and those who design controls. But what's the low-hanging fruit?

Foremost, here are some "operationalization litmus tests" for whether or not something might be handed to secops, netops, or desktop ops:

• Is it a repetitive task that is clearly spelled out in a process or procedure?
• Would operational execution of the tasks cause any violation of segregation of duties?
• Are there specific regulatory or contractual mandates stipulating who must do a piece of work?
• How high is the business risk in the area under consideration? The higher the risk, the more security oversight is warranted

Looking at common security tasks, here are some "best bets" for those to operationalize:

• 1st level help desk, including password reset and other credential handling
• Standard user account management
• Desktop patching
• Running standard vulnerability management infrastructure
• Firewall rule changes, if part of proper change control program with external oversight
• (possibly) Some degree of project management
• Security awareness and training execution (which might be handled by HR)
• Routine assessments (business unit, vendors, or others) that have been standardized (and "standardized" is an extremely important caveat, because such assessments might be compensating controls. For example, they might provide the monitoring of an outsource vendor's security program.)

On the flip side, here are "best bets" to retain in a Security architecture/strategy/program management team:

• Incident response (although ops might need to lend a hand)
• Future security architecture
• Policy
• Risk management and compliance monitoring
• Security awareness and training development
• Assessment program development and roll-up (create certification and accreditation [C&A] criteria, and aggregate organizational results)
• Interface with internal/external audit and higher-level risk management functions

Whether to shift/contain costs or keep security teams focused on more strategic functions, operationalization can be a legitimate, wise approach.

What are your experiences?

RSA Conference: Innovation becoming mainstream?

Blogger: Randall Gamby

Last week I attended the RSA Conference in San Francisco, CA.  While there was the usual flurry of security product announcements, there was a subtler undercurrent running through the show.  I heard the keynote speakers saying things like: “…security revolves around the three points of people, policy and technology”, “…you can’t secure what you don’t manage”, “…the future of security services is information-centric security”, “…end-to-end trust frameworks are needed”, etc.  Considering that RSA has led with technology in the past - after all it has one of the largest security expos in the country - this was quite a different outlook. 

In many ways this was a good conference for Burton Group.  The conference was, in a sense, validation of what Burton Group has been talking about since SRMS became a component of Burton Group’s portfolio of research areas.  Breakout sessions touting some of our tenets of security services being more than just firewalls and hardened platforms were starting to draw a significant number of attendees, however, the technology-oriented sessions still had the largest turnouts.  It was great to attend sessions where speakers were talking about how they’re developing security policies to address new threats and regulations; a talk on how a company’s security organization is structured to address business managers’ requirements through bi-directional communications through security liaisons; and a presentation on how roles are key to maintaining secure access. Quite interesting.

In addition, I attended a half-day off-site conference with Jericho Forum.  This Open Group sponsored forum has recognized that IT-dependent businesses have issues with traditional security mechanisms no longer meeting the business’ need for conducting dealings across open, extended enterprise environments. They have proposed a different model, de-perimeterization. Again echoing with the RSA conference’s themes of information-centric security and end-to-end trust (and Burton Group’s points of view).  Actually I was quite surprised that the Jericho Forum and RSA didn’t have closer ties, as they’re both preaching the same messages to the same crowds.

Finally, through manning our booth at the conference and talking to various attendees I found that security metrics – one of our 2008 “Security Vital Signs” – is a hot topic.  Both business managers and security personnel have recognized that security services are vital to the enterprise and have intrinsic value, but with the ever-decreasing security budget find themselves having to constantly justify their expenditures to get a piece of the budget pie.  To many I spoke to, being able to quantify the value, and cost, of security is getting harder and harder.  One of the metrics breakout sessions at RSA had people going around the block to attend, but the people I talked to afterwards said it didn’t go far enough and didn’t address their needs.  In all fairness to the speakers, metrics are a personal thing within an organization.  Like any sets of numbers, they have to be applicable to an enterprise’s current and future activities, they have to be quantifiable, and they have to address real issues the individual organization is dealing with.  No one set of metrics will fit everyone’s needs.

So my outtake from the 2008 RSA Conference was, "Security services have been hampering innovation with thoughts around denial but today's security services have to be about enablement of innovation using new processes, new procedures and new technologies."  Yep, quite a different RSA show.

Policy-based Management Tools Unite!

Blogger: Randall Gamby

I’ve recently moved over to the SRMS Analyst team from Burton Group’s Consulting organization. Before moving over to the team I spent almost nine years in the field as a Burton Group Principal Consultant. Over these years I’ve worked one-on-one with many of our clients in both North America and Europe, and one of the topics that has always been an issue, and still is in many enterprises, is the process of implementing the enterprise’s policies in technology.

In the Identity Management (IdM) arena everything is moving to “roles-based” management controls. While roles-based controls are a subset of an enterprise’s policies and deal well with access rights for individuals and groups, in the security world “policies” are much more in-depth than just access. Not only do policies govern the actions of individuals, they also deal with data (whether in motion or at rest) and systems. But it seems that every security control system in the market is developing its own policy-based management interface. So the question is, “How many policy-based management interfaces do we need to configure?”

Historically, most enterprises have taken many years to create a relatively consolidated user identity repository (a vast majority of enterprises I’ve worked with use Microsoft’s Active Directory). However, as we move up the food chain to enforcement and compliance tools, products typically don’t--or can’t--read the LDAP user and group information. This forces the enterprise to go back to a siloed approach of creating and interpreting policies.

Think about it. I have a client that has firewalls being run by its Network Group, secure messaging run by a specialized IT group, host intrusion and prevention system (HIPS) being run by Security, and enterprise Active Directory deployment run by its directory team. Each product has policies about users, groups, and resources but barely recognizes the existence of the others; and each claims to have done policy “right.” Are they consistent? Maybe. Are they genuinely doing their best? Of course. Is there a risk to the organization that something has been overlooked? Very probably.

So what has to be done?

I think the first thing that needs to be done is for enterprises to review their policies. In the field many enterprise security managers (confidentially) have expressed a concern that the brave new world of security enforcement has invalidated, or provided scenarios that were never considered, in their original enterprise security policies. Next, I think vendors have to recognize that while policy-based management is a great ideal, it can’t be done in a vacuum. Managing policy enforcement for your set of tools that addresses only a part of an enterprise’s security front, without considering how you can share this with other sets of vendors’ tools working on other fronts, increases the chance of a hole in the defenses. Finally, I know you hear Burton Group say this all the time, but we need a standard to represent “policies” within a set of tools and a central repository--probably “virtual” if you ask the IdM people--that can store these values for the consumption and update of the tools. If a vendor can create a policy-based management interface that works across its suite of products (and some have), why can’t this framework be standardized for a similar group of tools, or even across all security enforcement technologies?

In the end, it will be the market that will determine whether policy-based management will be something that is a tool requirement or an enterprise requirement. If security managers aren’t educated on the “risk” in their current enforcement technologies; if vendors don’t hear from their clients that they’re tired of interpreting their new, and updated, policies for each of their policy-based enforcement technologies; and if standards can’t be created to make this all “consistent” within an enterprise, then efforts to go out and purchase expensive tools to manage their risk may be in vain.