Research

For some of you steeped in IAM concepts, our previous post on Role Lifecycles seems a bit basic. But many enterprises are still grappling with how to plan for, implement, and manage roles throughout the enterprise. There are many systems which contribute to roles and privileges, so what may seem basic in theory is often quite complex in practice. Today’s post will dig a bit deeper into more advanced RBAC concepts. Let’s roll up our sleeves to look at role engineering! Role Engineering To get value from roles in real-world use cases requires spending some time analyzing what you want from the system, and deciding how to manage user roles. A common first step is to determine whether you want a flat or hierarchical role structure. A ‘flat’ structure is conceptually simple, and the easiest to manage for smallish environments. For example you might start by setting up DBA and SysAdmin roles as peers, and then link them to the privileges they need.   Flat role structures are enough to get the job done in many cases because they provide the core requirement of mapping between roles and privileges. Then Identity Management (IdM) and Provisioning systems can associate users with their roles, and limit users to their authorized subset of system functions. But large, multifunction applications with thousands of users typically demand more from roles to address the privilege management problem. Hierarchies add value in some circumstances, particularly when it makes sense for roles to include several logical groups of permissions. Each level of the hierarchy has sub-classes of permissions, and the further up the hierarchy you go the more permissions are bundled together into each logical construct. The hierarchy lets you assemble a role as coarse or granular as you need. Think of it as an access gradient, granting access based on an ascending or descending set of privileges.   This modeling exercise cuts both ways – more complex management and auditing is the cost of tighter control. Lower-level roles may have access to specific items or applications, such as a single database. In other systems the high-level manager functions may use roles to facilitate moving and assigning users in a system or project. Keep in mind that roles facilitate many great features that applications rely on. For example roles can be used to enforce session-level privileges to impose consistency in a system. A classic example is a police station, where there can only be one “officer of the watch” at any given time. While many users can fulfill this function, only one can hold it at a time. This is an edge case not found in most systems, but it nicely illustrates where RBAC can be needed and applied. RBAC + A Sometimes a role is not enough by itself. For example, your directory lists 100 users in the role “Doctor”, but is being a doctor enough to grant access to review a patient’s history or perform an operation? Clearly we need more than just roles to define user capabilities, so the industry is trending toward a combination of roles supplemented by attributes. Roles can be further refined by adding attributes – what is commonly called RBAC+A (for Attributes). In our simple example above the access management system both checks the Doctor role and queries additional attributes such as a patient list and approved operation types to fully resolve an access request. Adding attributes solves another dimension of the access control equation: they can be closely linked to a user or resource, and then loaded into the program at runtime. The benefit is access control decisions based on dynamic data rather than static mappings, which are much harder to maintain. Roles with dynamic attributes can provide the best of both worlds, with roles for coarse policy checks, refined with dynamic attributes for fresher and more precise authorization decisions. More on Integration We will return to integration… no, don’t go away… come back… integration is important! If you zoom out on any area of IAM you see they are all rife with integration challenges, and roles are no different. Key questions for integrating roles include the following: What is the authoritative source of roles? Roles are a hybrid – privilege information is derived from many sources. But roles are best stored in a locale with visibility to both users and resource privileges. In a monolithic system (“We just keep everything in AD.”) this is not a problem. But for distributed heterogeneous systems this isn’t a single problem – it is often problems #1, #2, and #3! The repository of users can usually be tracked down and managed – by hook or by crook – but the larger challenge is usually discovering and managing the privilege side. To work through this problem, security designers need to choose a starting point with the right level of resource permission granularity. A URL can be a starting point but itself is usually not enough, because a single URL may offer a broad range of functionality. This gets a bit complex so let’s walk though an example: Consider setting a role for accessing an arbitrary domain like https://example.com/admin. Checking that the user has the Admin role before displaying any content makes sense. But the functionality across all Admin screens can vary widely. In that case the scope of work must be defined by more granular roles (Mail Admin, DB Admin, and so on) and/or by further role checking within the applications. Even this simple example clearly demonstrates why working with roles is often an iterative process – getting the definition and granularity right requires consideration of both the subject and the object sides. The authoritative source is not just a user repository – it should ideally be a system repository for hooks and references to both users and resources. Where is the policy enforcement point for roles? Once the relationship between roles and privileges is defined, there is still the question of where to enforce privileges. The answer from most role checkers is simple: access either granted

Akamai’s research team has an interesting post on how attackers now use web proxies to shield their identities when launching DDoS attacks. Using fairly simple web-based tools they can launch attacks, and by routing the traffic through an exposed web proxy they can hide the bots or other devices performing the attacks. 234 source IP addresses is a surprisingly low number when considering the duration of the collected data (one month), further analysis into the data revealed that out of the 234 IPs, 136 were web proxies – this explains the low number of source IPs – attackers are using web proxies to hide their true identity. In order to understand the nature of these web proxies, we analyzed the domain (WHOIS) information as well as certain HTTP headers and discovered that 77% of all WebHive LOIC attack traffic came from behind Opera Mini proxy servers. So the hackers are abusing Opera’s mobile browser system to launch their attacks. Akamai tracked that back to the devices, which were largely in Indonesia. But were they? Were other obfuscation techniques used to further hide the attackers? Who knows? It doesn’t really matter. The Akamai researchers go on to talk about blocking attackers’ source IP addresses. Of course that requires you to be pretty nimble, able to mine those IP addresses, and to get blocks configured on your network gear (or within your scrubbing service). Then they talk about using WAF rules to protect applications by blocking DoS tools. And blocking HTTP from well-known DoS apps, assuming the attackers aren’t messing with headers.   Understand that blocking some of these IP addresses and applications may result in dropping legitimate sessions from legitimate former customers. Because people who cannot complete a transaction will find a company which can. So it becomes a balance of loss, between downtime and failed transactions. Akamai doesn’t mention built-in application defenses (as discussed in our AppDoS paper), but that’s okay – when you have a hammer, everything looks like a nail. Photo credit: “Hide & Seek” originally uploaded by capsicina Share:

I just finished reading The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. And wow, what a great book! It really captures the organizational trends and individual behaviors that screw up software & IT projects. And, better yet, it offers some concrete examples for how to address these issues. The Phoenix Project is a bit like a time machine for me, because it so accurately captures the entire ecosystem of dysfunction at one of my former companies that it could have been based on that organization. I have worked with these people and witnessed those behaviors – but my Brent was a guy named Yudong who was very bright and well-intentioned, but without a clue how to operate. Those weekly emergency hair-on-fire sessions were typically caused by him. Low-quality software and badly managed deployments make productivity go backwards. Worse, repeat failures and lack of reliability create tension and distrust between all the groups in a company, to the point when they become rival factions. Not a pleasant work environment – everyone thinks everyone else is bad at their jobs! The Phoenix Project does a wonderful job of capturing these situations, and why companies fall into these behavioral patterns. Had this book been written 10 years ago it would have saved a different firm I worked for. A certain CEO who did things like mandate a waterfall development process shorter than the development cycle, commit to features without specifications and forget to tell development, and only allow user features – not scalability, reliability, management, or testing infrastructure improvements – into development might not have failed so spectacularly. Look at blog posts from Facebook and Twitter and Netflix and Google – companies who have succeeded at building products during explosive growth. They don’t talk about fancy UI or customer-centric features – they talk about how to advance their infrastructure while making their jobs easier over the long term. Steady improvement. In some of my previous firms more money went into prototype apps to show off a technology than the technology and supporting infrastructure. Anyway, as an ex-VP of Engineering & CTO, I like this book a lot and think it would be very helpful for anyone who needs to manage technology or technical people. We all make mistakes, and it is valuable for executive management to have the essential threads of dysfunction exposed this way. When you are in the middle of the soup it is hard to explain why certain actions are disastrous, especially when they come from, say, the CEO. And no, I am not getting paid for this and no, I did not get a free copy of the book. This enthusiastic endorsement is because I think it will help managers avoid some misery. Well, that, and I am enjoying the mental image of the looks on some people’s face when they each receive a highlighted copy anonymously in the mail. Regardless, highly recommended, especially if you manage technology efforts. It might save your bacon! We have not done the Summary in a couple weeks, so there is a lot of news! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mort speaking next week at Thotcon. Favorite Securosis Posts David Mortman: NoSQL Security 2.0 [New Series] updated. Adrian Lane: Can’t Unsee. “It was funny … also because it didn’t happen to me.” Sometimes that Rothman guy really cracks me up! Mike Rothman: NoSQL Security 2.0 [New Series]. Looking forward to this series from Adrian. I know barely enough database security to be dangerous and it’s a great opportunity for all of us to learn. Other Securosis Posts Incite 4/16/2014: Allergies. Understanding Role Based Access Control: Role Lifecycle. Responsibly (Heart)Bleeding. Firestarter: Three for Five. FFIEC’s Rear-View Mirror. Understanding Role Based Access Control [New Series]. Defending Against DDoS: Mitigations. Favorite Outside Posts David Mortman: Security of Things: An Implementers’ Guide to Cyber-Security for Internet of Things. Devices and Beyond! <– a PDF, but read it anyway Adrian Lane: Manhattan: real-time, multi-tenant distributed database for Twitter scale. Having just finished the excellent The Phoenix Project, I particularly see success factors in how companies like Twitter, Facebook, and Netflix approach development. Gunnar Peterson: The Heartbleed Hit List. They took the time to go through all the major web services to show who is affected. Good reference. Mike Rothman: NSS Labs Hits Back at FireEye ‘Untruths’. There was quite a dust-up last week when NSS published their “Breach Detection” tests. FireEye didn’t do very well and responded. And then the war of words began. Here is Channelomics’ perspective. Gal Shpantzer: Moving Forward. I think this will be my FS link every week. Dave Lewis: Security on-call nightmares. Pepper: * iptables rules to block all heartbeat queries Research Reports and Presentations Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7. Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Top News and Posts Heartbleed Update (v3) via @CISOAndy DuckDuckGo is the Anonymous Alternative to Google What Edward Snowden Used to Evade the NSA FBI warns businesses of VC IP scams. Soon to be a movie snort. Aereo Streaming-TV Service Wins Big Ruling Against Broadcasters Staying ahead of OpenSSL vulnerabilities Don’t Shoot The Messenger One of World’s Largest Websites Hacked Brendan Eich Steps Down as Mozilla CEO. A series of strange decisions at Mozilla make you wonder what’s up over there. Companies track more than credit scores Whitehat Security’s Aviator browser is coming to Windows Blog Comment of the Week This week’s best comment goes to Marco Tietz, in response to Responsibly (Heart)Bleeding. Agreed. a bit of bumpy road pre-disclosure (why only a few groups etc pp, you guys covered that in the firestarter), but responsible handling from akamai along the way. maybe I’m too optimistic but it seems to be happening more often than it used to. Share:

It was a crummy winter. Cold. Snowy. Whiplash temperature swings. Over the past few weeks, when ATL finally seemed to warm up for spring (and I was actually in town), I rejoiced. One of the advantages of living a bit south is the temperate weather from mid-February to late November. But there is a downside. The springtime blooming of the flowers and trees is beautiful, and brings the onslaught of pollen. For a couple weeks in the spring, everything is literally green. It makes no difference what color your car is – if it’s outside for a few minutes it’s green. Things you leave outside (like your deck furniture and grill), green. Toys and balls the kids forget to put back in the garage when they are done. Yup, those are green too. And not a nice green, but a fluorescent type green that reminds you breathing will be a challenge for a few weeks.   Every so often we get some rain to wash the pollen away. And the streams and puddles run green. It’s pretty nasty. Thankfully I don’t have bad allergies, but for those few weeks even I get some sniffles and itchy eyes. But XX2 has allergies, bad. It’s hard for her to function during the pollen season. Her eyes are puffy (and last year swelled almost shut). She can’t really breathe. She’s hemorrhaging mucus; we can’t seem to send her to school with enough Sudafed, eye drops, and tissues to make it even barely comfortable. It’s brutal for her. But she’s a trooper. And for the most part she doesn’t play outside (no recess, phys ed, and limited sports activities) until the pollen is mostly gone. Unless she does. Last night, when we were celebrating Passover with a bunch of friends, we lost track of XX2. With 20+ kids at Seder that was easy enough to do. When it was time to leave we found her outside, and she had been playing for close to an hour. Yeah, it rained yesterday and gave her a temporary respite from the pollen. But that lulled her into a false sense of security. So when she started complaining about her eyes itching a bit and wanted some Benadryl to get to sleep, we didn’t want to hear about it. Yes, it’s hard seeing your child uncomfortable. It’s also brutal to have her wake you up in the middle of the night if she can’t breathe and can’t get back to sleep. But we make it clear to all the kids that they have the leeway to make choices for themselves. With that responsibility, they need to live with the consequences of their choices. Even when those consequences are difficult for all of us. But this will pass soon enough. The pollen will be gone and XX2 will be back outside playing every day. Which means she’ll need to learn the same lesson during next year’s pollen onslaught. Wash, rinse, repeat. It’s just another day in the parenting life. –Mike Photo credit: “I Heart Pollen!” originally uploaded by Brooke Novak See Mike Speak Mike will be moderating a webcast this coming Thursday at 2pm ET, discussing how to Combat the Next Generation of Advanced Malware with folks from Critical Assets and WatchGuard. Register here: http://secure.watchguard.com/how-to-survive-an-apt-attack-social.html Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. April 14 – Three for Five March 24 – The End of Full Disclosure March 19 – An Irish Wake March 11 – RSA Postmortem Feb 21 – Happy Hour – RSA 2014 Feb 17 – Payment Madness Feb 10 – Mass Media Abuse Feb 03 – Inevitable Doom Jan 27 – Government Influence Jan 20 – Target and Antivirus Jan 13 – Crisis Communications 2014 RSA Conference Guide In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat. Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. Understanding Role-based Access Control Introduction NoSQL Security 2.0 Introduction Defending Against Network Distributed Denial of Service Attacks Mitigations Magnification The Attacks Introduction Advanced Endpoint and Server Protection Quick Wins Detection/Investigation Prevention Assessment Introduction Newly Published Papers Reducing Attack Surface with Application Control Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Eliminating Surprises with Security Assurance and Testing What CISOs Need to Know about Cloud Computing Incite 4 U Traitors are the new whistleblowers: A good thought-provoking post by Justine Aitel on how security needs to change and evolve, given some of the architectural and social disruptions impacting technology. She makes a bunch of points about how the cloud and the “compete now/share first/think later mentality, “ impacts risk. It comes back to some tried and true tactics folks have been talking about for years (yes, Pragmatic CSO reference). Things like communications and getting senior folks on board with the risks they are taking – and ignorance is no excuse. She also makes good points about new roles as these changes take root, and that’s where the traitors and whistleblowers in the title comes from. Overall her conclusion: “This game is no longer just for us nerds” rings true. But that’s not new. Security has been the purview of business folks for years. It’s just that now the stakes are higher. – MR A glimpse of DBSec’s future: From a database design perspective, the way Facebook is customizing databases to meet their performance needs is a fascinating look at what’s possible with modular, open source NoSQL platforms. Facebook’s goals are performance related,

Roles-based access control (RBAC) has earned a place in the access control architectures at many organization. Companies have many questions about how to effectively use roles, including “How can I integrate role-based systems with my applications? How can I build a process around roles? How can I manage roles on a day-to-day basis? And by the way, how does this work?” It is difficult to distinguish between the different options on the market – they all claim equivalent functionality. Our goal for this post is to provide a simple view of how all the pieces fit together, what you do with them, and how each piece helps provide and/or support role-based access. Role Lifecycle in a real-world enterprise Roles make access control policy management easier. The concept is simple: perform access control based on a role assigned to one or more users. Users are grouped by job functions so a single role can define access for all users who perform a function – simplifying access control policy development, management, and deployment. The security manager does not need to set permissions for every user, but can simply provide access to necessary functions to a single shared role. Like many simple concepts, what is easy to understand can be difficult to achieve in the real world. We begin our discussion of real-world usage of roles and role-based access control (RBAC) by looking at practices and pitfalls for using roles in your company. Role definition For a basic definition we will start with roles as a construct for managing the application of security policy in the separation between users and the system’s resources. A role is a way to group similar users. On the resource side resources are accessed via a set of permissions – such as Create, Read, Update, and Delete – which are assigned to roles which need them.   This simple definition is the way roles are commonly used: as a tool for management convenience. If you have many users and a great many applications – each with many features and functions – it quickly becomes untenable to manage them individually. Roles provide an abstraction layer to ease administration. Roles and groups are often lumped together, but there is an important difference. Users are added to Groups – such as the Finance Group – to club them together. Roles go one step further – the association is bi-directional: users are members of roles, which are then associated with permissions. Permissions allow a user, through a role, to take action (such as Create, Read, Update, or Delete) on an application and/or resources. Enforcing access control policy with roles What roles should you create? What are your companies’ rules for which users get access to which application features? Most firms start with their security policies, if they are documented. But this is where things get interesting: some firms don’t have documented policies – or at least not at the right level to unambiguously specify technical access control policy. Others have information security policies which are tens or even hundreds of pages long. But as a rule those are not really read by IT practitioners, and sometimes not even by their authors. Information security policies are full of moldy old chestnuts like “principle of least privilege” – which sounds great, but what does it mean in practice? How do you actually use that? Another classic is “Separation of Duties” – which means privileged users should not have unfettered access, so you divide capabilities across several people. Again the concept makes sense, but there is no clear roadmap to take advantage of it. One of the main values of RBAC is that it lets you enforce a specific set of policies for a specific set of users. Only a user acting in the role of Department X can access Department X’s resources. In addition, RBAC can enforce a hierarchy of roles. A user with the Department X manager role can add or disable users in the Department X worker bee roles. Our recommendation is clear: start simple. It is very effective to start with a small set of rules, perhaps 20-30. Do not feel obliged to create more roles initially — instead ensure that your initial small set of roles is integrated end-to-end, to users on the front end, and to permissions and resources on the back end. Roles open up ways to enforce important access control policies – including separation of duties. For example your security policy might state that users in a Finance role cannot also be in an IT role. Role-Based Access Control gives you a way to enforce that policy. Implementation Building on our simple definition, a permission checker could perform this role check: Subject currentUser = SecurityService.getSubject(); if (currentUser.hasRole(“CallCenter”)) { //show the Call Center screen } else { //access denied } In this simple example an application does not make an access control decision per user, but instead based on the user’s role. Most application servers contain some form of RBAC support, and it is often better to rely on server configuration than to hard-code permission checks. For example: <web-app> <security-role> <role-name>CallCenter</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>Call Center pages</web-resource-name> <url-pattern>/CCFunctions/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>CallCenter</role-name> </auth-constraint> </security-constraint>   Notice that both code and configuration examples map the role the permission set to the resource (screen and URL). This accomplishes a key RBAC concept: the programmer does not need specific knowledge about any user – they are abstracted from user accounts, and only deal with permissions and roles. Making this work in the real world raises the question of integration: Where do you deploy the roles that govern access? Do you do it in code, configuration, or a purpose-built tool? Integration RBAC systems raise both first-mile and last-mile integration considerations. For the first mile what you do is straightforward: role assignment is tied to user accounts. Each user has one or more assigned roles. Most enterprises use Active Directory, LDAP, and other systems to store and manage users, so role mapping conveniently takes place in collaboration with

I have to admit the USAirways porno tweet had me cracking up. Business Insider has good coverage (even including the NSFW link, if you are a glutton for well, whatever). It was funny not because of the picture, but as an illustration of how a huge corporation could have its brand and image impacted by the mistake of one person. Also because it didn’t happen to me. I assure you the executive suite at the company did not think this was funny, at all.   But it highlights the need for much greater control of social media. With advertising there are multiple layers of approval before anything ever hits the airwaves – and we still have branding fiascos. Social media changes the rules. One person can control a very highly followed account, and that person’s device can be attacked and compromised – giving attackers free reign to behave badly and impact the brand. Or a malicious insider could do the same. Or just plain old human error. It happens all the time, but not like the USAir tweet. That went viral fast, and the damage was done even faster. It’s like Pandora’s Box. Once it’s open, you shouldn’t try to put a plane in it. (Sorry, had to…) I know you have to move fast with social media. But folks will be lampooning USAirways for years over this. I don’t think their real-time response to the customer outweighs the downside, or that a little check and balance would be a terrible thing – if only to make sure you have multiple eyes on the corporate social media accounts. Photo credit: “Cannot Unsee” originally uploaded by Lynn Williams Share:

Yeah, we hit on the Heartbleed vulnerability in this week’s FireStarter, but I wanted to call attention to how Akamai handled the vulnerability. They first came out with an announcement that their networks (and their customers) were safe because their systems were already patched. Big network service providers tend to get an early heads-up when stuff like this happens, so they can get a head start on patching. They were also very candid about whether they have proof of compromise: Do you have any evidence of a data breach? No. And unfortunately, this isn’t “No, we have evidence that there was no breach of data;” rather, “we have no evidence at all.” We doubt many people do – and this leaves data holders in the uncomfortable position of not knowing what, if any, data breaches might have happened. Sites using Akamai were not measurably safer – or less safe – than sites not using Akamai. So kudos are due Akamai for explaining the issue in understandable terms, discussing their home-grown way of issuing and dealing with certs, discussing the potential vulnerability window before they started patching, and owning up to the fact that they (like everyone else) have no idea what (if anything) was compromised. Then they assured customers they were protected. Unless they weren’t. Over the weekend a researcher pointed out a bug in Akamai’s patch. Ruh Roh. But again, to Akamai’s credit, they came clean. They posted an update explaining the specifics of the buggy patch and why they were still exposed. Then they made it clear that all the certs will be re-issued – just to be sure. As a result, we have begun the process of rotating all customer SSL keys/certificates. Some of these certificates will quickly rotate; some require extra validation with the certificate authorities and may take longer. It is okay to be wrong. As long as an organization works diligently to make it right, and they keep customers updated and in the loop. Preferably without requiring an NDA to figure out what’s going on… Share:

You have to love compliance mandates, especially when they are anywhere from 18 months to 3 years behind the threat. Recently the FFIEC (the body that regulates financial institutions) published some guidance for financials to defend against DDoS attacks. Hat tip to Techworld.   It’s not like the guidance is bad. Assessing risk, monitoring inbound traffic, and having a plan to move traffic to a scrubber is all good. And I guess some organizations still don’t know that they should even perform that simple level of diligence. But a statement in the FFIEC guidance sums up rear-view mirror compliance: “In the latter half of 2012, an increased number of DDoS attacks were launched against financial institutions by politically motivated groups,” the FFIEC statement says. “These DDoS attacks continued periodically and increased in sophistication and intensity. These attacks caused slow website response times, intermittently prevented customers from accessing institutions’ public websites, and adversely affected back-office operations.” Uh, right on time. 18 months later. It’s not that DDoS is going away, but to mandate such obvious stuff at this point is a beautiful illustration of solving yesterday’s problem tomorrow. Which I guess is what most compliance mandates are about. Sigh. Photo credit: “mtcook” originally uploaded by Jim Howard Share:

In this week’s Firestarter the team makes up for last week and picks three different stories, each with a time limit. It’s like one of those ESPN shows, but with less content and personality. The audio-only version is up too. Share:

Identity and Access Management (IAM) is a marathon rather than a sprint. Most enterprises begin their IAM journey by strengthening authentication, implementing single-sign on, and enabling automated provisioning. These are excellent starting points for an enterprise IAM foundation, but what happens next? Once users are provisioned, authenticated, and signed on to multiple systems, how are they authorized? Enterprises need to very quickly answer crucial questions: How is access managed for large groups of users? How will you map business roles to technology and applications? How is access reviewed for security and auditing? What level of access granularity is appropriate? Many enterprises have gotten over the first hurdle for IAM programs with sufficient initial capabilities in authentication, single sign-on, and provisioning. But focusing on access is only half the challenge; the key to establishing a durable IAM program for the long haul is tying it to an effective authorization strategy. Roles are not just a management concept to make IT management easier; they are also fundamental to defining how work in an enterprise gets done. Role based access control (RBAC) has been around for a while and has a proven track record, but key questions remain for enterprise practitioners. How can roles make management easier? Where is the IAM industry going? What pitfalls exist with current role practices? How should an organization get started setting up a role based system? This series will explore these questions in detail. Roles are special to IAM. They can answer certain critical access management problems, but they require careful consideration. Their value is easy to see, but there are essential to realize value. These include identifying authoritative sources, managing the business-to-technology mapping, integration with applications, and the art and science of access granularity. The paper will provide context, explore each of these questions in detail, and provide the critical bits enterprises need to choose between role-based access control products: The role lifecycle in a real world enterprise – how to use roles to make management easier: This post will focus on three areas: defining roles and how they work, enforcing access control policies with roles, and using roles in real-world systems. We will also cover identification of sources, integration, and access reviews. Advanced concepts – where is the industry going? This section will talk about role engineering – rolling up your sleeves to get work done. But we will also cover more advanced concepts such as using attributes with roles, dynamic ‘risk-based’ assess, scalability, and dealing with legacy systems. Role management: This is the section many of you will be most interested in: how to manage roles. We will examine access control reviews, scaling across the enterprise, metrics, logging, error handling, and handling key audit & compliance chores. Buyer’s guide: As with most of our series, not all vendors and services are equal, so we will offer a buyer’s guide. We will examine the criteria for the major use cases, help you plan and run the evaluation, and decide on a product. We will offer a set of steps to ensure success, and finally, a buyer’s checklist for features and proofs-of-concept. Our goal is to address the common questions from enterprises regarding role-based access controls, with a focus on techniques and technologies that address these concerns. The content for this paper will be developed and posted to the Securosis blog, and as always we welcome community feedback on the blog and via Twitter. Share: