Tag Archive for: Access Management

Developing an Entitlements Management Approach

/in , , , , , , , , , , , , , , , , /by

We were sitting down with a client during some initial prioritization discussions in an Identity and Access Management (IAM) Roadmap effort, when the talk turned to entitlements and how they were currently being handled.  Like many companies, they did not have a unified approach on how they wanted to manage entitlements in their new world of unified IAM (a.k.a. the end of the 3 year roadmap we were helping to develop).  Their definition of entitlements also varied from person to person, much less how they wanted to define and enforce them.  We decided to take a step back and really dig into entitlements, entitlement enforcement, and some of the other factors that come into play, so we could put together a realistic enterprise entitlement management approach.  We ended up having a really great discussion that touched on many areas within their enterprise.  I wanted to briefly discuss a few of the topics that really seemed to resonate with the audience of stakeholders sitting in that meeting room.

(For the purpose of this discussion, entitlements refer to the privileges, permissions or access rights that a user is given within a particular application or group of applications. These rights are enforced by a set of tools that operate based on the defined policies put in place by the organization.  Got it?)

  • Which Data is the Most Valuable?- There were a lot of dissenting opinions on which pieces of data were the most business critical, which should be most readily available, and which data needed to be protected.   As a company’s data is moved, replicated, aggregated, virtualized and monetized, a good Data Management program is critical to making sure that an organization has handle on the critical data questions:
    • What is my data worth?
    • How much should I spend to protect that data?
    • Who should be able to read/write/update this data?
    • Can I trust the integrity of the data?
  • The Deny Question – For a long time, Least Privilege was the primary model that people used to provide access. It means that an entitlement is specifically granted for access and all other access is denied, thus providing users with exact privilege needed to do their job and nothing more.  All other access is implicitly denied.  New thinking is out there that says that you should minimize complexity and administration by moving to an explicit deny model that says that everyone can see everything unless it is explicitly forbidden.  Granted, this model is mostly being tossed around at Gartner Conferences, but I do think you will see more companies that are willing to loosen their grip on the information that doesn’t need protection, and focus their efforts on those pieces of data that are truly important to their company.
  • Age Old Questions – Fine-Grained vs. Coarse-Grained. Roles vs. Rules. Pirates vs. Ninjas. These are questions that every organization has discussed as they are building their entitlements model.
    • Should the entitlements be internal to the application or externalized for unified administration?
    • Should roles be used to grant access, should we base those decisions on attributes about the users, or should we use some combination?
    • Did he really throw Pirates vs. Ninjas in there to see if we were still paying attention? (Yes.  Yes, I did).

There are no cut and dry answers for these questions, as it truly will vary from application to application and organization to organization.  The important part is to come to a consensus on the approach and then provide the application teams, developers and security staff the tools to manage entitlements going forward.

  • Are We Using The Right Tools? – This discussion always warms my heart, as finding the right technical solution for customers IAM needs is what I do for a living. I have my favorites and would love to share them with you but that is for another time.  As with the other topics, there really isn’t a cookie cutter answer.  The right tool will come down to how you need to use it, what sort of architecture, your selected development platform, and what sort of system performance you require.  Make sure that you aren’t trying to make the decisions you make on the topics above based on your selected tool, but rather choose the tool based on the answers to the important questions above.

Building an IAM Roadmap – A five step process

/in , , , , , , , , , , /by

Since 2003, our teams have been part of over 350 efforts to implement or rescue Identity and Access Management (“IAM”) projects.  Our customers, most of whom have become great friends, are from all over the US, crossing many disparate and unique industries.  In most cases, they are working to solve similar business problems and to fix or improve the same processes.

On many occasions, we started from the ground floor and had the opportunity to create a roadmap for their long-term strategy.  To those familiar with IAM capabilities, it may seem obvious what to prioritize and where to start, but let’s not be so quick to jump to what looks like an easy decision.  All IAM capabilities are not created equal.

Our job as a systems integrator is to successfully implement these complex IAM security technologies, and to ensure that our customers maximize the return on their significant IT investments.  As we help guide our customers through these decisions, this ROI is always our priority, which leads us to the topic for today.

So how, exactly, can we accomplish this?  This article is all about alignment.  Having alignment between IT and the other key stakeholders will significantly reduce the risk of your IAM projects failing and losing or wasting precious budget dollars.

How can you ensure you have correct alignment?  Here’s how our IAM Roadmap process breaks down.

Step 1 – We start by prioritizing a list of over 100 key IAM capabilities.  This list was compiled from our work over the years and is vendor agnostic.  After a brief explanation to help educate the stakeholders, we apply a ranking of low, medium or high based on their opinion on how important the organization needs a certain capability.  Typical examples of high priority capabilities are automated provisioning of accounts, self-service password reset and role recertification.

Here’s a common example of the final output

Step 2 – Once you have a high priority list to work from, we dig a little deeper into three categories of analysis.  The first category is Business Benefit – How significant is the true Business Benefit of this capability?  Is this just a shiny new IT toy or will the stakeholders see lift and leverage from adopting this functionality.  It’s critical to have your business stakeholders at the table so they can weigh in.

Step 3 – The second category is for your technical staff regarding Technical Complexity – How technically difficult will it be to configure or customize this solution?  Are there products that provide this feature and function out of the box?  Will your team be able to update and maintain the tools going forward or is this going to be way outside of their comfort zone and expertise?  Is it cost prohibitive based on the benefit?  This is where we can weigh in to help provide some context as well.

Step 4 – The third and last category is about Organizational Readiness – can the company readily adopt the capability?  Are there so many competing priorities that gaining mindshare and focus will be difficult?  Do you have the buy-in from stakeholder leadership?  Is everyone at the table truly on board with this project and these priorities?  Will they drive the effort through their organizations?

Step 5 – Once you’ve made it through this list and conducted a robust debate and Q&A with these three key questions, it’s time to score and rank the results.  Amazingly you will see a handful of capabilities that float to the top where the Business Benefit is high, the Technical Complexity is low and the Organizational Readiness is high.  After a short review of the results with some discussion and debate, a solid scope of high priority capabilities emerge as candidates for the first one or two phases of a successful program.

The next step is to choose a product that can fulfill these priorities, and then you are off and running.  The advantage you have is that your stakeholders are more educated and have bought into the process and priorities – they are aligned.  At the first sign of deviating from scope or questioning why we are including specific capabilities, you simply go back to the prior analysis and remind the team of the decision-making rationale.

Does this IAM Roadmap process guarantee a successful project or program?  Not necessarily.  But having all your stakeholders at the table and aligned provides a huge advantage and a great start.

 

What is Single Sign-On?

/in , , , , , , , , , , , , /by

As I was preparing for Gartner’s Identity and Access Management conference next week in Las Vegas, I was thinking about some of the typical topics that attendees usually ask us about.  There are always the people that want more information about the sexy, cutting edge topics like the Internet of Things, Privileged Identity Management and Adaptive Access Control.  I love talking about these subjects as they are new and involve interesting problems.  Solving interesting problems is fun and the reason many of us got into the information security field.

Another topic that frequently comes up isn’t quite as sexy or fun but really is a foundation function for a mature IAM system:  What is Single Sign-On (SSO)? It seems like SSO is viewed by many as a commoditized feature these days but a surprising number of organizations are still in the early stages of investigating SSO and what it might mean for them.

When explaining SSO to someone, I used to lead off by trying to break the news that they are really never going to have 100% single sign-on but as more and more legacy desktop fat client applications become web-enabled it is much more likely that they might be able to approach a true single sign-on.  These days I just get into a quick overview of what SSO means across a variety of different use cases.

  • Web-Based Single Sign-On – The most commonly recognized type of SSO is the sharing of credentials and user sessions across a common set of internally managed web applications. These can be things like Oracle e-Business Suite applications, portals and most other non-Software-as-a-Service (SaaS) web applications.  A user will be authenticated when the system validates username and password (plus additional factors in some cases).  They are given a session token in the form of a browser cookie that is validated and updated as they travel from application to application.  Usually the same Access Management system provides some level of authorization into these applications but we’re not going to get into all that entails.
  • Federation – Federation is a standards based method of authenticating users into applications hosted by a third party, also called Cloud-based or Saas. Think of SalesForce.com or any of a variety of Oracle’s Cloud applications. There are two sides to a federated agreement: Service Provider controls the actual application, and Identity Provider controls the user IDs and passwords.  The session token is typically a SAML assertion that is consumed by both parties and includes all of the relevant user information.  These SAML assertions can typically be consumed by the Access Management system that provided SSO for the internal applications, allowing users to seamlessly move from application to application regardless of where that application is hosted. (As an aside, when you hear Identity as a Service (IaaS) tossed around, typically is refers to a federation model when you still control your account information but the IaaS is used to broker application access via federation.)
  • Windows Native Authentication – This is the bridge to true SSO by allowing the Access Management system to integrate with a Windows domain to provide a seamless experience. A user will authenticate into their domain as they perform their initial login.  Once they are validated, they will received a Kerberos ticket from the domain controller that contains user and session information much like the browser token or SAML assertion.  When they launch an application that is protected by the Access Management system, the Kerberos ticket will be consumed, validated and then used as the basis to issue its own session token.
  • Enterprise SSO – eSSO, or desktop SSO, is based on agents being installed on each work station to handle the login in process for fat client and legacy applications. We don’t see this nearly as much since more and more applications are moving to the web.

An example to tie it all together – I sit down at my workstation and log in for the morning. A Kerberos ticket is issued.  I decide that I need to check the status of a customer lead in Salesforce.com so I launch a browser and go to the site. When I land on the app, it will query its Identity Provider (our Access Management system) who I am.  The Access Management system sees that I have a valid Kerberos ticket so it will create a SAML assertion and send me back to Salesforce.  This all happens behind the scenes and is usually pretty quick.  Once I am done on SalesForce, I need to go to Oracle e-Business to check on the status of an order.  I browse to the app.  The Access Management system sees that there is an active SSO session (via the SaleForce visit) and creates a new browser cookie to manage the session.  I’d be able to go between any integrated app, onsite or in the cloud, and have SSO for the duration of that session.

Obviously, this is a super-simplified version of how SSO works but I find that it gives people who don’t have a working knowledge of IAM concepts a good understanding of the functionality that is typically grouped under the SSO umbrella.

As a note, PathMaker Group typically implements SSO early in the release roadmap as it can be a quick win that shows value and progress to stakeholders.  We can get through a typical SSO project from requirements through production deployment in 3-4 months depending on scope and complexity.  Reach out to us to see how we can help you get your SSO project underway.

 

 

 

Three Characteristics of a Mature Identity and Access Management Program

/in , , , , , , , , , , , , , /by

Identity and Access Management (“IAM”) as an industry started gaining significant recognition and momentum around 2003. During these last 12 years, we’ve seen product vendors come and go, we’ve seen industry consolidation, and we’ve seen important product innovation driven by real business need.

While all this has been going on, many companies have leveraged IAM products to achieve important and significant gains in security, efficiency and compliance enforcement. On the other hand, some companies have tried and tried to establish effective IAM programs only to fail in their attempts to affect real change.

What makes one company succeed and another one fail while attempting to leverage the same products and technologies? What are the characteristics of a truly mature IAM program?

Over the next few weeks, I will attempt to address these questions. I also hope to create an important dialogue among those of you who have “been at it” for the last 5-10 years and have seen and been part of great successes and colossal failures. Although I have been part of hundreds of IAM projects, and will lend my experience to the discussion, you, as the readers and contributors, may have much more to contribute to make this topic come alive. Will you help?

Let’s get started with three important characteristics of a mature IAM program. This list is not exhaustive but these capabilities are common among organizations that have made IAM a strategic part of the IT infrastructure.

#1 – User Identity Integration

Pieces and parts of a user’s identity can exist across many different systems in an enterprise. HR systems are an obvious source along with IT systems like Active Directory. Then there is the badge or physical access system, the phone system, and various business applications that become critical for a user to perform their role. Before long, keeping up with all these disparate systems and keeping user attributes current becomes unmanageable. Most organizations recognize the problem and also recognize the need for a consolidated view of a user’s identity. It seems simple enough, but it takes planning, time and good processes to move an organization down the road to centralizing processes, automating synchronization, and removing redundant identity attributes from across the enterprise.

#2 – Account Provisioning

Creating an account on an appropriate system with the correct permissions is a straightforward task when you’ve been given the right information and you have the time to get it done. When a company grows to around 3,000 employees, the enterprise reaches a tipping point where going about this using people and manual effort becomes untenable. Too many requests for new accounts, or too many changes to existing accounts, or repeated requests to remove accounts for terminated employees all begin to pile up. This creates a backlog delaying new workers from getting started, hampering productivity, or creating security exposures where accounts of terminated employees remain active far too long.   Centralizing and/or standardizing the process can help but adding technology that provides automation will speed up the process along with enforcing identity standards, access entitlements, and important policies and standards. Automatic account removal of terminated employees is also a significant gain. All accounts on key systems can also be tied back to a central, validated user account eliminating unknown, orphaned user ids from across the enterprise.

#3 – Password Management

Password management activities face a similar challenge as an organization grows and adds more and more people, systems and applications. Initial steps should be to provide tools to help desk personnel centralize and automate this activity. Ultimately an organization needs to move this function away from the help desk and enable the end user to manage his own passwords on key systems, including resetting their own Active Directory password. This is another step that seems simple on the surface but can actually take a significant amount of planning and coordination to get it right and keep it running smoothly. Organizations that make a misstep on their first attempt find it difficult to gain user adoption the second (or third) time around. Eventually, standardized help desk procedures can assist the user community in adopting the self-service approach to managing passwords.

 

Identity integration, provisioning and password management are three essential building blocks, but there are another 8 – 10 key capabilities we could discuss that should be considered when talking about IAM maturity. What other capabilities would you consider to be essential building blocks? Please contribute to the discussion.

Up next, let’s talk about the essentials for planning a long-term, mature IAM program. If you’re just getting started or have been struggling to make progress, what are some of the keys to putting plans in place that can be effectively executed?

5 Keys to Addressing Privileged Access

/0 Comments/in /by

Most security breaches require some form of privileged access to result in any serious damage being inflicted. You know you need a Privileged Access or Privileged Identity Management solution but don’t know where to start? Here are 5 keys to jump start your project and get you on your way to 1) reducing the cost of providing privileged access, 2) decreasing the risk of security incidents and 3) lowering the time it takes to grant privileged access:

1. Temporary vs. Permanent Privileged Access
Some employees use privileged access every day, all day in order to perform their daily job responsibilities. Others only need temporary privileged access to perform a project, incident or change management activity. Should you treat both of these groups the same? Some factors to consider are:

• Historical risk – past audit issues with either group
• Size of each user population – are there many more temporary access users
• User type – are there more internal vs. external users in either user population

2. Resource Classification
Have you classified your privileged access endpoints into tiers that could be used to determine the rigor required to provide privileged access? A typical organization will have hundreds or thousands of endpoints that need to be defined in the Privileged Access solution. Defining tiers of resources will help to prioritize deployment and map the appropriate workflow around the privileged access request process. Some recommended tiers are:

• Tier 1 – resources that drive financial reporting to auditors or regulatory agencies
• Tier 2 – resources that are mission critical to company operations
• Tier 3 – resources that contain very sensitive personally identifiable information

All other endpoints should be ignored until these prioritized resources are addressed.

3. Authoritative Source for Check-Out / Check-In
Do you have an authoritative source that can be used to drive check-in and check-out of privileged credentials? This is the most important component to making the privileged access workflow a smooth and natural process for the end users. The most common authoritative source is an IT Service Desk System used for request, incident & change control tracking. The presence of an open ticket assigned to the protected resource both automates the check-in/check-out process and restricts who can request privileged access at the same time.

4. Automated Provisioning
Delivering privileged access efficiently requires an automated mechanism to update the account password or entitlements. Integrating the privileged access solution with an existing identity management system is a key consideration. The identity management system has connectors deployed for the protected resources which will allow:

• Self Service – to request privileged access
• Workflow – to automate the check-in/check-out process
• Account Updates – to grant/remove privileged access
• Recertification – to drive audit & verification of users with privileged access

5. Privileged Roles
Knowing which groups of privileged users are entitled to request privileged access to various groups of protected resources is an important aspect in providing a privileged access solution. Having these roles defined ahead of time and mapped to the appropriate resources can dramatically reduce the time it takes to deliver a solution. Some common privileged access roles are:

• Server Administrators – to grant server admin access
• Database Administrators – to grant database admin access
• Application Administrators – to grant application admin access
• Security Administrators – to grant security admin access
• Desktop Administrators – to grant desktop/laptop admin access

Getting a handle on these topics will allow you to jump start your Privileged Access implementation and get you well on your way to a more secure environment that provides a seamless end user experience for your administrators.

 

Identity and Access Management Best Practices Webinar

/0 Comments/in , , /by

How Levi leveraged Identity Management infrastructure to enable “just in time” fully automated privileged system access

Presented by:

  • Chuck Lankford, Global Director of Security at Levi Strauss & Co.
  • Chris Fields, Vice President of Security Strategy, PathMaker Group
  • Ravi Srinivasan, Director of IBM Security, Strategy, and Product Management

In our 50 minute webinar you will:

  • Learn about the latest market trends in Identity and Access Management
  • See why the IBM IAM Suite is one of the hottest sellers in the last six months
  • See what’s new with the IBM IAM Suite including upcoming features and capabilities
  • Hear what customers are buying and why
  • Learn the five most common benefits from a robust IAM infrastructure
  • Learn about best practices for implementing provisioning, access management, federation
  • Hear customer use cases and their key business drivers for IAM

Chuck_Lankford

About the key presenter, Chuck Lankford:

Chuck is the Director of Global Information Security for Levi Strauss & Co. and has responsibility for protecting LS&Co. from threats to the confidentiality, integrity and availability of LS&CO systems, information and infrastructure. Chuck has been with LS&Co. more than 10 years has served in global IT leadership roles for 17 years. Prior to joining LS&Co. Chuck was Director of Global Networking for network products manufacturer 3Com (Santa Clara, CA) where he architected and managed 3Com’s global voice, data and video networks. Chuck holds numerous certifications including Certified Information Security Systems Professional (CISSP), Certified Ethical Hacker, Certified Information Systems Auditor (CISA) and Certified Information Systems Risk Consultant (CISRC).test

Chris_Fields

About Chris Fields:

Chris has held his CISSP certification since 2003 and is the Identity Management Architect & Visionary responsible for setting the strategic direction and architecture approach for all of our IBM identity and access management projects. He is also responsible for managing partner relationships with identity management vendors. Chris’ love of technology makes everything about his job enjoyable. Mentoring and expanding the technical skill sets of his employees is the most enjoyable aspect of his daily activities. Equally enjoyable is the time spent helping clients to understand the industry and discuss viable options for them to begin and mature their identity and access management infrastructures.

Ravi_SrinivasanAbout Ravi Srinivasan:

Ravi manages the IBM identity, access and mainframe security portfolio strategy and product management based in Austin, Texas. He has over 15 years of experience in product management, market strategy, and development in software and services industries. Ravi meets and consults with senior management, lines of business owners and IT operations management around the world on their key security, risk, and compliance initiatives. He’s also a frequent speaker at trade, analyst conferences and customer events to share a worldwide customer perspective and insights on secure mobile, cloud and social business transformations. Ravi mentors several security services practitioners and product managers to develop practical solution approach to changing security, risk and compliance needs.

7th Stage (Security) of IS growth, Part II

/0 Comments/in , , , , /by

A little background:

Now that you’ve been in the CIO’s position for your first quarter, it is time to prepare for your first review with the board of directors.  The agenda for the IS presentation will cover key factors that you discovered in your operations, your accomplishments and your plans for the next year.  Since this is the quarter for your next year’s budget, it should contain the funding needed to accomplish the IS plan.

One of the key factors in the review of your operations was discovering the lack of security focus and non-compliance issues that made the operations vulnerable to unwanted intrusion in your network.  Listed in your accomplishments is the Security Assessment study and recommendations provided by PathMaker Group when you engaged them for a study of your IS environment.  One of their recommendations was to deploy IBM’s Security products for managing Identify and Application Access in your enterprise network.  This is an important undertaking as your company will replace the outdated security monitoring with IBM’s Showcase Solution to keep unwanted intruders out while making it easier for the authorized users to have easy access to their applications.  As a result of PathMaker Group’s findings and recommendations, you asked them to submit a proposal for the corrective solution using IBM Security Products and PMG Professional Services to deploy them in your IS Network.

This section of your review was very well received by the board of directors and they gave you the approval to get started.

Read more

OIM User Attributes Modification

/0 Comments/in , , , /by

While integrating Oracle Identity Manager within a corporate environment, sometimes it is important to change some user attributes externally. OIM API provides simple means to perform these operations.

As is the case in any operation, a connection needs to be made to the OIM instance. This is a simple task, but one must ensure that credentials are properly stored and protected.

 

protected static OIMClient client;

private static String OIMInitialContextFactory = “weblogic.jndi.WLInitialContextFactory”;

 

public OIMConnect(String fileName) throws Exception

{

Hashtable<String, String> env = new Hashtable<String, String>();

env.put(OIMClient.JAVA_NAMING_FACTORY_INITIAL, OIMInitialContextFactory);

env.put(OIMClient.JAVA_NAMING_PROVIDER_URL, CONNECTION_URL);

client = new OIMClient(env);

System.setProperty(“java.security.auth.login.config”, AUTHCONF_FILE);

System.setProperty(“OIM.AppServerType”, “weblogic”);

client.login(OIMUSERNAME, OIMUSERPASSWORD.toCharArray());

return;

}

Read more

7 Minutes of Terror

/0 Comments/in , , , , /by

Last month we witnessed an amazing feat of science & engineering with the landing of NASA’s Curiosity Rover on Mars. Before this could be accomplished years of preparation through innovation, design & testing had to occur. It all culminated towards what the NASA scientists and engineers at JPL call “the 7 minutes of terror” – the 7 minutes between when Curiosity entered the Mars atmosphere and when it was expected to land. Of course we know now that it was a fantastic success – but what made it so? How does an organization accomplish such a fantastic undertaking?

Well it got us here at PMG thinking; what is it that we do together with our clients that makes projects a success? We know we’re not rocket scientists, but it’s still fun to day dream & draw some interesting connections between the Curiosity mission and our own business and philosophies.  Read more