Research

[Note: Rich, Adrian, and Mike are all traveling today, so we asked Jamie Arlen to provide at least a little perspective on an aspect of the DBIR he found interesting. So thanks Jamie for this. We will also throw Gunnar under the bus a little because he has been very active on our email list, with all sorts of thoughts on the DBIR, but he doesn’t want to share them publicly. Maybe external shaming will work, but more likely he’ll retain his midwestern sensibilities and be too damn nice.] As usual, the gang over at Verizon have put a lot of information and effort into the 2014 edition of their DBIR (registration required). This is both a good thing and a bad thing. The awesome part is that there are historically very few places where incident information is available – leaving all too many professionals in the position of doing risk mitigation planning, based on anecdotes, prayer, and imagination. The DBIR offers some much-needed information to fill in the blanks. This year you will note the DBIR is different. Wade, Jay, and the gang have gone back to the data to provide a new set of viewpoints. They have also done a great job of putting together great graphics. Visualization for the win! Except that all the graphics are secondary to the high quality data tables. Of course graphics are sexy and tables are boring. Unless you have to make sense of the data, that is. So I will focus on one table in particular to illustrate my point.   This is Figure 19 (page 15 printed, 17 of 62 in the PDF) – click it to see a larger version. You may need to stare at it for a while for it to even begin to make sense. I have been staring at it since Friday and I’m still seeing new things. Obvious things Accommodation and Point of Sale Intrusion: No real surprise here. The problem of “the waiter taking the carbons” in the 70’s seems to be maintaining its strength into the future. Despite the efforts of the PCI Council, we have a whole lot of compliance but not enough security. And honestly, isn’t it time for the accommodation industry to make that number go down? Healthcare Theft/Loss: Based on the news it is no great surprise that about half the problems in healthcare are related to the loss or theft of information. We have pretty stringent regulation in place (and for years now). Is this a case of too much compliance and not enough security? It is time to take stock of what is really important (protecting the information of recipients of health care services) and build systems and staff capabilities to meet patient expectations! Interesting things Industry = Public: Biggest issue is “Misc. Error”. I didn’t know what a Misc Error was either. It turns out that it is due to the reporting requirements most of the public sector is under – they need to (and do) report everything. Things that would go completely unremarked in most organizations are reported. Things like, “I sent this email to the wrong person,” “I lost my personal phone (which had access to company data),” etc. I vaguely remember something from stats class about this. Incident = Denial of Service: The two industries reporting the largest impact are ‘Management’ and ‘Professional’. If you look at the NAICS listings for those two industry categories, you will see they are largely ‘offices’. I would love a deeper dive into those incidents to see what’s going on exactly and what industries they really represent. The text of the report talks primarily about the impact of DoS on the financial industry, but doesn’t go into any detail on the effects on Management and Professional. You can read into the report to see that the issue may have been the takeover of content management systems by the QCF / Brobot DoS attacks. Incident = Cyber Espionage: Just sounds cool. And something we have all spent lots of time talking about. It seems to affect Mining, Manufacturing, Professional and Transportation in greater proportion than others. Again, I’d love a look at the actual incidents – they are probably about 10% Sneakers and 90% Tommy Boy. If you are working in those industries you have something interesting to talk to your HR department about. There shouldn’t be any big surprises in this data, but there are plenty of obvious and interesting things. I am still staring at the table and waiting for the magic pattern moment to jump out at me. Though if I stare at the chart long enough, I think it’s a sailboat. Share:

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