Layered Database Security in the age of Data Breaches

We live in a time of daily breach notifications. One recently affected organization in Germany put out a statement which said: "The incident is not attributable to security deficiencies." and "Human error can also be ruled out." They went on say that it is "virtually impossible to provide viable protection against organized, highly professional hacking attacks." It's a tough climate we find ourselves in. It  just feels too hard or impossible at times. And there's some truth to that. There are way too many potential attack vectors for comfort.

Many breaches occur in ways that make it difficult to pinpoint exactly what might have prevented it. Or, the companies involved hide details about what actually happened or how. In some cases, they lie. They might claim there was some Advanced Persistent Threat on the network when in reality, it was a simple phishing attack where credentials were simply handed over.

In one recent case, a third party vendor apparently uploaded a database file to an unsecured Amazon AWS server. A media outlet covering the story called out that it was not hacking because the data was made so easily available. Numerous checkpoints come to mind that each could have prevented or lessened the damage in this scenario. I’d like to paint a picture of the numerous layers of defense that should be in place to help prevent this type of exposure.

Layer 1: Removing Production Data

The data should have been long removed from the database.

Assuming this is a non-production database (and I sure hope it is), it should have been fully masked before it was even saved as a file. Masking data means completely removing the original sensitive data and replacing it with fake data that looks and acts real. This enables safe use of the database for app development, QA, and testing. Data can be masked as it’s exported from the production database (most secure) or in a secure staging environment after the initial export. Had this step been done, the database could safely be placed on an insecure AWS server with limited security concerns because there’s no real data. An attacker could perhaps use the DB schema or other details to better formulate an attack on the production data, so I’m not recommending posting masked databases publicly, but the risk of data loss is severely limited once the data is masked.

Layer 2: Secure Cloud Server Configuration

The researcher should never have been able to get to the file.

A security researcher poking around the web should never have been able to access this database file. Proper server configuration and access controls should prevent unauthorized access to any files (including databases). In addition to documenting proper security configuration, certain Cloud Security Access Brokers can be used to continuously monitor AWS instances to ensure that server configurations match the corporate guidelines. Any instances of configuration drift can be auto-remediated with these solutions to ensure that humans don’t accidentally misconfigure servers or miss security settings in the course of daily administration.

Layer 3: Apply Database Encryption

Even with access to the database file, the researcher should not have been able to access the data.

At-rest data encryption that is built into the database protects sensitive data against this type of scenario. Even if someone has the database file, if it were encrypted, the file would essentially be useless. An attacker would have to implement an advanced crypto attack which would take enormous resources and time to conduct and is, for all intents and purposes, impractical. Encryption is a no-brainer. Some organizations use disk-layer encryption, which is OK in the event of lost or stolen disk. However, if a database file is moved to an unencrypted volume, it is no longer protected. In-database encryption improves security because the security stays with the file regardless of where it’s moved or exported. The data remains encrypted and inaccessible without the proper encryption keys regardless of where the database file is moved.

Layer 4: Apply Database Administrative Controls

Even with administrative permissions to the database, the researcher should not have been able to access the sensitive data.

I’m not aware of similar capabilities outside of Oracle database, but Oracle Database Vault would have also prevented this breach by implementing access controls within the database. Database Vault effectively segregates roles (enforces Separation of Duties) so that even an attacker with DBA permissions and access to the database file and encryption keys cannot run queries against the sensitive application data within the database because their role does not allow it. This role-based access, enforced within the database, is an extremely effective control to avoid accidental access that may occur throughout the course of daily database administration.

Layer 5: Protect Data Within the Database

Even with full authorization to application data, highly sensitive fields should be protected within the database.

Assuming all of the other layers break down and you have full access to the unencrypted database file and credentials that are authorized to access the sensitive application data, certain highly sensitive fields should be protected via application-tier encryption. Social Security Numbers and Passwords, for example, shouldn’t be stored in plain text. By applying protection for these fields at the app layer, even fully authorized users wouldn’t have access. We all know that passwords should be hashed so that the password field is only useful to the individual user who enters their correct password. But other fields, like SSN, can be encrypted at the app layer to protect against accidental exposure (human error), intentional insider attack, or exposed credentials (perhaps via phishing attack).

Maybe the vendor didn’t follow the proper protocols instituted by the organization. Maybe they made a human error; we all make mistakes. But, that’s why a layered approach to database security is critical on any database instances where sensitive production data resides. Security protocols shouldn’t require humans to make the right decisions. They should apply security best practices by default and without option.

Assuming this was a non-production database, any sensitive data should have been fully masked/replaced before it was even made available. And, if it was a production DB, database encryption and access control protections that stay with the database during export or if the database file is moved away from an encrypted volume should have been applied. The data should have been protected before the vendor's analyst ever got his/her hands on it. Oracle Database Vault would have prevented even a DBA-type user from being able to access the sensitive user data that was exposed here. These are not new technologies; they’ve been around for many years with plentiful documentation and industry awareness.

Unfortunately, a few of the early comments I read on this particular event were declarations or warnings about how this proves that cloud is less secure than on-premises deployments. I don’t agree. Many cloud services are configured with security by default and offer far more protection than company-owned data centers. Companies should seek cloud services that enable security by default and that offer layered security controls; more security than their own data centers. It’s more than selecting the right Cloud Service Provider. You also need to choose the right service; one that matches the specific needs (including security needs) of your current project. The top CSPs offer multiple IaaS and/or PaaS options that may meet the basic project requirements. While cloud computing grew popular because it’s easy and low cost, ease-of-use and cost are not always the most important factors when choosing the right cloud service. When sensitive data is involved, security needs to be weighed heavily when making service decisions.

I'll leave you with this. Today's computing landscape is extremely complex and constantly changing. But security controls are evolving to address what has been called the extended enterprise (which includes cloud computing and user mobility among other characteristics). Don't leave security in the hands of humans. And apply security in layers to cover as many potential attack vectors as possible. Enable security by default and apply automated checks to ensure that security configuration guidelines are being followed.

Note: Some of the content above is based on my understanding of Oracle security products (encryption, masking, CASB, etc.) Specific techniques or advantages mentioned may not apply to other vendors’ similar solutions.

Human Behavior = Biggest Security Risk

Two quick examples (both considered 'spear phishing' or targeted phishing attacks) from today's headlines:

1. The perpetrators of the RSA data breach which may have compromised the security of RSA's premium two-factor authentication solution, as it turns out, got help from RSA employees when they opened an email attachment. An Excel spreadsheet containing an Adobe Flash exploit opened the doors to RSA's network.

2. Conde Nast recently paid $8 Million to a fake company in response to a single believeable email that asked them politely to update their payee information on one of their vendors.

Both of these examples make the clear, simple point that it doesn't really matter how much technology you put between an attacker and your business assets. If an employee opens the door, they can walk right in. We're either going to get extreme in terms of limiting behavioral options (disallow all email attachments?) or we need to do much better in employee training.

Since employees are ultimately only motivated by what is easier, I don't think training will be the silver-bullet answer.

How to clean up years of permission bloat

Since joining NetVision a few years ago, I've spoken to countless organizations who are faced with clean up duty. For years, administrators have granted permissions, added group memberships, created countless new security groups, delegated rights in Active Directory and have been mostly in a reactive mode. That is, they grant permissions in response to some member of the business asking for new rights. Unfortunately, business managers have not had motivation to request that permissions be revoked when appropriate. So, in many cases, there are hundreds or thousands of security groups that nobody seems to know what they're for or how they should be used. And some big percentage of the user population has access to files/folders that they shouldn't.

In an ESJ article titled Coming Clean: Getting a Handle on Permissions and Group Memberships, NetVision CEO David Rowe discusses the challenge and explains how you can regain control over network access rights.

The 'Soft' Insider Threat: More Data

There's a new IDC white paper sponsored by RSA:
Insider Risk Management: A Framework Approach to Internal Security (PDF)

It has some interesting data on the risk posed by insiders. Specifically, they look at the difference between risk from malicious attackers and the risk posed by unintentional breaches or well-intentioned employees (the 'Soft' Insider Threat).

Courion points out one of the most interesting data points:

"CXOs also revealed that the greatest financial impact to their organization was caused by risks related to out-of-date or excessive access rights"

I was surprised by that. I intuitively know that soft breaches occur far more often than malicious attacks. But, my intuition also tells me that malicious attacks probably cause far more extensive financial harm. The respondents of this survey tell us that inappropriate permissions lead to greater financial harm than malware, internal fraud, deliberate policy violations, and unauthorized access (among others).

You should look directly at the data. It does vary by country. In the U.S. (where the greatest financial losses were reported by respondents), internal fraud edges out excessive rights, but I'm still surprised to see the financial impact of each is almost equal. And keep closer watch on contractors and temporary employees!

USB Drive Security Issues

The SANS Institute recently published a document discussing Universal Serial Bus (USB) drives (also called Thumb Drives, Flash Drives, or USB Keys) and their implications on enterprise security. It's a good overview of the basic threats, types of attacks, as well as common risk mitigation strategies.

It's titled: USB - Ubiquitous Security Backdoor

Despite the lame title, if you're trying to make sense of the threat posed by flash memory drives, it's worth a look. Of course, if you're already a security guru, you can give this one a pass.

Quick Reference Guides for Windows and AD admins

Active Directory UserAccountControl – Common values related to access rights.

Windows File System Permissions – As labelled in the Windows Security dialog with descriptions for both folders and files.

The SOFT Insider Threat

I've written a lot about the insider threat and what it means to me. A while back, I spoke to IT Business Edge about my opinion that non-malicious insiders pose a greater risk of causing a breach than malicious insiders. Many in the industry still claim that insiders should not be a major cause for concern and that external threats should get the lion's share of attention.

It's fairly easy to see that malicious attacks cause immediate and expansive financial harm. But, the unintentional or at least non-malicious insider breaches, which I'll call the Soft Insider Threat, occurs far more often – perhaps hundreds of times every day.

Today, I read a story in NetworkWorld titled Inside a Data Leak Audit that illustrates my story.

The IT Director at a pharmaceutical firm facilitated a data leakage audit for his company. Before the audit, the firm believed they "were in good shape". They "had done internal and external audits" and "extensive penetration testing". They had intrusion detection and prevention solutions, laptop encryption, and employee training. What they found out is that "you can do all that and it's just not enough."

The audit, conducted by Networks Unlimited, revealed gaping holes, including:

• 700 leaks of critical information, such as Social Security numbers, pricing, financial information and other sensitive data in violation of the PCI-DSS standards.
• Over 4,000 incidents that ran counter to HIPAA and Defense Department Information Assurance Certification rules.
• More than 1,000 cases of unencrypted password dissemination, such as to access personal, Web-based e-mail accounts.

A few specific examples:

• Employees sent ZIP files and attachments of confidential documents in unencrypted emails.
• An employee attached a clinical study report in an unencrypted email to an outside vendor.
• An employee sent sensitive employee compensation data to an outside survey company inc. salary, bonuses, sales quota, stock options, granted share price and more.

This single audit conducted on one company revealed 11,000 potential leaks that not only went unreported as data breaches, but wouldn't have even been known about or identified as problematic if the audit wasn't going on at the time.

I call them soft breaches because they're not intended to be harmful and may not ever cause harm or get noticed. But if they happen 10,000 times over the course of two weeks, that's 260,000 security violations each year. And those are real breaches that may violate HIPAA or PCI-DSS, expose employee and customer information, violate business contracts, and otherwise cause potential for harm. It should be pretty apparent that if this happens 260,000 times each year, that's a pretty big attack surface.

As the author and auditor say in the article, don't leave security in the hands of end-users. Automate the important stuff and track activity on a regular basis to ensure that your attack-surface is in-line with your risk tolerance. Don't ignore the soft insider threat just because it gets overlooked. That's the exact reason why you need to address it.

Bad Guy Scenario

Here's a perfect example of the insider "bad guy" threat scenario. An unhappy ex-employee came back in through an Internet-based system and put malicious code on the company's customers' servers. He installed the code on 1000 servers and crashed 25 out of the 1000. The company reports a cost of $49,000 to find and fix the problem. They also say it could have cost $4.25 million if all 1000 servers had crashed.

The Lessons:

• Be diligent about monitoring – catching this early saved close to $4 Million
• De-Provision (it's unclear whether the employee still had an account)
• Include hosted and Internet systems in your de-provisioning process
• Do security audits to find and fill holes

Although I don't think the "bad guy" scenario happens nearly as much as the "good guy" security breach scenario, it has the potential to get very expensive very quickly.

Data Breaches Up in 2008

The Washington Post reported today that Data Breaches were up 50% in 2008. There are probably lots of contributing factors to the increase in stats:

• As the article points out, an increase in participation and sophistication of organized crime with regard to electronic crimes. I've heard this in multiple places.
• Stricter adherence to regulations that require notification of breaches (as pointed out by Shannon McNaught on Twitter -- where I stumbled across the article)
• Continued lack of deterrents for Crimes of Opportunity. Organizations have been slow to get serious about monitoring admin activity.
• An increasing reliance on electronic forms of data - people and companies have increasingly become more trusting and more reliant on electronic media. This makes the data increasingly more valuable and therefore a bigger target.
• Improved tools and sophistication that enables theft. A 16 GB USB key is an extremely effective way to quickly transfer large amounts of data without being detected. Improved technology and lower cost has introduced new and stronger threats.

The article also states that "The largest single cause of data breaches came from human error" once again affirming my proposal that by far most breaches are not malicious. I recently heard a genuine real-world story that an admin made an error on a windows drag-and-drop (as we all sometimes do) and an entire factory was brought to a standstill -- an OU was moved in AD.

It also points out that statistics "mask the extent of the problem" because many organizations fail to report data breaches. As I said before:

Nobody calls a forensics team when an admin opens up an HR doc containing a co-worker's salary. Or when an admin creates a new account and grants full system rights in order to get a new application up and running.

We all know the implications. If you've got sensitive data, understand your risk, know what your threats are, and be proactive before you become one of the stats.

More Insider Threat Data

RSA recently released their latest data on Insider security.

Some interesting results:

53% of respondents feel they NEED to work around security policies to get their jobs done.

37% of respondents have stumbled into areas of the network to which they SHOULDN'T have access.

50% of U.S. respondents switched roles and still had access to UNNECESSARY accounts/resources.

And that's with most respondents understanding security policies and having been given training about the importance of following security practices.

The last time I wrote about an RSA survey pointing out that employees feel they NEED to work around security controls to get their jobs done, the number was at 35%. So, it's either gotten worse or it varies from crowd to crowd (likely the latter).

Get the full survey report here

Identity-Based NAC or UTM

While walking the floor at Interop in NYC this week, I stopped to chat with the guys at the Cyberoam booth. Cyberoam provides a security appliance that provides identity-based Unified Threat Management (UTM). Similar to most Network Access Control (NAC) devices, the solution grants and denies access to systems and resources based on the IP+port destination address. Typically, this is done at the network layer by enforcing policies based on the requesting machine's MAC address (laptop X is allowed to access application Y on server Z).

Cyberoam's messaging is that they are identity-based. This means that the appliance (the red box below) doesn't enforce policies strictly based on MAC address (the user's hardware). It is identity-aware in that it knows who is logged onto the desktop, verifies policies and access rights against the network directory (Microsoft's Active Directory, for example) and grants access to the user rather than to the machine. This is a level of protection and intelligence above purely hardware-driven NAC solutions.

I can't vouch for Cyberoam as a solution. I haven't used it and don't know more than was told to me in a five minute conversation. But, I immediately recognized a use-case scenario for NetVision.

If access to systems and assets across the network is based on data held within Active Directory, then you better be able to monitor changes to that data and get immediate alerts if there's a policy breach. If it's true that 88% of IT admins would steal from their employers or snoop around the network, then an environment that puts the keys to the kingdoms in the hands of the Active Directory administrators needs a comprehensive ability to audit and monitor administrative activity.

So, if you are a Cyberoam customer or if you have a similar NAC or UTM solution that relies heavily on the network directory, please let me know. Even if you're not interested in finding a monitoring solution, I'll buy you a cup of coffee and maybe lunch if you're willing to tell me about your environment, the business challenges, how it's going, what risks you see, etc..

89% of Security Incidents in 2007 Unreported

I've been saying for the past few years that most security breaches go unreported, but I had no hard data to back it up.  I just believed it by instinct and some anecdotal evidence.  Now, we have a survey to point to with supporting data that claims 89% of data leakage incidents in 2007 went unreported.  I've also talked a lot about non-malicious insider breaches which is listed as the #2 security challenge by respondents of this survey.  I haven't seen that question asked very often.  Interesting data points.  Data leakage, lost devices, insider threats continue to be a major concern (along with email attachments, malware and phishing).

Cyber-Ark Study: 88% of IT admins would steal

From the press release:

Of the 88 percent that said they would take valuable information with them, one third of devious IT administrators would take the privilege password list which would give them access to all the other sensitive and valuable documents and information such as financial reports, accounts, and HR records.

Also:

The survey also found that one third of IT staff admitted to snooping around the network, looking at highly confidential information, such as salary details, M & A plans, people's personal emails, board meeting minutes and other personal information that they were not privy to. They did this by using their privileged rights and administrative passwords to access information that is confidential or sensitive.

I guess if you're hiring an IT admin, you might ask if they participated in the Cyber-Ark study and if so, there's an 88% chance that you shouldn't hire them. I know the criticism about surveys like this, but is it really that hard to believe? Seems like human nature to me.

Insider Threat: Crime of Opportunity

For the past few years, I've talked to many people about the insider threat. I don't spend too much time focused on the hardcore criminal element that plan an attack against their employer. I have mostly been thinking about the 35% of employees that claim they need to break policies in order to get their jobs done (see my post on Insider Threat - By the Numbers). And the unknown percentage of employees who break policies without being noticed (or in many cases without even knowing it).

A few days ago, security researcher Ira Winkler articulated one aspect of this very plainly.

Why is there a sudden epidemic of violations of sensitive personal information? The answer is, Because it’s there.

The scenario of an employee viewing sensitive information that they shouldn't be viewing is a fairly common example of real-world insider security breaches. While it won't likely lead to a $7 Billion loss, it could mean a failed audit, bad publicity, lost customers, or other lost business opportunities. In today's transparent business environment, it's only a matter of time before juicy information is made public. State Dept. employees were probably snooping on passport information for years before they found the 2008 presidential candidates. Then, it got out and became a news story.

Winkler goes on to note:

Anyone developing or maintaining information just better accept that their fellow workers will look at information and that they need to track and limit access. More importantly, they better look at their audit logs and specifically search for violations.

I agree. One of the scenarios I often run into is where administrators require access to files (in order to manage access) but they don't require access to the information within those files. A good example is the admin who controls access to HR files and has the ability to open offer letters containing salary and other personal information. To Winkler's point, if the capability is there, they will likely open the files to take a peek. After all, they have been explicitly granted access to those files in order to do their jobs. Doesn't that make it OK? No. And to Winkler's final point, the admin would probably exercise additional restraint if they knew that file access was being monitored.

Obama Passport Breached by Insider

This is a great example of one of the most underestimated insider threat scenarios that I would be worried about if I were managing GRC for an organization.

Three employees of the U.S. State Department, who were properly given access rights to passport files, inappropriately used those rights to access details such as Obama's date and place of birth, e-mail address, mailing address, Social Security number, former names and travel plans. Was this a problem about not having the right policies in place? No. A problem with ineffective controls? No. It's simply a problem of a few people choosing to abuse the trust that had been given them – not out of malice, but simple curiosity (most likely).

Luckily, the State Department has computer-monitoring equipment in place that triggered alarms. And each of the three breaches was identified and dealt with. This incident will serve as a pretty strong deterrent for future curious employees who might otherwise be tempted to try the same thing. And (if this wasn't a government agency) the organization would be able to prove to auditors pretty quickly that they're effectively managing the risk associated to the access rights provided to employees and contractors. Because even when there is risk, they're watching and ready to respond.

UPDATE:
Apparently, it was a bipartisan attack.

Users Cutting Corners, Not Crooks, Are Main Inside Threat

Thanks to IT Business Edge for taking some time to speak with me about the insider threat. Now, I'm going to take a moment to argue with myself on one point. While I do think non-malicious breaches occur far more often than their malicious counterparts, I do also concede that so far it appears that the malicous attacks have brought about more monetary damages (which is usually the bottom line in corporate environments). So, the question of which is a bigger threat probably depends on which beans you're counting. Strictly from an audit and policy perspective, you want to be sure that policies are being enforced, which is why the numerous security breaches we often see in our daily routines seem like a bigger threat. They're more likely to cause problems in an audit or compliance project. And they open holes which can be exploited during malicious attacks. So, if you don't patch the holes that are often exploited by non-malicious personnel, it could come back to bite you in the bottom line.

The Insider Threat: News & Info

Some recent news of malicious insiders:

• Employee's silent rampage wipes out $2.5m worth of data - Here, a woman unnecessarily fearing job loss wiped out valuable employer data.


• Sys admin jailed for 30 months over failed logic bomb - A system administrator at MedCo planted a logic bomb that was luckily a dud in his first attempt.

Some interesting reading on the insider threat:

• Are Insiders Really a Threat? - An article from the Software Engineering Institute at Carnegie Mellon discussing the reality of the insider threat and outlining thirteen practices for preventing insider attacks. Incidentally, I think the 30% stat they provide is low. I think 30% may be the percentage of reported malicious attacks perpetrated by insiders. A far greater number of security breaches happen every day by non-malicious insiders. And here's an article on research suggesting that many insider breaches aren't reported (and why).


• The CERT Insider Threat Research page - Lots of useful information on insider breaches, including the source of the article above.

What does all that mean?

Well, the insider threat is real. I don't think that's controversial news. But I would argue that there are far more light security breaches by insiders than malicious attacks -- something I haven't seen much data on. But a breach is a breach and in many cases can be prevented with the right policies, processes and tools. I like the SEI article and I think it provides a good place to start thinking about how to approach the challenge.

Insider Threat - By the Numbers

I've been talking with customers and colleagues about the insider threat throughout most of 2007. I've mentioned stats that 70% of electronic security breaches originate inside the firewall and 90% of those are users with elevated rights (systems administrators, etc.).

For the most part, I've rationalized that most of those attacks are likely in one of these two categories:

• Opportunistic
• Unintentional

The category that's missing is malicious. I leave out malicious because I believe the large majority of breaches are not intentional or at least not driven by ill-intent. From what I've seen, people break security policies because their everyday jobs lead them to it. Sometimes, people break security protocols in order to meet a deadline or otherwise get a task accomplished. Other times, opportunity just presents itself.

Consider these scenarios:

• A DBA opens a database to accomplish a work-related task and encounters data that's just too enticing to ignore.
• A file system administrator is asked to grant a new HR manager access to the file share that houses previous employees' offer letters and he/she can't help but take a peak at a few co-worker salaries.
• An employee is asked to take some work home and rather than carry a company laptop, they put sensitive information on a USB key that they often use to share songs or other trivial files with friends. Or they email files to/from a personal account which may not be secure.
• In software development and/or integration, I've seen numerous people make decisions to share a password, grant full permissions or otherwise remove security restrictions to troubleshoot some software or configuration-related issue.

All of these scenarios represent a real security risk to the organization but none would be considered a malicious attack. When I first saw the 70% number, I thought it had to include these types of scenarios. I know malicious attacks happen, but I just don't see it in my daily life. These scenarios, however, are another story. It's almost hard to work on any corporate project and not encounter these types of security breaches.

A series of articles posted yesterday in Network World by Denise Dubie provides some air cover for the arguments I've made based on personal experience. Check out just a few of these quotes, then go look at the articles for yourself. Great food for thought.

End users behaving badly
Most employees knowingly violate corporate security policies.
By Denise Dubie, Network World, 12/10/07

"most companies say they have security policies in place, yet data breaches continue to plague more than 75% of Fortune 1000 companies"

"More than 50% of survey respondents admit to copying confidential information onto a USB memory stick, and 87% say they believe that the company's policy forbids it. But 40% also reported they knowingly break the policy because the company doesn't enforce it, and another 21% said 'no one really cares about compliance with this policy.' Close to 30% said they'd violate the policy because otherwise they would not be able to complete their work on time."

"46% of those polled said they share their passwords at work, and 40% of survey respondents believe that sharing passwords with co-workers is necessary to get work done within deadlines"

Trusted users pose significant security threats, survey finds
RSA survey data reveals innocent insiders create data exposures of extraordinary scope
By Denise Dubie, Network World, 12/10/07

"35% of people polled said they need to work around their organization's security policies to get their job done"

"34% reported having held a door open for someone they did not recognize"

Scary tech stories: How dangerous user behavior puts networks at risk
IT managers share tales of how users' actions can cause security nightmares
By Denise Dubie, Network World, 12/10/07

"end users just don't think passwords are a big deal and think we are just here to make their lives miserable when we request them to change or update passwords"

NetVision: Policing the Power of Identity

NetVision issued a press release today in conjunction with our appearance at Digital ID World. It's primarily about our very cool new reporting capabilities to be officially released in October. The release also points to a four minute whiteboard session explaining what we mean by Policing the Power of Identity. If you have four minutes, please take a look. Since I created the presentation, I especially hope you enjoy it.

Identity Management Detective

Jackson Shaw asks "is there a role for an identity management detective?" Although I suspect it was mostly a rhetorical question, the answer is absolutely. You may have seen my recent post on Policing the Power of Identity. The challenge that Jackson describes is exactly what we have in mind when we talk about policing identity. Many of NetVision's customers recognize that they can't provide answers to basic questions about what identity controls are in place, what are people doing on the network and what power has been given to users. The combination of controls, behavior and power is what makes up the power of identity. And our customers are definitely finding value in tools that provide policing/detective capabilities around that power.