Security Management

IDM: Identity?

By David Mortman

For Adam after harassing me on irc:

Calling 'accounts' 'identities' is broken. Discuss.

–David Mortman

IDM: Roles, Authorization and Data Centric Security

By David Mortman

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.

–David Mortman

IDM: Reality Sets In

By David Mortman

As I have mentioned in previous posts, although in principle IDM isn't that complicated, real world practicalities make it fairly challenging. To quote myself:

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 was chatting with Rich the other day, and he reminded me that there were several issues that I hadn't brought up yet. By way of example, he sent me the following list:

• Most organizations of even moderate size have already lost control of identities.
• The challenge is to regain control, while instituting the processes you describe.
• The average large enterprise has 1 custom application for every 100 employees
• A surprising number of enterprise applications have more roles than users (especially ERP systems, as admins "cheat" and create new roles for different tasks of a user to deal with application restrictions).
• Due to compliance, for in-scope applications you often need a full user/role analysis... 2 years ago.
• Because of these factors, the IDM market is massive and has been one of the fastest growing in the security industry for years (I think it's tapering off now, but it really isn't my area so I could be wrong).
• The IDM market itself is complex, with multiyear implementations, and customer satisfaction is often low until the pain of implementation is complete.
• There are still a lot of issues integrating any kind of IDM into many custom applications.

As if that weren't enough to make you want to go do something easier, the problem gets even worse when you realize that while compliance forces organizations to evaluate annually whether people should still have the roles they do, there is little to no compliance required around regularly adjusting the roles themselves within applications. As a result, the roles themselves only get reevaluated at major upgrade times (and often not even then) which means maybe every 18-24 months. The ugliness comes in because the business tends to change its needs much more quickly -- this is why most major ERM, ERP, CRM, etc. rollouts fail: IT simply can't keep up with the business. So it's not enough to just solve the process problem, but in the long run, you will also need to deal with some fundamental business and IT cultural issues of how applications are handled. Essentially, IT will have to become a lot more agile in its ability to respond to changing business needs. While this is hardly limited to the IDM space, IDM nicely highlights the issue. After all, if the roles are meaningless, knowing who has what role may be helpful from an incident response or investigation standpoint, but cannot really help understand your risk or compliance profile.

–David Mortman

IDM: It’s A Process

By David Mortman

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.

1. When someone changes roles, IT gets notified how.
2. A request is placed by a manager or employee to gain access to a system.
3. If employee request, manager must(?) approve.
4. If approved as "in job scope" by manager, system owner approves.
5. 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.

–David Mortman

The Laws of Emergency Medicine—Security Style

By Rich

Thanks to some bad timing on the part of our new daughter, I managed to miss the window to refresh my EMT certification and earned the privilege of spending two weekends in a refresher class. The class isn't bad, but I've been riding this horse for nearly 20 years (and have the attention span of a garden gnome), so it's more than a little boring.

On the upside, it's bringing back all sorts of fun memories from my days as a field paramedic. One of my favorite humorous/true anecdotes is the "Rules of Emergency Medicine". I've decided to translate them into security speak:

1. All patients die... eventually. Security equivalent: You will be hacked... eventually. It sucks when you kill^H^H^H^Hfail to save a patient, but all you're ever doing is delaying the inevitable. In the security world, you'll get breached someday. Maybe not at this job, but it's going to happen. Get over it, and make sure you also focus on what you need to do after you're breached. React faster and better.
2. All bleeding stops... eventually. Security equivalent: If you don't fix the problem, it will fix itself. You can play all the games you want, and sponsor all the pet projects you want, but if you don't focus on the real threats they'll take care of your problems for you. Take vulnerability scanning -- if it isn't in your budget, don't worry about it. I'm sure someone on the Internet will take care of it for you. This one also applies to management -- if they want to ignore data breaches, web app security, or whatever... eventually it will take care of itself.
3. If you drop the baby, pick it up. Security equivalent: If you screw up, move on. None of us are perfect and we all screw up on a regular basis. When something bad happens, rather than freaking out, it's best to move on to the next task. Fix the mistake, and carry on. The key of this parable is to fix the problem rather than all the other hand wringing/blame-pushing we tend to do when we make mistakes.

I think I'm inspired to write a new presentation -- "The Firefighter's Guide to Data Security".

–Rich

The Business Justification For Data Security

By Rich

You've probably noticed that we've been a little quieter than usual here on the blog. After blasting out our series on Building a Web Application Security Program, we haven't been putting up much original content.

That's because we've been working on one of our tougher projects over the past 2 weeks. Adrian and I have both been involved with data security (information-centric) security since long before we met. I was the first analyst to cover it over at Gartner, and Adrian spent many years as VP of Development and CTO in data security startups. A while back we started talking about models for justifying data security investments. Many of our clients struggle with the business case for data security, even though they know the intrinsic value. All too often they are asked to use ROI or other inappropriate models.

A few months ago one of our vendor clients asked if we were planning on any research in this area. We initially thought they wanted yet-another ROI model, but once we explained our positions they asked to sign up and license the content. Thus, in the very near future, we will be releasing a report (also distributed by SANS) on The Business Justification for Data Security. (For the record, I like the term information-centric better, but we have to acknowledge the reality that "data security" is more commonly used).

Normally we prefer to develop our content live on the blog, as with the application security series, but this was complex enough that we felt we needed to form a first draft of the complete model, then release it for public review. Starting today, we're going to release the core content of the report for public review as a series of posts. Rather than making you read the exhaustive report, we're reformatting and condensing the content (the report itself will be available for free, as always, in the near future). Even after we release the PDF we're open to input and intend to continuously revise the content over time.

The Business Justification Model

Today I'm just going to outline the core concepts and structure of the model. Our principle position is that you can't fully quantify the value of information; it changes too often, and doesn't always correlate to a measurable monetary amount. Sure, it's theoretically possible, but practically speaking we assume the first person to fully and accurately quantify the value of information will win the nobel prize.

Our model is built on the foundation that you quantify what you can, qualify the rest, and use a structured approach to combine those results into an overall business justification. We purposely designed this as a business justification model, not a risk/loss model. Yes, we talk about risk, valuation, and loss, but only in the context of justifying security investments. That's very different from a full risk assessment/management model.

Our model follows four steps:

1. Data Valuation: In this step you quantify and qualify the value of the data, accounting for changing business context (when you can). It's also where you rank the importance of data, so you know if you are investing in protecting the right things in the right order.
2. Risk Estimation: We provide a model to combine qualitative and quantitative risk estimates. Again, since this is a business justification model, we show you how to do this in a pragmatic way designed to meet this goal, rather than bogging you down in near-impossible endless assessment cycles. We provide a starting list of data-security specific risk categories to focus on.
3. Potential Loss Assessment: While it may seem counter-intuitive, we break potential losses from our risk estimate since a single kind of loss may map to multiple risk categories. Again, you'll see we combine the quantitative and qualitative. As with the risk categories, we also provide you with a starting list.
4. Positive Benefits Evaluation: Many data security investments also contain positive benefits beyond just reducing risk/losses. Reduced TCO and lower audit costs are just two examples.

After walking through these steps we show how to match the potential security investment to these assessments and evaluate the potential benefits, which is the core of the business justification. A summarized result might look like:

- Investing in DLP content discovery (data at rest scanning) will reduce our PCI related audit costs by 15% by providing detailed, current reports of the location of all PCI data. This translates to $xx per annual audit. - Last year we lost 43 laptops, 27 of which contained sensitive information. Laptop full drive encryption for all mobile workers effectively eliminates this risk. Since Y tool also integrates with our systems management console and tells us exactly which systems are encrypted, this reduces our risk of an unencrypted laptop slipping through the gaps by 90%. - Our SOX auditor requires us to implement full monitoring of database administrators of financial applications within 2 fiscal quarters. We estimate this will cost us $X using native auditing, but the administrators will be able to modify the logs, and we will need Y man-hours per audit cycle to analyze logs and create the reports. Database Activity Monitoring costs %Y, which is more than native auditing, but by correlating the logs and providing the compliance reports it reduces the risk of a DBA modifying a log by Z%, and reduces our audit costs by 10%, which translates to a net potential gain of $ZZ. - Installation of DLP reduces the chance of protected data being placed on a USB drive by 60%, the chances of it being emailed outside the organization by 80%, and the chance an employee will upload it to their personal webmail account by 70%.

We'll be detailing more of the sections in the coming days, and releasing the full report early next month. But please let us know what you think of the overall structure. Also, if you want to take a look at a draft (and we know you) drop us a line...

We're really excited to get this out there. My favorite parts are where we debunk ROI and ALE.

–Rich

The “Good Enough/Woe Is Me” Dissociation Postulate

By Rich

I don't get it. I mean I really don't get it. I can't possibly imagine why it isn't so obvious to everyone else!! Don't you see what's happening!!! Soylent Green is QSAs!!!

One of the more frustrating aspects of our profession is the apparent lack of security prioritization by the rest of the world. We feel like we see things they don't, and in that context many of their decisions make absolutely no sense. Are we just that much smarter than everyone else? Are they blindfully ignorant? Alan sums up our problem in his post on security gimmicks:

Agree or disagree with the gimmicks. You have to ask yourself why. With all that we read and see about data breaches, with all of these compliance regulations and rules around, why can't people take security seriously enough? Here is one man's opinion. Security is a bad news generator of an industry. We focus on what happens when things go wrong. We focus on adding to the process. We don't focus on the positive and the profitable. There is enough bad news in the world for people to focus on right now. They don't want the bad news that security makes them confront. If we can figure out how to make security a way of bringing a message of good news, we wouldn't need to resort to gimmicks.

My position is a little more zen.

Back in physical security/paramedic/firefighter/mountain rescue days I learned we all go through a process of dissociation with mainstream society. When all you see is nasty sh*t and dying people all day, every day, it's hard to give a rat's ass about someone getting the cold shoulder at the water cooler. The military, police, nurses, and many other professions suffer the same problem. In that world, there are two ways to handle it- shut up and deal, or isolate yourself into your chosen community. It's no accident that so many cops are married to nurses.

It's pretty much the same deal for IT security, except we don't have to wash blood off our shoes quite as often.

We see the fragility and danger of our online economy and society. Stolen elections, rampant fraud, and pwned grandmothers. No website is safe, all PCs have trojans, and those damn Macs will all be compromised next week.

We need to collectively chill out. Before we blow an aneurysm.

As Marcus Ranum said (totally pissing me off because I didn't say it first):

Will the future be more secure? It'll be just as insecure as it possibly can, while still continuing to function. Just like it is today.

We need to do our best to communicate risks to the business and cost effectively keep those risks within tolerance. Then we clean up the mess if the business, after being well informed, decides to accept that risk.

If we don't take risks, we can't possibly grow. No matter what someone tells us, we sometimes need to touch the hot stove and learn for ourselves. It's human nature; don't expect it to change. Security is only good news when it's no news.

Don't worry. When things get bad enough, we'll get the call. If you've kept your documentation and communication up, you won't get shafted with the proverbial short end.

Don't end up like I did in college- working as a full time medic on top of being a student wasn't exactly conducive to my dating life. That uniform didn't work nearly as well as I expected. (However, a black belt a few years later was very... effective).

–Rich

Policies vs. Plans vs. Procedures vs. Standards

By Rich

I was catching up with Rob Newby's blog and this post on dealing with security policies vs. standards/processes caught my eye. Although policies form the foundation for our security programs (at least they should), I find that more often than not they are completely misused by many of my clients. While I've noticed definite improvement over the past few years, I still often walk into organizations and see big 3 inch binders full of their security policies.

Rob does a great job of breaking these out, but I'd like to take it a step further. I'm going to dig into some nitty-gritty details, but feel free to skip to the end where I tell you why none of this parsing of language matters much. Here's how I like to divide up the world of security gove ance documentation:

1. Policies are high-level strategic governance with executive sponsorship. Policies should be short and to the point, since those who sign off on them don't need to know the technical details. An example might be, "we shall monitor all database activity based on the sensitivity of the data and legal or contractual requirements". Keep in mind, that since policies should be signed off by senior management you want to keep them generic enough that you don't have to go back to the CEO/CIO/CFO/COO every time you want to change a firewall configuration or AV product.
2. The next layer down are the high-level tactical documentations- plans and standards. The security plan is how you intend on achieving the policy, but it's still not at the level of specific steps. Keeping with our policy above, the plan would specify the contractual requirements, basic data classification, which activity will be monitored, and so on. While plans define how security will do things, standards define how everyone else has to do things.
3. Below that are your specific implementation documentations- processes, guidelines, and procedures. Here's where you get into the bitty-gritty of actual implementation and step by step guides. A process is a repeatable series of steps to achieve an objective, while procedures are the specific things you do at each of those steps. Keeping with out example above, the process would define how monitoring occurs (e.g. third party DAM tool), and the procedure is which bits to flip within the tool.

Yeah, I think that's a whole lot of paper and a huge time sink myself. Here's a slightly more pragmatic, and somewhat repetitive, way of looking at things:

1. Policies are still high level strategic governance with executive sponsorship; that never changes. Short and sweet since it makes it easier to get them approved, and you want o have to change them as little as possible.
2. I don't really care what you call below that, but you should have a security plan for implementing your policies. Plans are managed at the CISO or security director level (whoever is in charge) and change more frequently. You don't want to have to go to the CEO to change your plans. At this layer you also have your standards- which, if you think about it, is the next layer of gove ance. CEOs sign off on policies, and CISOs sign off on standards.
3. Below that is where you detail how the heck you'll accomplish all this gove ance. You document processes, list our procedures, and issue guidelines and configuration standards. This stuff will change all the time, and shouldn't necessarily need the CISO to sign off on it unless it breaks with the layer above.

The simpler the better, but if you don't write this stuff down in an organized way you'll eventually pay the price. By breaking it down into these three main layers, you can more easily change both the minutiae and the big picture as you adapt to changing conditions.

–Rich

Outsourced Email Security

By Adrian Lane

In the last post on Email Security, I commented on how easy it was to add outsourced email security services onto your existing email security deployment. That adding on an extra layer of anti-spam filtering on top of what you have not only provides an increase in the effectiveness of filtering, but also reduced the processing load on your existing hardware. But email security service vendors have been adding outbound email, data and web security offerings to their portfolio on top of their existing offerings, and these services solve different problems and offer different value propositions. 

Most companies I speak with state that 95~97% of the email that hits their servers are spam. A large percentage contain viruses, spyware and inappropriate content. The switch is cost effective and 'painless' in terms of administration and maintenance, and the large service providers tend to have very current and effective solutions. But it is worth noting that the problem you are solving is not protecting sensitive corporate information, rather keeping garbage out of your system. If you don't see spam and your computers have not been infected, you have been successful. 

From the customer's perspective, outbound email security offers many of the same advantages as inbound. As most companies have a very positive experience with inbound service, adoption of an outbound email security service is a natural extension of those advantages you enjoy today. It takes very little work to route your outbound email to a third party provider. These providers offer a canned set of security policies out of the box so you can be up and running in minutes, in conjunction with well designed web interfaces to customize and tune email (or even web security) policies. But the problem being set being addressed is very different; intellectual property leakage, use of private customer information, inappropriate content, violation of corporate policies and even bot-net detection. These problems are more complex and require policy and system verification. 

Just because you outsourced the operation does not mean you removed the responsibility of audit and security verification of the system itself.

Specifically what do I mean by that? If all of your corporate correspondence is being routed through a third party provider, you need to make sure that they are secure, and their policies are in line with yours. Remember, the information you are sending out is all of your corporate email, your policies for enforcement, and possibly all of the web browsing history. The service providers offer ad-on email retention services for 'compliance', but as some of the data is stored for their own backup and recovery processes, your data will be stored for some period of time. How is privacy maintained? Who has access to the data? Is there verification of integrity? When and how is the data disposed?

What the vendor will be selling you is the filtering service, the administrative interface, and the storage. What you need to ask for is their security policy, their data retention & data destruction policies, and audit reports for changes in permissions, data access and alterations to your data. The vendor will provide you a report on what was filtered and blocked according to policy; in addition you need reports on the operational controls around the system. If these services are being marketed to you as 'must-have' for compliance, then the vendor must be able to provide their own policies and audit trail of their service. The vendor will need to provide some degree of transparency both to their methods and processes in general, but specifics on who or what has access to your data.

I know a lot of this sounds incredibly obvious, but I have yet to run across a company who has requested this information from their outbound email security provider.

–Adrian Lane