How to Implement Content Based Security Rules

“Should I grant access to this report containing sensitive data?. . .”

The employee needs some of the data, but other parts are above their clearance level. What would you do?

Restricting access to report content is normal in most report and ECM solutions. But, limiting who can and cannot see a given report is just the first step in securing report content and sensitive data.

Lacking the ability to dynamically assign permissions to specific portions of your report leaves you with one of two options:

1. You can create security settings that are too restrictive and hide information that would be helpful for the end user’s job for the sake of keeping other secure information under lock and key.

2. More likely, leaving security settings too loose in the name of making it easier for people to do their job. This happens when you open up access to data that a person shouldn’t have access to in order to also show them the information that is pertinent to their job.Loss Due To Unauthorized Computer Usage

In 2013, U.S. Companies Reported $40,000,000,000 (That’s $40 BILLION) in losses from the unauthorized use of computers by employees. (Experian) While looking at those statistics, it is easy to shove them off but remember, your employees could be doing the same things, they just haven’t been caught – yet.

Unless you’re securing report content based on distinguishing characteristics in the report, you’re forced to decide between the two options we just discussed.

Consider this example:

Jackson, a sales manager at Acme Corporation, oversees the Minnesota & Wisconsin sales teams. Those responsibilities are noted in his domain account or other system authentication source which is integrated with your report / content management system.

Using his account information, you can grant him access to the national sales report without letting him see teams he doesn’t manage.

Jackson will not be able to access the pages that have information on any other sales team. For a weekly national sales report that was 50 pages (1 for each state) Jackson will only see two pages.

 

Content Based Security Example

Not only does this help keep the information more secure, but it also significantly improves the rate at which Jackson can review the information that he cares about and get on with this day. All without sifting through pages and pages of data.

The best part about handling security this way is the flexibility to provide additional permissions as he starts managing new teams. He will be able to see all future and historical report data for the new teams.

Similarly, if Jackson stops managing a team, removing that permission revokes his access to all historical and future access to the team’s results.

This scenario would most likely falls in the “Too Loose” category if it hadn’t been for content based security. The report is necessary to measure progress but would have exposed information the employee should not be able to see.

Take Away

Distributing reports without page level security typically causes a lack of information or loose permissions.

Security At High Levels

Let’s take our weekly sales report for example.

We’ve already determined that all sales managers can access the report when it’s released each week. While it is ideal to only allow sales managers to see data for the teams they manage, their superiors likely need more access, such as the VP of Sales, and should be able to see all results from all teams.

Example 1:

Kim is the VP of the Midwest division and has access to see all weekly sales reports for sales teams in her division. 

By securing reports based on the content on each individual page, you are able to provide much more pointed and explicit permissions to keep security tighter, and give meaningful results to those searching.

You can could also create security groups based on the region of employees.

Example 2:

Janet is the VP of Global Sales so she can see all the reports for all teams in all regions.

Take Away

Use the information you have to empower your team without increasing your security risks

Apply this to your infrastructure:

  1. Pick a report that should be broken down to restrict sensitive data.
    Typically, a weekly or monthly report that is broad in its contents and widely distributed.
  2. Find the identifying element/descriptor for a page that should be shown.
    An identifying element could be a company division, region, or another descriptor about the content.
  3. Configure security only to allow users to see pages with

Have questions about securing your documents? Use our contact form to the right; we’d love to help you out.

This content is excerpted from our free content security e-book. To get your free copy, drop your email in the box below!

Receive our free e-book!

* indicates required

 

 

Comments are closed.