Archie Reed's Secure Observations Blog

"Just say no to 'GRC'" - say what?

2008-07-11T16:48:00Z

Unfortunately due to a last minutes change in plans I did not make it to this years Catalyst Conference, so I am working my way through the slides online and chatting with those who did attend.

One thing that caught my eye was Bob Blakley's Thursday talk on "Governance, Risk [Management] and Compliance" - a four letter word as he describes it.

This peaks my interest for several reasons based on the customers and industry pundits that I have spoken to... Bob postulates, ney, demands that you "Just say no to 'GRC'" to which I say nay (to say no)!

Why?

I have a great deal of respect for Bob, and acknowledge that he would be talking to many more folks in the industry than I, and while this could well be flamebait, I do not agree with his premise... Bob stated that thinking of GRC as one big thing will confuse you - Semantics are important here so the words "one big thing" are important. I say this is simply a point where you need to carefully think about the requirements of each disciple in toto, however by not bringing them together as "one big thing" as a long term initiative, you will end up with disconnects across each of these disciplnes- taking your organization down anyway. Execs don't tend to like that.

Fundamentally the security (and identity management) industry has spent years trying to manage each of these disciplines/requirements individually, and found issues specifcially because we were not joining up and aligning these disciplines when rolling out solutions. Having a single app, or set of applications, that coaliesces the planning and delivery of these disciplines allows an organization to manage their GRC requirements better. The "seperate people are responsible for each discpline" discussion is a red herring if you end up with seperate teams and disconnected products..

I discssed this with a couple colleagues who consult every day on these things - we see the following:

Companies are generally doing really well (or much better depending on your perspective) at Compliance.
Companies are doing OK at Governance
Companies are concerned with Risk.

So we have a catch 22 if we believe what Bob has put forth.

Companies NEED to link GRC together to manage governance, minimize risk, and ensure compliance.

My view here is that while these MAY be considered as seperate disciplines and requirements per se, it would be a mistake to do so. This may be the result of pontification, or even the reality that different people/departments inside an organizaton are repsonsible for different components of GRC... HOWEVER, it is critical to consider them like we do many linked items (eg security approaches such as CIA and PDR)!

Bob does lay out a lot of great things here.in the middle - for example, Bob says that many risk management approaches are wrong. They take only one tack such as focus on maximizing gain rather than minimizing losses only, consider the portfolio, consider wildcards and build in transperancy. Interestingly this is what is wrong with the beginning and end of Bob's overall thesis. By not linking GRC together (properly of course), you increase your risk.

A loss in any part of GRC systematicaly and dramitcally affects the other - pick you analogy as needed (pillars of support, legs of the stool, corners of the triangle).

In the end Bob offers a number of recommendations including:

•Don’t use “GRC” as a catch-all term

•Say what you mean: governance, risk management, OR compliance

•Think of governance as round-trip management

•Do not think of it as something you can fix with tools

•Measure risk management on the basis of value created

•Not loss avoided

•Measure compliance on the basis of loss avoided

•Not liability avoided

I agree, but the lead in for this set is based on the wrong premise.

Going forward the requriements in each of these areas will become greater, as a result, the importance of these disciplines being aligned becomes much greater still - just say no, to saying no to GRC...

Be smart, don't buy what you don't need.

NIST RBAC - What goes around...

2008-07-11T00:27:00Z

...comes around.

In Sep 2006 I sat on a panel at Digital ID World titled "Are NIST Based Roles the Right Answer?”. I blogged about the session and issues discussed here... I can even point to my 2001 book "The Definitive Guide to Identity Management" which details the same issues again.. Hard to find despite being an ebook, but you can search for it out there.

I am sure others could point to earlier discussions and this just keeps circling the drain.

I point this out because the same conversation is passing by again...

Oracle's Nishant Kaushik posts today attempting to raise controversy around the NIST RBAC standard. Dave Kearns comments... and then... who next?

Well... here's 2c

Fundamentally, the standard is just that and not much more - and the issue is how folks can manage whatever they decide to implement. The Government certainly like standards, so they use it as much as possible. However, the same issues remain...

Even in the broad identity management implementation sphere, most have not even read the NIST RBAC standard and if they have, it didn't really help them do their implementation any better.
Because no one (vendors or customers) implements RBAC completely per se, and roles are even less consistent across applications, it doesn’t help that much to have done much more than skim the standard – If at all
The hierarchical approach pushed by the NIST RBAC model does not extend far enough to support the variety of needs of security, business and IT
From any starting point, anyone choosing to use the standard or not will deviate from almost every other implementation.
Folks cannot migrate from one Identity Management implementation to another without reworking their role model to suit whatever application they want to add into the mix - even using products from the same vendor...
There are still some better standards/approaches to look at (today)

The Healthcare Level 7 (HL7) model http://www.hl7.org/ regardless of whether you’re in healthcare or not, as it provides a good approach for defining roles.
The Software Engineering Institutes Capability Maturity model at http://www.sei.cmu.edu/cmm/ is another more mature model on how to do enterprise role implementations.

What has changed over the last few years perhaps are several things:

More people are interested in, and working on, tools to manage roles
NIST is working on a new iteration of roles. As Kevin Kampan blogged after the Burton Group 2008 Catalyst Conference here.

Tim Weil, Vice Chair of the INCITS CS 1.1 Role-Based Access Control (RBAC) Working Group discussed their effort. His group is developing a standard for the implementation and interoperability of RBAC components described in INCITS 359-2004.

More projects have hit snags as a result of their initial obsession with roles and role definition.
Microsoft took a "Claims Based Access Control" tack to try and approach the access control and contextual requirements but did not solve the overall role modeling issue - this is more like one of the approaches I described in my 2001 book "The Definitive Guide to Identity Management".

Anyway- thought I would throw a small note into the thread as its been a long (time based) thread indeed.

New blog platform coming next week.

2008-05-23T14:03:00Z

The HP blogs site will be migrating to a new platform over the next week. We expect to be back sometime in the around June 1, so even though I haven't been bloggin' much, I definitely won't be blogging next week, and comments on recent blog entries will be tough - so... Please hold your comments until June 1 when our new site will be live.

Thanks all.

HP and Identity Management - watch this space...

2008-05-23T13:59:00Z

I didn't blog about HP’s Identity Management strategy at all recently because there are still things being worked on, but now that the first stage of HP's Identity Management partnering strategy has been announced (HP and Novell Announce Migration Program for HP Identity Management Customers). My HP colleague, Marco Casassa-Mont, commented on the announcement here. As a result, I've been hit up with a bunch of questions from the field and colleagues in the industry asking for more background.

Given the industry at large and HP’s market position, HP rightly, or wrongly, chose to shutter its own identity management offering to new customers, and instead, expand our partnering and integration efforts – to offer customers a best choice set of options based on their needs. In terms of other projects at HP that I am working on, identity is a critical component and is recognized as key functionality, but so are the needs for integration and interoperability.

So, HP still fundamentally understands the need for Identity Management, and has chosen to focus on a broad security approach incorporating an “Identity Services Layer” to our security architecture, and delivery capabilities from our services organization.

The Identity Services Layer approach is viewed as an abstraction of the technical identity components (such as repositories, security services, lifecycle management, etc…) to provide identity services for users, applications, services and devices. The Identity Services Layer encompasses identity-related technology, processes and people into identity solutions that are aligned with an organization’s business requirements and that ease compliance with industry and/or government regulations. This then allows HP to build solutions aligned with the HP Information Security Service Management (ISSM) Reference Model, which provides the structure and context to define, measure and ensure compliance with global regulations, security requirements and operational standards.

While I admit that sounds a bit fluffy, the approach is incredibly flexible but comprehensive for organizations in the mid market through to the global giants.

In this, HP takes a best-of-breed approach for delivering the Identity Services Layer and its solutions to customers. Therefore HP will include leading players in the identity management space as part of the HP Secure Advantage Alliance program. This allows HP to continue to drive the evolution of the identity solutions from a non-partisan position and provide integrated solutions with HP Secure Advantage encryption and key management products. This approach is also in line with the concept of the Identity Services Layer - to have identity capabilities that are appropriate to the I.T. infrastructure regardless of the technology deployed.

So, to those who have sent me queries - yes you can expect more Identity Management related partnerships to occur. Novell is a key partner for HP in this space, and others will be along soon to meet and match both customer needs specifically, and the HP identity services layer requirements in general.

Watch this space…

Interop 2008 Las Vegas - Disconnects with the NAC Interop Lab

2008-05-15T17:54:00Z

I spent time at Interop Las Vegas (Apr 27 – May 2) a couple weeks ago, including attending the NAC day on the Monday which I’ll comment on separately.

One thing strikes me is that NAC is still a jumbled market with this being an obvious hook for many vendors to hang their hat on, and while things are consolidating, many smaller vendors need to find a safe harbor quickly or risk. The concern that I have is simply that most vendors are entering this space with product and delivery (I misspelled delivery as devilry – should I be concerned?)… that does not involve the overall “lifecycle” implications. Sure, folks talk about it, but not many help you deal with it.

That said, this post is to focus on the Interop Labs. I was surprised that ProCurve wasn’t participating, especially as their involvement in the standards development, and implementation of NAC have been at the forefront. Then I saw this article “Can ACLs and NAC mix for security success?” by Joel Snyder at Network World and thought I needed to understand a little more.

Joel noted that:

“This year we pushed the NAC envelope with the decision that access control would be handled with a combination of access control lists (ACL) and VLANs. We used VLAN separation for guests and VoIP phones, areas where we had a clear, never-changing security policy. All internal users -- employees, whether they needed remediation or not -- were put on the same subnet and had their access controlled with ACLs : keeping quarantined users to their own part of the network and away from normal users, yet all on the same subnet and using the same address space.”

More specifically, Joel called out HP in particular:

“The second type of equipment required the ACL to actually be generated on the policy server and pushed to the switch at the moment the user wants to get on the network. In our interoperability testing, HP's wired and wireless equipment fell into this camp. Although this is a less popular approach, it offers a different way to manage security in a more dynamic fashion.

While our policy server vendors also could all interoperate with the HP equipment, we didn't find any policy server that actually dynamically generated the ACL. Juniper's UAC, which can dynamically generate ACLs for Juniper's own firewalls, won't do so for non-Juniper equipment. None of the other policy servers had any dynamic generation capability. So while the HP approach is theoretically more dynamic, it's a moot point until more NAC products support that feature.”

I was again struck by some of the challenges that the standards groups face when also dealing with vendor needs to deliver compelling and useful solutions early. However, I didn’t quite agree with the “moot point” comment so I approached the folks I know at ProCurve and we had the following thread developed, specifically with Tim Martin and Adrian Cowham:

ProCurve can and do set dynamic ACL's from IDM based on User Identity. It's a differentiator for IDM. It is also true that we do not implement ACL's in the same fashion as other vendors, but rather, we have taken a standards based approach to our implementation...

But to be clear we need a little history about ProCurve’s ACL RADIUS attribute.

HP's implementation of dynamically assigned ACLs is based on the standards RFC 4849 and 3588. When ProCurve released their V1.0 NAC solution, HP was actively engaged in the standards process but the standard wasn't finalized. Therefore, the current implementation uses a Vendor Specific Attribute (VSA) for defining the ACL attribute but the attribute value adheres to RFC 3588. In an upcoming release the networking devices and NAC solution will fully support the standard.

Adrian thought that the Interop Lab failed to recognize the obvious deficiency in configuring ACLs on the switch. In a medium environment or larger, deployment and maintenance of ACLs across a large number of devices is a burden and increases the barrier to NAC adoption. Assuming vendors have an automated method for deploying and maintaining ACLs across a customer's networks to help reduce the complexity of their approach; you will still run into scaling problems because it takes time to touch every device.

So, HP's implementation has a number of benefits that make the point "non-moot"...

1.) Ease of use - Rather than having to go to all your network devices to configure them with ACLs, HP's implementation allows customers to configure them from a central location. This reduces the complexity with respect to NAC deployment and maintenance. This is also increases speed of deployment.

2.) Interoperability - In an environment with heterogeneous network infrastructure, customers won't have to worry about creating a complex system of rules to ensure that each vendor's hardware receives the correct RADIUS attribute. As opposed to a standards approach, where the customer doesn't have to think about which network devices get which RADIUS attributes.

3.) Efficiency - When an ACL is changed, the change does not need to be propagated to all network devices. You can imagine the effect of modifying, adding, or deleting an ACL in a large environment where the ACLs are stored on every device (or the majority of the devices).

4.) Complexity - The approach of requiring the switch to be configured with the NAC ACLs creates unnecessary complexity when new devices are installed into the customer's environment.

An interesting discussion no doubt, and one I’ll look to some of the other vendors that I work with to respond to.

NAC (Network Access Control) - Future Directions...

2008-04-04T00:14:00Z

I've spent some time over the last many months looking at NAC (amongst other things), and think there is a long way to go. The standards are still evolving, vendors are still jockeying for position if not acquisition for the smaller players, and folks trying to implement NAC are still riding through various peaks and troughs of success and disillusionment.

But this post is not about those things… this is about where I think NAC needs to and will evolve over the next few years… and I’ll say that if I am wrong, or missing things, let me know – I am watching lots of news and analysis go by through the tubes, but the evolution seems to be moving slowly.

So, here are some key areas I think we need to focus on:

Standardized NAC infrastructure: With the work of the TCG's TNC working group, HP believes that standards for NAC infrastructure will help meet customer needs for interoperability between NAC level products. For example, Microsoft's recent NAP alignment with TNC will have a significant impact on creating a common NAC framework. HP will continue to work with vendors and standards bodies to deliver a standardized NAC infrastructure. Further, the increased use of interoperability testing will ensure that the infrastructures will provide for easier deployments.
Device Identities: HP sees the need for secure device identities to be implemented to support NAC security architectures. Using existing standards such as TCG's TPM specifications, the TCG's TNC working group and the IEEE 802.1AR work will better address network infrastructure security needs: endpoints will be able to provide stronger security assurances with hardware protected device identity credentials, and signed health statements to a NAC eco-system.
Standardized NAC integrations: To minimize friction between governance models and network security initiatives, it is critical that NAC be able to support and respond to an organization's supporting SIM/SEM, change management, network management, and similar tools.
Behavior based NAC: Linking NAC implementations with network monitoring capabilities allows for legacy devices to participate more fully in a complete NAC environment, while appropriately mitigating the risks associated with their lack of NAC device client capabilities. This will evolve into a cyclical relationship between these solution areas delivered by standardized NAC integrations.
Virtualization and Hypervisor evolutions: With the emergence of virtualization technology on endpoints, we expect to see the development of hypervisor-level NAC solutions for endpoint compliance enforcement. Proprietary technologies such as Intel vPro are beginning to take advantage of hypervisor technology to isolate and secure network security policy enforcement on individual endpoints, and we expect such implementations to integrate with NAC architectures moving forward.

Let me know your thoughts...

RSA 7-11th Apr - I'll be there, along with the rest of HP's security folks.

2008-04-04T00:05:00Z

Like many of you I'll be racing around the RSA security conference next week... I'll be at the HP stand a bit, ready to talk about NAC, IAM, security in general, and international beer tasting.

HP has a large presence, and you should take a look at the following list to see if there is something you want to talk to HP about:

1. HP-UX 11iv3 Data Protection

HP-UX 11iv3 provides embedded data encryption capability to utilize existing applications and storage devices for the protection of sensitive data at-rest, with enterprise key management and key protection. Prototype integration with HP StorageWorks Secure Key Manager

2. Secure Print Advantage (SPA)

Secure end-to-end printing solution for the enterprise. There will also be slides on other IPG secure printing solutions.

3. HP Compliance Log Warehouse

HP Compliance Log Warehouse solution is an integrated, enterprise-class appliance that provides collection, retention, and analysis of event log data for security, industry and government regulation compliance, and IT systems governance.

4. HP Storage Security

For data-at-rest, HP Secure Key Manager and MDS9000 SME deliver the right encryption keys to the right person at the right time! Secure and high availability key management for enterprise data privacy. It integrates with HP’s Compliance Log Warehouse to bring key event data into the Compliance Log Warehouse.

5. HP NetTop and Trusted Infrastructure

Protect your cross domain solution, from the client to the server. HP NetTop provides secure virtualization for secret and top secret data. Common Criteria servers and multi-level security services provide information assurance for your computing infrastructure needs.

6. ProCurve ProActive Defense

ProCurve ProActive Defense delivers a trusted network infrastructure that is immune to threats, controllable for appropriate use and able to protect data and integrity for all users

7. Application Security Center

Products (AMP, DevInspect, QAInspect, and WebInspect)

8. Information Security Service Management

The three demos on this station are Information Security Service Management, Mission Critical Security Services, and Proactive Compliance Management.

HP is announcing the evolution of ISSM and the transformation approach. This presentation will demonstrate the ISSM Reference Model, the delivery life-cycle, the major phases and milestones for an ISSM transformation project, how security controls align with IT processes, how ISSM addresses compliance and supports standards, and how ISSM is a key component of HP Service Management Framework (SMF)

Mission Critical Security Services

HP is announcing new Mission Critical Security Services. This presentation will demonstrate how these services focus on continual improvement of the security infrastructure and how they are integrated with a complete set of proactive security and risk management services.

Proactive Compliance Management

This presentation will demonstrate a joint solution with HP Services, HP Compliance Log Warehouse and Symantec Control Compliance suite which automates IT compliance management processes and the assessment of technical and procedural controls.

9. Securing the Data Center

How HP Services addresses end-to-end the data center protection working with Apani

End-to-End Data Protection
Compliance and Data Loss Prevention
Data Encryption and Key Management

10. HP ProtectTools

Client PC Security ProtectTools suite plus HP NAC demonstration. There will be a demo that focuses on PSG’s HP ProtectTools clients and one that offers an implementation of layered security policy enforcement created by integrating HP thin clients and Consolidated Client Infrastructure (CCI) blade PCs with the HP ProCurve Network Admission Control (NAC) solution. The combination of thin clients and CCI blade PCs provides a very secure, robust, and cost-effective computing solution that can be applied to any network.

11. HP Application Security Center tools

Application Security Center tools demonstrate how they protect against hacking of web applications.

NAC (Network Access Control) - Some Best Practices #1

2008-02-26T20:09:00Z

A few thoughts (not comprehensive) as you review the NAC capabilities available today, and consider preparing for the changes and additions to NAC requirements going forward:

Standards

Choosing one single standard today is a challenge given the core variants - NAP, CNAC and TNC. Add to that efforts in the IETF, Open Group, and others, and the need for a framework to align and match your business needs to your network architecture, ensure that your approach can do so.
As of today (early 08) the standards are not entirely interoperable outside of custom integrations, and therefore, choosing the approach to meets a majority of your needs is the key direction to take. Think the 80/20 rule for now.

Vendor experience and stability

There are a multitude of NAC vendors out there. Many smaller players align with the TCG TNC model and then integrate with CNAC and/or Microsoft NAP. However, the key consideration is whether the vendor will be in business in the long term. Validation from a larger partner is good, but make sure you understand what has been implemented before accepting the delivery.
For comprehensive integration of NAC, you must incorporate your Governance requirements into the definition, delivery and ongoing assessment of your NAC. So, implementation experience is important, but consider the need to work from business drivers down to actual NAC policy and network ACL and whether the vendor alone can mediate between all those layers in your environment.

Phased deployment is critical

Start slow – attempting to implement NAC using a big bang approach will likely result in end-user discontent and increased work for the help desk.
Implement a non-enforcement mode as early as possible – before implementing a NAC solution it is hard to ascertain what the impact will be. If the chosen NAC solution allows for a reporting mode only, implement that first and analyze the data you receive. This data will assist the organization in developing the enforcement policies and know up front where the pain points will be.
Secure your open areas as soon as possible - Attack low hanging fruit first – if the chosen solution allows you to address a certain “limited” part of the network first, start there. For example, if you can begin by implementing NAC on VPN concentrators first you will impact a subset of the total population as opposed to the whole. Also you could start with just a single concentrator as opposed to all of them assuming you can control which users hit that concentrator. Instead, you could implement NAC just on a subset of 802.1X network access points; maybe ones the organization views as high risk.
Undertake an asset inventory as soon as possible – very few environments have a single vendor solution, and interoperability is not guaranteed.
Assess the enforcement points before starting deployment – if the chosen NAC solution takes advantage of hardware based access points (i.e. wired/wireless switches) ensure that a) they support 802.1X and b) have the correct firmware/patches/upgrades/OS. As an example, each model may or may not support enforcement, each may require an upgrade or a unique set of patches, and each may have completely different configuration commands.

As a set of best practices, HP considers these as the starting point.

look for future posts on more best practices...

NAC (Network Access Control) - Challenges

2007-12-19T16:55:00Z

NAC solutions today are quite often not overtly complex in their goals or implementations, but might also be considered relatively simplistic in their enforcement capabilities. From our perspective we also see NAC implementations running into trouble by starting with a small set of requirements in mind, and remaining focused on those goals without considering the longer term impact of the deployment on a true security architecture - say a layered security model such as HP's Adaptive Networking Architecture.

Additonally, some of largest challenges facing NAC today are:

Legacy or limited endpoint capabilities: While endpoints such as PC's and servers can run agents or respond to remote queries to determine their health, devices such as networked printers, phones, PDA's, game machines, cameras and so forth usually do not have the capacity or standard capability to respond to standard or even alternate NAC challenges such as web access redirection or 802.1x-based authentication. Therefore organizations implementing NAC usually end up using exceptions such as MAC or IP address authentication, or implementing Guest VLANs. Since MAC or IP address authentication can often be spoofed, it is important to consider carefully the security implication on a NAC deployment, and implement separate guest VLAN when possible.
Politics: Like many projects, NAC has the potential to significantly change the way in which people will need to work when using networked resources. Initial implementations can fail if they create too complex remediation processes, or worse, force a user into a dead-end where they are unable to work at all. The commonplace example is a critical deal being lost because some individual could not get on the network to obtain or submit critical time-sensitive information. Make that person an executive and the example can often become more serious.
Another political issue is bringing together desktop management, network management, help desk, and security teams to work alongside the business to ensure that policies do not conflict.
Complex integrations: In order to successfully deliver NAC, it is required that all parties work well together. Today many vendors provide their own partner integration programs.
Proprietary solutions: Today most vendors offer their own agent technology. Firstly the initial lack of common baseline functionality and standards has forced vendors to implement or OEM client agents that cannot work with other solutions. An ongoing disconnect between standards and proprietary solutions remains at the network level, which limits comprehensive innovation across the NAC management space, in terms of standard Integrations with tools such as SIM/SEM, change management, network management, and similar tools.
Security vs. Policy: Introducing NAC agents to your environment can be a costly and complex exercise as there is the issue of creating an agent stack. Many NAC solutions offer dissolvable agents to mitigate this risk, however, as your NAC enforcement policies become more complex, the limitations of only using pre process checks against continuous checks (e.g. behavioral checks) will begin to force the need to for a permanent agent.

HP is working on all these areas through a combination of standards activities, partner integrations and advanced service delivery capabilities. In addition, HP ProCurve's unique identity and immunity solutions already provide advanced NAC capabilities across the network to the port and endpoints that are part of the evolving NAC environment.

NAC (Network Access Control) - A HP View

2007-11-30T23:21:00Z

I've been looking at the hype, potential and sometimes disappointment associated with the Network Access Control (NAC) market (and its kin - NAP/CNAC etc).

The needs are relatively obvious in terms of protecting data, protecting resources and validating compliance - HP's Secure Advantage approach to securty encapsulates these goals as well - however, the benefits sometimes hard to quantify.

HP’s approach to NAC is comprehensive in its scope and flexible in its delivery evolved from a security model that requires analysis of the business needs, governance models and operational risk management. HP states that NAC cannot be an isolated security solution. NAC is part of a layered security, or Defense in Depth approach to protecting your organizations information technology assets.

HP looks at NAC as a combination of software, hardware, services and processes designed to protect a network from untrusted or unsecured endpoints while providing clear policy compliance across the corporate network environment. HP Enterprise NAC incorporates:

Policy Management and Compliance – NAC controls and restricts access to network resources based on certain criteria (e.g. posture/health) and business policies
Endpoint Protection – NAC solutions include authentication (user and endpoint), endpoint health checks, and/or ongoing monitoring of endpoint health
Network Security – Complete NAC solutions incorporate appropriate endpoint, edge, core, LAN and WAN controls.
Remediation – NAC also provides mechanisms to quarantine and remediate non-compliant devices to allow them appropriate access to network resources.

While these are the core functional aspects of NAC, other service and solution requirements need to be considered including: ISSM, ITIL, ANA, Identity Management, IDP, HIP, Help Desk.

The business benefits of proper NAC solutions are significant, and include:

Improved Compliance and Governance - When dealing with regulatory or corporate compliance requirements, NAC allows an organization to significantly improve their ability to ensure that access to specific systems and data is only available to specific authorized devices and users that comply with policy. Additionally with the right implementation, the ability to audit and report on the environment is increased. NAC implementations then allow for the high level governance capabilities to be aligned with common network security due diligence used in many different governance frameworks.
Improved security posture - NAC provides an additional protection layer for an organizations Defense in Depth or Layered Security requirements. While it requires analysis specific to an organization, the goal is to minimize risk to the network business resources from unauthorized, unhealthy and out-of-compliance devices and endpoints, and subsequently minimize risks resident in environment where user is connecting. By doing this, NAC can reduce unnecessary exposure of corporate assets, for example, if a PC is running P2P software then there is a risk that confidential docs could be inadvertently shared. This could then be caught, audited and blocked by ensuring the PC does not get on to the secured network.
Improved operational cost management - Ranging from virus infection through to data loss, organizations face tremendous pressures to prevent breaches, while at the same time maintain or decrease cost structures. Investing in NAC capabilities allows an organization to increase the security posture while ensuring that fewer issues need to resolved post-breach. Unfortunately, costs associated with resolving security breaches after the fact are often hard to quantify, however, there is a mountain of data available that provides a baseline for such events.

Interestingly, the cost benefits are sometimes overlooked, yet there are a multitude of methods and real life data that provides clear business case metrics - The US TJ Maxx compromise shows that network security is critical, and the losses can be immense, both in terms of financial and credibility hits - beyond that think slammer, rootkits, ip/data losses, etc. NAC can provide a large piece of the solution.

In upcoming posts I'll take a look at the challenges for NAC, the standards, and the future evolutions.

Full White Paper on Federation Router now available...

2007-11-30T23:19:00Z

With some of my recent posts I've been illustrating the benefits and capabilities of the Federaton Router available in HP Select Federation 7.

I am now pleased to be able to refer you to a complete white paper written by Jason Rouault, HP's Chief Technologist for IdM available on the Liberty Alliance site. You can download it here: http://www.projectliberty.org/liberty/content/download/3782/24970/file/HP%20SF%20Router%20whitepaper.pdf

This white paper includes the use cases I referred to - including:

Edge Router
Tiered Router
Trusted Authority Router; and
Router with IDP

Jason summarizes:

The federation router architecture eliminates [] complexity. It allows an organization to have a single interface to the partners. With a single negotiation of technical and legal agreements, organizations can establish a partnership that may optionally be leveraged by various business units. Additionally those business units may interact with each other through a single interface without the need to support multiple protocols or to negotiate beyond the granting of access to the application to the business unit partner. The federation router architecture helps reduce the number of partnerships that need to be set up, while improving oversight, monitoring, controls and audit of the partnerships. It helps reduce the time-to-market and legal and planning costs, while insulating the organization's partners from the inevitable change that occur in its IT environment. The result is improved business continuity at a reduced cost.

I've recently seen folks adopt the term "Identity Router" as well, but note that the functionality they consider to warrant the term routing is limited and manual. Take a look at the management capabilities available in HP Select Federation. Then consider how much benefit this offers a deployment that needs to deliver quickly, and scale effectively over short or long periods of time.

Gartner Identity and Access Management Speaking Notes...

2007-11-12T13:41:00Z

After spending the first day at the conference I was struck by how many of the presentations seemed to run on, and into each other... critically so in terms of verbosity on the page and directly from the speakers. While ultimately interesting in terms of viewpoint, it took a lot of effort to get to the core of what points were trying to be made.

As a result, I reworked my own presentation on the first night, effectively giving it a theme of "Heroes and Villians" as opposed to the that suggested by the title marketing allowed me to have - "8 Concepts to Explain, Justify and Deliver Successful Identity Management".

On the day (Thu), I was concerned for attendance, as it seemed we had been given the Siberian room (i.e. a long way from the main conference rooms), making it a challenge for people to drop in a see if they liked what they saw before commiting to a session. I was surprised therefore to see the room swell and fill to over 100 folks. I was very interested when I asked how many folks were attending this type of conference for the first time, and almost half the audience put their hands up.

Well... this was either going to backfire or it was going to be the most interesting talk folks saw over the event.

I started out with the agenda - still 8 items...

Heroes
Villians
Teamwork
Money
People
MacGuffins
Government
HP

I think this provided a very unique 8 points (should I say "concepts") for the audience, and based on the feedback, it was useful as well as interesting - well, except for MacGuffins which no-one in the audience knew the definition of... so I'll use the term "gadgets" instead for any future talks.

Was it what folks expected based on the original title? Probably not.

Was it entertaining yet interesting? I think so based on the feedback I received.

If you missed it, or would like to talk some more, give me an email or commentary - tell me if it helped or hindered.

Speaking at Gartner Identity and Access Management Summit - Nov 15

2007-11-06T21:23:00Z

Next week, I along with many other Identity Management illuminaries will be converging on Los Angeles to attend the Gartner Identity and Access Management Summit at the Hyatt Regency Century Plaza in Los Angeles, CA.

The summit is scheduled for Nov 14-16. I'll be speaking on Thursday 15, at the 2:45 session, offering you 8 Concepts to Explain, Justify and Deliver Successful Identity Management. We've heard from many folks, including Gartner, that many folks having started their implementations, have yet to see the returns expected, or worse, encountered failures. How did they begin, how did they plan, and what measurements did they use to determine success or failure? Its more interesting that it sounds, and you may even see a hero or two appear as I run through some key concepts to help deliver your success (8 to be specific, 9 to be rebellious)...

I'll be around Wednesday and Thursday if anyone would like to talk, however on Friday, I'll be off to another conference.

Why does the world need a Federation Router?

2007-10-30T06:51:00Z

In my previous post on Federation, I noted that HP releases game changing "Federation Router" in Select Federation 7.0.

The question then is: Who needs it?

In this entry I wanted to take a further look at the challenges that drove this development. In subsequent entries I'll take a look at the various deployment options that deal with the challenges...

Federated identity technology is rapidly growing in adoption. New management challenges that never existed before are resulting out of its early success. Federation depends upon trust relationships (business policy) between independent entities; Trust between an Identity Provider (IDP) and Service Provider (SP); Trust between Web Service Provider and Web Service Consumer.

Common use cases of federation deployments today include allowing employees to seamlessly access their benefits information which is provided by independent benefits provider enterprises, or allowing consumers of to seamlessly access different services provided by independent divisions of the same enterprise.

Adoption of Federation technology and the evolution of federation standards have introduced a need to deal with issues that are not necessarily new to an organization, but are in a different context. These issues are not apparent in small deployments, when the number of federation partners is fairly limited or very uniform. Complexity of the deployment grows exponentially as the number federation partners increases and/or the number of federation protocols supported increases.

It’s a classic problem of scale that needs to be management up front, and over time.

Diagram 1 demonstrates the sets of relationships that might be required between federating entities from an enterprise (Employer) and outsourced employee service provider (Benefits Provider). In this example a large engineering enterprise has an aeronautical division, medical systems division and a financial services division. The enterprise as a whole has contracted with a benefits provider for health and dental benefits. However, since each of the divisions in the enterprise is independent, each has its own identity management processes. Further, the Benefits Provider is actually a merger between two benefits providers, one which provides medical benefits and the other providing dental benefits. As a result, the systems within the benefits provider are also independent. The enterprise has now mandated that all employees must receive seamless access to their benefits information. This means that each division would have to explicitly trust each service of the benefits provider so that employees from each division get seamless access to their personal medical and dental benefits information.

For each of the federation relationships depicted in the diagram 1, business and technical policy must be defined to address trust, protocol usage, attribute mapping, and security. Since trust agreements are based upon business and regulatory policies, they are typically legal documents requiring costly legal review. Thus, having a large number of legal agreements is less than desirable to simplify and reduce costs of governance and management of contracts. Furthermore, non-technology processes will lengthen the duration of federation IT projects adding further delay and uncertainty to the process. These issues become a hurdle for rapid adoption of federated identity management.

As new IDP’s and SP’s relationships are added to the federated environment, there will undoubtedly be new federation protocol requirements.

Diagram 2 depicts the complexity that can arise related to federation protocols and the need to match the capabilities of your partner. Either an IdP will need to add support for an additional federation protocol when interacting with the new partner (e.g. Aerospace division uses WS-Fed when interacting with the Travel Service Provider), or the SP will need to add support for a protocol that the IDP(s) already supports. Either way, this can become a hindrance to doing business, not to mention complicates configuration and support of the environment for any particular federating entity.

Simplifying Federation Management and Accelerating Deployments

In today’s TCP/IP networking environment, much of the work to get a message from one computer to another is done by routers, because they're the crucial devices that let messages transit between networking domains. These routers play the critical role of directing traffic, ensuring message delivery, providing protocol translation, and allowing for special handling of requests.

With HP Select Federation, HP is applying the same principles behind network routers to the processing of identity federation. HP Select Federation 7.0 has introduced a new capability that allows for its deployment as a federation router. A federation router simplifies the relationships between federated entities.

Diagram 3 depicts a view of how the federation relationships between federating entities from an enterprise (Employer) and outsourced employee service provider (Benefits Provider) have now been condensed, as compared to the pair-wise deployment without a router shown earlier.

With the federation router, not only are there less trust relationships, but the management of the relationships, including the information conveyed about users, authentication policies, etc. can move away from the individual divisions to being managed at the enterprise level.

NEXT…

This entry describes the basics of the Federation Router, and as with all things the real test is in the deployment and management. Fundamentally this model allows for some very interesting and time-saving deployments at scale. So, as I noted in my introduction, I will begin to detail deployment options for the Federation Router in upcoming posts that show clear benefits in terms of management and scale for any size deployment.

HP releases game changing "Federation Router" in Select Federation 7.0

2007-10-05T23:22:00Z

Most enterprise level technologies face the issue of scalability at some point. Most vendors try to support more and more protocols and similarly, more and more features, without changing the way in which their tool is managed, creating a significant issue for businesses that wish to scale at speed. HP believes that management and modeling technologies are critical for technology to deliver for business.

As a result, HP introduces the “Federation Router”, available in HP Select Federation 7.0.

The thinking here is that as the adoption of federation technologies has grown, it has become increasingly evident that that required pair-wise business and technical agreements between federating entities does not scale. Each federation relationship requires a business/legal agreement, meta-data exchange, determination of protocol usage, user mapping, etc. While these issues are manageable “in the small”, this complexity grows exponentially as the variety of federation protocols and number of federation partners increases.

Just as a network router simplifies the relationships between network entities by directing traffic, ensuring message delivery, providing protocol translation, and allowing for special handling of requests, a federation router simplifies the relationships between federated identity entities. The federation router will enable identity to be a more pervasive aspect of the enterprise infrastructure – transforming the enterprise and blurring the lines between the enterprise and extended enterprise.

Adopting the HP federation router architecture will allow enterprises to be more ready for organizational change; to be better integrated with customers, partners and suppliers; and to easily scale these capabilities as there electronic business relationships grow. The primary issue of deploying multiple federation brokers even is that a change in business policy requires IT administrators to change policy in all deployed federation solutions. By pushing links through centrally managed routers, changes can be managed and deployed simply and effectively.

Simply put, a federation router acts as an SP to an IDP on one side and then turns around and acts as an IDP to an SP on the other side. The Liberty specifications proposed the use of such “identity proxies” first in its Liberty ID-FF 1.2 specification, and it is now a part of the SAML 2.0 specification. However, the HP federation routers architecture takes the idea of identity proxies further by fulfilling the following purposes:

Acts as an intermediary between multiple organizations, some of which are on the “inside” and others on the “outside”.
Abstracts the details of each side for the other. Hides backend infrastructure (various Federation protocols, agreements, multiple IDPs, etc.)
Maintains trust relationship with identity components on the inside and outside. This reduces the overall number of trust relationships that need to be managed.
Maintains policy about which users on one side have access to which applications on the other side
Transforms user identity representation so that applications can get all information they need about a user in the format they expect.
Performs protocol translation, ensuring that federating entities receive messages in the format they support
Possible to make internal changes without requiring communication to or coordination with external partners

Let me know if you’d like to talk more. In a follow-up post I’ll give some examples of how this works in real world applications.