Research

I recently had the pleasure to present at a local CIO conference. There were about 50 CIOs in the room, ranging from .edu folks, to start-ups, to the CIOs of major enterprises including a large international bank and a similarly large insurance company. While the official topic for the event was “the cloud”, there was a second underlying theme – that CIOs needed to learn how to talk to the business folks on their terms and also how to make sure that IT wasn’t being a roadblock but rather an enabler of the business. There was a lot of discussion and concern about the cloud in general – driven by business’ ability to take control of infrastructure away from IT – so while everybody agreed that communicating with the business should always have been a concern, the cloud has brought this issue to the fore. This all sounds awfully familiar, doesn’t it? For a while now I’ve been advocating that we as an industry need to be doing a better job communicating with the business and I stand behind that argument today. But I hadn’t realized how fortunate I was to work with several CIOs who had already figured it out. It’s now pretty clear to me that many CIOs are still struggling with this, and that it is not necessarily a bad thing. It means, however, that while the CIO is still an ally as you work to communicate better with the business, it is now important to keep in mind that the CIO might be more of a direct partner rather than a mentor. Either way, having someone to work with on improving your messaging is important – it’s like having an editor (Hi Chris!) when writing. That second set of eyes is really important for ensuring the message is clear and concise. Share:

For Adam after harassing me on irc: Calling ‘accounts’ ‘identities’ is broken. Discuss. Share:

There were some great comments on my last post, which bring to light a serious problem with the way authorization is done today and how roles don’t help as much as we’d like. First we hear from LonerVamp: And even if you get the authentication part down, very few apps that I’ve seen then tie back into whatever is in place for role management. This is an important point that often gets glossed over by IDM vendors. It turns out that while many applications have support for third party authentication mechanisms, very few have support for third party authorization methods. Which means that even if you can centralize your identities for the purposes of account creation/deletion, you still have to manage use inside each application. Furthermore, many of the applications that claim to support third party authorization really turn out to only support third party groups in LDAP or RADIUS, but you still have to map those groups onto roles within the applications. Andrew Yeomans followed up with his own comment that shows that he’s been a dedicated Securosis reader for a while now: I’m starting to think that a data-centric approach may be a way forward. Today, authorizations are generally enforced by applications. Now firstly this leads to high complexity (as you describe) as there is no unifying set of “policy decision points” and “policy enforcement points”. Secondly, it allows for authorization restrictions to be bypassed by other applications that have access to the same data. Andrew really hits the nail on the head here. We need to continue our shift towards Data-centric Security. The Data Security Lifecycle explicitly assumes that you can properly assign and control rights to who has what data, which is why IDM is so important. I’ve said it before and I’ll say it again: If you don’t know who is accessing the data, how can you possibly tell if it is being abused or misused? Finally Omie asked: I’ve been hearing too much about identity management recently and how the move to roles will solve our compliance problems. And I’ve been wondering and asking how we plan to keep the roles maintained over time. Of course I’ve also been under the impression that every other organization has figured that out except ours, but your post is making me rethink that assumption. If there are some best practices/examples of how to approach role maintenance, I would love to learn about them. Roles can definitely help you out with compliance, but you are correct – role maintenance is definitely a challenge. There is often an implicit assumption that roles, like the rest of the application configuration, are static, when in reality roles tend be dynamic so you absolutely need a process for adapting roles as necessary. Often the complexity of the application causes admins to add roles rather then edit the existing ones because it is easier in the short term. But in the long run this causes extra complexity. I’ll go into more details on this issue and how to deal with it in a later post, so stay tuned. In the meantime, NIST recently published some documents from their recent Privilege (Access) Management Workshop. In particular, you should check out A Survey of Access Control Models, to give you an idea of some ways that role based access control is problematic. Share:

IDM fascinates me, if only because it is such an important base for a good security program. Despite this, many organizations (even ones with cutting edge technology) haven’t really focused on solving the issues around managing users’ identity. This is, no doubt, in part due to the fact that IDM is hard in the real world. Businesses can have hundreds if not thousands of applications (GM purportedly had over 15,000 apps at one point) and each application itself can have hundreds or thousands of roles within it. Combine this with multiple methods of authentication and authorization, and you have a major problem on your hands which makes digging into the morass challenging to say the least. I also suspect IDM gets ignored because it does not warrant playing with fun toys, so as a result, doesn’t get appropriate attention from the technophiles. Don’t get me wrong – there are some great technologies out there to help solve the problem, but no matter what tools you have at your disposal, IDM is fundamentally not a technology problem but a process issue. I cannot possibly emphasize this enough. In the industry we love to say that security is about People, Process, and Technology. Well, IDM is pretty much all about Process, with People and Technology supporting it. Process is an area that many security folks have trouble with, perhaps due to lack of experience. This is why I generally recommend that security be part of designing the IDM processes, policies, and procedures – but that the actual day to day stuff be handled by the IT operations teams who have the experience and discipline to make it work properly. DS had a great comment on my last post, which is well worth reading in its entirety, but today there is one part I’d like to highlight because it nicely shows the general process that should be followed regardless of organization size: While certainly not exhaustive, the above simple facts can help build a closed loop process. When someone changes roles, IT gets notified how. A request is placed by a manager or employee to gain access to a system. If employee request, manager must(?) approve. If approved as “in job scope” by manager, system owner approves. IT (or system owner in decentralized case) provisions necessary access. Requester is notified. Five steps, not terribly complicated and easy to do, and essentially what happens when someone gets hired. For termination, all you really need are steps 1, 2, and 5 – but in reverse. This process can even work in large decentralized organizations, provided you can figure out (a) the notification/request process for access changes and (b) a work flow process for driving through the above cycle. (a) is where the Info Sec team has to get outside the IT department and talk to the business. This is huge. I’ve talked in the past about the need for IT to understand the business and IDM is a great example of why. This isn’t directly about business goals or profit/loss margins, but rather about understanding how the business operates on a day to day basis. Don’t assume that IT knows what applications are being used – in many organizations IT only provides the servers and sometimes only the servers for the basic infrastructure. So sit down with the various business units and find out what applications/services are being used and what process they are using today to provision users, who is handling that process, and what changes if any they’d like to see to the process. This is an opportunity to figure out which applications/services need to be part of your IDM initiative (this could be compliance, audit, corporate mandate etc.) and which ones currently aren’t relevant. It has the added benefit of discovering where data is flowing, which is key to not only compliance mandates under HIPAA, SOX, and the European Data Directive (to name a few), but also incredibly handy when electronic discovery is necessary. One all this data has been gathered, you can evaluate the various technologies available and see if they can help. This could be anything from a web app to manage change requests, to workflow (see below), to a full-scale automated access provisioning and de-provisioning system, driven by the approval process. Once you’ve solved (a), (b) is comparatively straightforward and another place where technology can make life easier. The best part is that your organization likely has something like this deployed for other reasons, so the additional costs should be relatively low. Once your company/department/university/etc. grows to a decent size and/or starts to decentralize, manually following the process will become more and more cumbersome, especially as the number of supported applications goes up. A high rate of job role changes within the organization has a similar effect. So some sort of software that automatically notifies employees when they have tasks will greatly streamline the process and help people get the access they need much more quickly. Workflow software is also a great source of performance metrics and can help provide the necessary logs when dealing with audit or compliance issues. As I mentioned above, the business reality for many organizations is far from pristine or clear, so in my next post I’ll explore more those issues in more depth. For now, suffice it to say that until you address those issues, the above process will work best with a small company with fewer apps/auth methods. If you are involved in a larger more complex organization, all is not lost. In that case, I highly recommend that you not try to fix things all at once, but start with one a group or sub-group within the organization and roll out there first. Once you’ve worked out the kinks, you can roll in more and more groups over time. Share:

So a buddy of mine back from when I was on the customer side contacted me recently. He’s at a new company doing some very interesting work on detecting certain classes of online fraud and amounts of malware on websites. So far he’s gathered some fascinating data on just how bad the problem is, and I’m trying to convince him that he should start publishing some of his aggregate data in a quarterly or semi-annual report. He is very interested but would love some community input on what the report should look like, which brings me to you. Some of what should be in such a report is obvious – such as rate of detected fraud overall and by various industry verticals. The rest isn’t so clear and that’s where you all come in. Put on whatever hat you like – CISO, CFO, security researcher, risk officer, consumer, or whatever else – and what would you like to see in such a report? Are there things you hate about other reports? Or are there things you wish they covered which they never do? Throw out your requests, rants, comments, ideas, and questions in the comments and I’ll collect them all together and summarize them in a future post. If this really takes off, I’ll move it over to the forums. Share:

IDM fascinates me, if only because it is such an important base for a good security program. Despite this, many organizations (even ones with cutting edge technology) haven’t really focused on solving the issues around managing users’ identity. This is, no doubt, in part due to the fact that IDM is hard in the real world. Businesses can have hundreds if not thousands of applications (GM purportedly had over 15,000 apps at one point) and each application itself can have hundreds or thousands of roles within it. Combine this with multiple methods of authentication and authorization, and you have a major problem on your hands which makes digging into the morass challenging to say the least. I also suspect IDM gets ignored because it does not warrant playing with fun toys, so as a result, doesn’t get appropriate attention from the technophiles. Don’t get me wrong – there are some great technologies out there to help solve the problem, but no matter what tools you have at your disposal, IDM is fundamentally not a technology problem but a process issue. I cannot possibly emphasize this enough. In the industry we love to say that security is about People, Process, and Technology. Well, IDM is pretty much all about Process, with People and Technology supporting it. Process is an area that many security folks have trouble with, perhaps due to lack of experience. This is why I generally recommend that security be part of designing the IDM processes, policies, and procedures – but that the actual day to day stuff be handled by the IT operations teams who have the experience and discipline to make it work properly. DS had a great comment on my last post, which is well worth reading in its entirety, but today there is one part I’d like to highlight because it nicely shows the general process that should be followed regardless of organization size: While certainly not exhaustive, the above simple facts can help build a closed loop process. When someone changes roles, IT gets notified how. A request is placed by a manager or employee to gain access to a system. If employee request, manager must(?) approve. If approved as “in job scope” by manager, system owner approves. IT (or system owner in decentralized case) provisions necessary access. Requester is notified. Five steps, not terribly complicated and easy to do, and essentially what happens when someone gets hired. For termination, all you really need are steps 1, 2, and 5 – but in reverse. This process can even work in large decentralized organizations, provided you can figure out (a) the notification/request process for access changes and (b) a work flow process for driving through the above cycle. (a) is where the Info Sec team has to get outside the IT department and talk to the business. This is huge. I’ve talked in the past about the need for IT to understand the business and IDM is a great example of why. This isn’t directly about business goals or profit/loss margins, but rather about understanding how the business operates on a day to day basis. Don’t assume that IT knows what applications are being used – in many organizations IT only provides the servers and sometimes only the servers for the basic infrastructure. So sit down with the various business units and find out what applications/services are being used and what process they are using today to provision users, who is handling that process, and what changes if any they’d like to see to the process. This is an opportunity to figure out which applications/services need to be part of your IDM initiative (this could be compliance, audit, corporate mandate etc.) and which ones currently aren’t relevant. It has the added benefit of discovering where data is flowing, which is key to not only compliance mandates under HIPAA, SOX, and the European Data Directive (to name a few), but also incredibly handy when electronic discovery is necessary. One all this data has been gathered, you can evaluate the various technologies available and see if they can help. This could be anything from a web app to manage change requests, to workflow (see below), to a full-scale automated access provisioning and de-provisioning system, driven by the approval process. Once you’ve solved (a), (b) is comparatively straightforward and another place where technology can make life easier. The best part is that your organization likely has something like this deployed for other reasons, so the additional costs should be relatively low. Once your company/department/university/etc. grows to a decent size and/or starts to decentralize, manually following the process will become more and more cumbersome, especially as the number of supported applications goes up. A high rate of job role changes within the organization has a similar effect. So some sort of software that automatically notifies employees when they have tasks will greatly streamline the process and help people get the access they need much more quickly. Workflow software is also a great source of performance metrics and can help provide the necessary logs when dealing with audit or compliance issues. As I mentioned above, the business reality for many organizations is far from pristine or clear, so in my next post I’ll explore more those issues in more depth. For now, suffice it to say that until you address those issues, the above process will work best with a small company with fewer apps/auth methods. If you are involved in a larger more complex organization, all is not lost. In that case, I highly recommend that you not try to fix things all at once, but start with one a group or sub-group within the organization and roll out there first. Once you’ve worked out the kinks, you can roll in more and more groups over time. Share:

Thanks to the opportunity to be the Securosis Contributing Analyst, I’m back to blogging here on Securosis even though Rich isn’t off getting bits of his body operated on. I’ve decided to revive an old Identity and Access Management (IDM) research project of mine to kick off my work here at Securosis. Once you get past compliance, one of the biggest recent concerns for CIOs and CISOs has been IDM. This isn’t really that surprising when you consider that IDM is a key aspect of any successful security or compliance program. After all, how can you say with confidence whether or not you’ve had a breach, if you don’t know who has access to what data, or don’t have a process for granting and revoking that access? In principle this should be pretty straightforward, right? Keep a database of users with what applications they have access to and whenever they change roles, re-evaluate that access and make the appropriate changes for their new (or now non-existent) role. Unfortunately, simple doesn’t mean easy. Many large enterprises have hundreds if not thousands of applications that they need to track and in many (most?) cases these applications are not centrally controlled, even if you just count the ‘critical’ ones. This disparate control will continue to get worse as corporations continue to embrace “The Cloud.” Realistically, companies are in a situation where IDM is not only a difficult problem to solve, but also a fairly complex one as well. IDM is a large enough problem for enough companies that an entire market has sprung up over the last ten years to help organizations deal with it. In the beginning, IDM solutions were all about managing Moves, Adds and Changes (MAC) for accounts. There are several products to help with this issue, but by all reports many of them just make the situation even more complicated then it already was. Since these initial products hit the market, vendors who sell directory services, single sign on/federated identity, and entitlement services (to name just a few) have jumped onto the IDM bandwagon with claims to solve your woes. This has just caused even more confusion and made customers’ jobs even more difficult, causing many to ask: “Just what is IDM anyway?” As a result, I’m planning on breaking up my project into two major pieces. One part of the larger project will be to evaluate the IDM space in order to make recommendations on what security practitioners should look for in such products, to the extent that they choose to go that route. From my investigations to date, many companies (especially SMBs) don’t have a technology problem to solve, but rather one of process. As a result, the other part of this project will be to create a series of recommendations for companies to implement to make their IDM efforts more successful. In the meantime, feel free to treat the comments here as an open thread for your thoughts on IDM and how to do it better. Share:

I’m very excited to announce a new project I’ve been working on for some time with Debix. Yesterday, they released a new study today on child identity theft. I was astounded to discover that on average one out of twenty kids has their identity compromised in some way before they reach adulthood. That’s essentially one kid in every classroom. And those kids had on average almost $12,800 of debt fraudulenly associated with them. Talk about a nightmare to clean up! Anyway, there are more details over on their blog which just happens to be written by your truly. I’d love to hear your comments either here or over there. Looking forward to hearing from you all. Share:

‘Last week Jeremiah “Purple Belt” Grossman posted the following question: “You’re hired on at a new company placed in charge of securing their online business (websites). You know next to nothing about the technical details of the infrastructure other than they have no existing web/software security program and a significant portion of the organizations revenues are generated through their websites. What is the very first thing do on day 1?” Day one is going to be a long day, that’s for certain. Like several commentators on the original post, I’d start with talking with the people who own the application both at a business and technology level. Basically, this is a prime opportunity to not only understand what the goals of the business are but also get everyone’s perceptions of their needs, and equally important their perceptions of the cost of their systems being unavailable. The next few weeks would be used to determine where reality diverged from perception. But day one is when I get to make my first impression and if I can successfully convince people that I really am on their side, it will make the rest of my tenure much easier. I’ve found that I can do so by demonstrating that my prime concern is enabling the business to accomplish its goals with a minimum of hassle from me. One of the key ways of doing this is spending my time listening, and limiting my talking to asking questions that lead my interviewee to the necessary logical conclusions rather than being a dictator…. …not that I don’t reserve the right to hit things with a hammer later to protect the business, but day 1 sets the tone for the future, and that’s far more important than putting in X fix or blocking Y vulnerability. Share:

This past Monday, I had the privilege of speaking (along with several peers) to the Commission on Cyber Security for the 44th Presidency about issues on identity theft, breach disclosure and personal privacy in general. It was an honor to present with such a great group of folks. There were some great discussions/debates and I look forward to the opportunity to present again as the Commission works to streamline its recommendations. My written testimony is below. A special thanks to the folks at Emergent Chaos and to Rich for their comments, which made this a much better piece. Any errors or logical fallacies are, of course, my own. Thank you for the opportunity to present to you today on the issue of identity theft. Since the advent of CA1386, we have seen 41 other states pass similar legislation mandating to some degree or another that companies must notify customers or the government when they believe they have suffered a loss of personal data. Unfortunately, each and every state has created slightly different criteria for what constitutes personal information, what a loss is, when notification needs be sent and, to whom it must be sent. As a result there are huge disparities among companies on what they do when they discover they’ve suffered a breach. As much as I prefer to not have even more legislation, I believe that the only solution to this dilemma is to have a uniform federal law that covers the loss of personal information. Rather than preempt state laws, this law should set baseline requirements of: a) Notification to all customers in a timely fashion. b) Notification to a central organization. c) The gathered data about companies suffering breaches must be a matter of public record and un-anonymized. d) Include notification of any personal information that is not a matter of public record. e) Not have a “get out of jail free” card. This last point is key. One of the great weaknesses of CA1386 (and several other states’ legislation as well) is that companies don’t have to notify in case the information was encrypted. Unfortunately, the mere use of encryption does not mean the data was actually obfuscated at the time it was stolen, for instance in cases where a laptop is stolen while the user is logged in. Don’t get me wrong- encryption is important. A well-written law will provide a safe harbor for a company that has lost data. If they can establish that it was encrypted following best practices and that key material was not also lost, the company should be protected from litigation as a result of the breach disclosure. Similarly, many state laws allow companies to choose to not disclose if they believe the data has not been misused. Given that the companies lost the data to begin with, should we really trust their assessment of the risk of misuse, especially when many executives believe it is not in their best interest to not disclose? It is worth noting that following a breach, stock prices do not suffer in the long run and customer loss is approximately 2%. On the other side of the coin from breach disclosure, we have the problem that people don’t know what personal information companies have about them. Part of the outrage behind the ChoicePoint debacle of several years ago was that people didn’t know that this data was even being collected about them to begin with, and had no real way to find out what ChoicePoint might or might not have collected. In Europe as well as in Australia and parts of Asia such as Japan, companies have to both tell customers what data they have and allow them the opportunity to correct any errors. Additionally, there are strict restrictions on what collected personal information may be used for. I believe that it is time that similar protections be available to Americans as well. Share: