Security and Risk Management Strategies Blog

Musings on why security is everyone’s job

Blogger: Phil Schacter

The more we debate who owns security and is responsible for enforcing compliance and technical controls, the more we should realize that security needs to be everywhere and everyone needs to be involved. The days of IT security being effectively operated by the mainframe RACF or ACF2 administrator, or by the network security operations team administering firewall and router ACLs, are long gone.

A few examples of the many places where security resides within the organization and business environment:

• Security controls operate on the devices that access business IT functions, subject to the security-aware user avoiding actions that would compromise the device.
• Other controls are enforced by file management systems, content management systems, and enterprise data base management systems to ensure that users are only able to access information that is required based on their current job function, organization role, or relationship to the business.
• Custom and commercial developers are responsible for delivery of software  that is well tested and free of known code vulnerabilities.
• Network and content monitoring tools should recognize unacceptable behaviors and be able to determine accountability at the user, device, or application/service level.

A failure anywhere within the information, application, or identity life cycle could break security and expose the business to a growing array of insider or external threats, in spite of our best efforts to implement a defense-in-depth strategy.

A systematic approach to security is clearly needed to establish security as a basic quality to our IT-enabled business services. Security cannot be imposed and realized by an external regulator, or by a CISO drafting a new policy document, or by implementing all of the recommendations coming out of an IT audit report.

One of the steps that an organization can take to improve security across all aspects of the business and the IT organization is to have business executives clearly communicate to all employees the importance of  security to the brand and economic well being of the organization. A continuous security awareness and education program is needed to help all users and IT staff appreciate why security is important to the success of the business, and how individual actions contribute to the effectiveness of security controls. Such an awareness program is a bargain with minimal impact on the overall IT and security budget, often leveraging existing internal newsletters and electronic communication programs.

Security is also not something an organization can purchase from any vendor or combination of vendors. Achieving business and security goals requires everyone in the organization to play their part. This effort may be as simple as being aware when someone is paying too much attention as you enter your password, or attempt to tailgate as you enter a secure facility, or not accessing a private web mail service that circumvents organizational malware filters.  You get the idea…

What do you mean "we can't get in"?!

Blogger: Ramon Krikken

Hypothetical situation: one day you come in to the office, and find out your senior network administrator was hit by the proverbial bus. How sure are you that you have all the information needed to continue managing the network? If instead he went to work for the competition, how sure are you about the integrity of your network?

If the answer is anything but "We're as sure as we can be. This is accounted for in our security program, business continuity plan, and disaster recovery plan. And yes, we do security audits and BC/DR plan tests on a regular basis", it's probably time to check and make sure.

Real situation: the city of San Francisco puts its its senior network administrator on administrative leave, and then finds out no one else could access their city-wide "FiberWAN" network routers. The official details were vague, but an unofficial story purportedly showed the administrator's side of the story . It appears that the situation isn't the usual cut and dried password recovery or reload and restore from backup.

Does it all sound far-fetched? Well, possibly, but in challenging economic times, and even during better times when mergers and acquisitions take place, it is certainly not unthinkable that someone will leave on bad terms at some point. It may be rather unlikely, but it could still happen ... apparently with potentially significant consequences.

I say potential, because the city can't know. After all, without access to the router, they don't know its configuration. The solution could have been as simple as reloading and recovering the password, but that could lead to losing the configuration if it isn't written in NVRAM and isn't backed up.

Or, it could be that password recovery was disabled with a single configuration statement, available in modern Cisco IOS releases, which results in having to clear the configuration and load it from backup if you lose the password. And no, there doesn't appear to be bypass mechanism, even in hardware, for this.

So there you are with an availability-critical system, designed and configured with priority for confidentiality and integrity of its root password without compensating availability controls (backup, configuration audit, segregation of duties, etc.) ... and you have no idea whether you can easily fix it or not.

So it's certainly possible to assume that a product like this is designed with some fail-open recovery mechanism, and that you should be able to trust high-level administrators to behave a certain way, but it's definitely a mistake to do so. Indicative of a defective risk assessment process, or weakness in the governance process, it's something that needs to be fixed.

Of course getting some basic network management security right is important: proper authentication mechanisms, backups, command restrictions, logging and auditing for configuration changes, and so on. But this all presumes that you've actually thought about it, and that you have more than one person in charge of the network.

In the end, only by having strong governance and proper controls throughout the information systems life cycle, will you be able to have assurance that security objectives - including availability and accountability - can be properly met. This includes assessing risks posed by the implementation itself; something that is easily forgotten.

It's not necessarily a lot of work, it's just creating the methodical approach to it all. A bit of governance goes a long way.

It's all GRC to me

Blogger: Trent Henry

Each fall the Security and Risk Management Strategies team gets together for annual planning and brainstorming. These are long days spent in conference rooms, followed by evening vacillation: "should I go exercise, or go to the calorie-laden group dinner?" then email, then repeat the next day.

We always try to create a list of key themes for the research year -- things that are top-of-mind to clients, represent interesting trends for the industry, or are potential market "gotchas." This year we looked at the emerging discussion of "GRC" and scratched out heads. We didn't get it. In fact, we thought the market messaging and product direction(s) were potentially deleterious, so one of our key themes was to debunk the solution space of GRC (that's "Governance, Risk management, and Compliance" in case you were unaware; of course, as further evidence of the meaninglessness of glomming these words together, some vendors use "GRC management," which drops the individual management from risk management. On the other hand, it also implies a such thing as "governance management," which, if not redundant, I don't know what is; but don't get me started down the semantic idiocy path...)

Back to the point: GRC is not a solution, technology, or product category. This sentiment has been echoed the last couple weeks by others in the blogosphere, notably kicked off by Rich Mogul (securosis.com/2008/05/13/grc-is-dead).

Of course, the elements of G, R, C are not dead. Governing, managing risk, and responding to compliance obligations are ongoing and critical organizational tasks. The problem is conflating them into a single term. As Burton Group is inclined to say, GRC is a four-letter word that shouldn't be spoken among polite company. Each function is deserving of its own, complete, and separate word. There's no organization in which compliance activities, risk management, and executive governance are rolled into a single person, group, or tool. No sense creating an acronym that implies it.

This is more than terminological, though. The problem is a vast landscape of vendors touting "GRC" functionality, but whose tools operate at widely varied levels of the solution stack (or, more aptly, at very different levels of organizational reporting). Is a SOX risk register a "GRC" tool? Apparently--particularly if you call it "Enterprise GRC." Is a user provisioning and identity certification solution a "GRC" tool? Yes--it seems--because it has a small stake in validating user management controls. And the list of claims goes on... If everything is "GRC," then nothing is.

What this obscures is the real value that many solutions provide: to map various enterprise requirements (regulations and control standards), test controls for effectiveness, and report gaps or problems that need attending. And it's appropriate that certain tools address the audit community, others the security team, and yet others lower-level technical operations groups. What's inappropriate is to call them all some variation of "GRC."

We've published two reports, a Telebriefing, and we plan to talk at some length about these issues at Catalyst in June (San Diego). We'll be talking realistically about governance functions, the landscape of tools, etc. Our intent is to make clear that many vendor solutions provide value to staff at various levels: just don't go looking for some unifying uber-tool called "GRC."

Business Matters

Blogger: Eric Maiwald

A number of years ago I knew a security manager – we will call him Joe. Joe worked for a division of an enterprise and was originally hired as the head of IT security. One of the first things that Joe did when he came on board was to write a security policy. It was huge and covered all aspects of IT. Unfortunately, Joe wrote the security policy based on his experience and knowledge without consulting the business users. When Joe tried to implement his policy, he found that the business users were not too interested in implementing it. The complaints included everything from “that’s not the way we do things” to “I can’t do my job if I have to comply with all of this.” Joe pushed his policy, and the business pushed back. Most of you can guess who won – yup, the business won, and Joe ended up reassigned and working under QA in the software development department.

In doing recent research into network security architectures, business concerns also came up. It was not only that security could not interfere with business, but even IT as a whole could not interfere with business. Policies that required business users to function in certain ways did not go over well. In fact, if the business executives didn’t push back (and get the policies changed), the business users would work around the policies and security controls. Even in cases where business executives are on board with (or at least not hostile to) the security policies and controls, users can still cause problems if they are not trained as to what is expected of them.

So what does this mean for the security professional? Clearly, security professionals cannot rely solely on technology. We may find the greatest product in the world but if we interfere with business or even if the product (or control) is perceived to interfere with business, it will fail when implemented. Security professionals cannot ignore how business works. We cannot ignore the needs of the users, and we can certainly not take user knowledge for granted. Security professionals need to create a partnership with business and with users in order to manage risk to the enterprise. This does not mean that no security control can be implemented. Through a partnership with the business, security professionals can explain the purpose of the controls or policy in managing risk.

More results from the network security architecture research will be presented at Catalyst North America the week of June 23 in San Diego. I hope to see you there.

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.