"Dundas Consulting did a fantastic job and was able to deliver the final project in two weeks, as planned. We were particularly impressed with the responsiveness of our consultant, as well as his willingness to share his opinions about our needs. Since this was our first dashboard application, we appreciated his candor and experience - especially on the subject of user interfaces."

Mitesh Patel
Executive Technology Director, TMX Communications

more »

Digital Dashboard Security

A Few Considerations To Get You Thinking About Your Next Project

INTRODUCTION

Unlike the traditional efforts in computer security - locking down data sources, networks, firewalls or web access - digital dashboard security is generally focused on the presentation layer and the methods of hiding specific data and resources from unauthorized users. The purpose of this article is to describe security as it pertains to dashboards, as well as give you the basics on dashboard views and filters.

While there are cases when a dashboard may require little security (e.g., publicly available stats from the Olympics), hiding data is not an uncommon request. A medical dashboard in a doctor's office may conceal patient information from prying eyes; a company's accounting department may observe similar privacies. And although it's not considered "security" in the classic sense, data may be partitioned so that users of a particular role or job function - like corporate executives - can focus on the details that are significant to them. Partitioning the application or hiding certain aspects based on the user can streamline the dashboard and remove clutter to ensure it is utilized effectively.

Before we go any further:

Dashboard Security Definitions (see image below)

 

Users - The user is simply the person who uses the application. They are generally identified through some kind of credential, like a login username with a password. In most systems, users can be part of one or many roles or groups. Roles - A role groups together a set of users who have something in common. For example, a dashboard may have administrators (who have full access), executives (who can view all company data) and accounting employees (who have strict access to budgeting information). Resources - A resource (or securable) is simply something that can be secured, like a web page, specific data items in drop downs, administration privileges, etc. Permissions - These are rules that determine if an individual role or user can access a specific resource. Permissions can either be explicitly "allowed" or "denied" on a resource. When a user is part of one or more roles, it is necessary to combine all permissions into a permission set to determine if that user has access to a resource. User permissions will always override role-level permissions.

 

Dashboard Project Planning

Dundas Consulting has created hundreds of dashboard systems and our experience has proven that the risk of not considering security up front can be costly, so security should be evaluated during the initial phases of the dashboard system's design. Two concerns quickly come to mind: The first is related to the visual design of the application, since dashboard security is all about hiding data. Security considerations can have a tremendous impact on how the screen actually looks. Picture "holes" or blocked-out areas on your screen where data is buried below - it does not look pretty (see image below).

The second concern relates to saving time, effort and money in the future: by considering security or role requirements during the initial requirements phase, you benefit by not having to alter the application's user experience to accommodate security or data partitioning later in the project cycle. Delaying security considerations could seriously affect the dashboard project's scope and scheduling.

Dashboard Views

Once the project planning is underway, developers must consider how to partition data and views (dashboard items) from users, based on permissions. The most common way of doing this is via roles, which gives the ability to assign users to roles without managing individual permissions. In some cases it becomes necessary to use a combination of roles and user-level permissions. This gives the administrator complete control over permissions, but it can also increase the level of complexity of the permission sets.

In general, a dashboard application usually has one or more dashboard screens focusing on a specific set of related key performance indicators (KPIs). As stated with the doctor's office example, not all KPIs or dashboards should be viewable to everyone; in these cases the dashboards must be hidden or disabled from the viewer. Hiding dashboards to unauthorized users is usually the better approach. However if you want to make users aware of the existence of a particular dashboard, you may choose to disable the secured dashboard and provide a message and possibly an option to request access.

Dashboard Filters

Dashboard filters utilize permissions and roles to provide the user with a data subset, based on their permissions. These filters can be anything from drop downs and input boxes to clickable charts and maps. They are the basis for the dashboard interactivity and allow the user to filter the data information into smaller subsets.

In the simplest sense, filters are just dashboard parameters and usually consist of a list of available options for each parameter. For instance, when selecting a country from a drop-down list, the data would then be filtered based on that specific country selected. (Also, a map of the world may have the same countries and allow the user to click on the desi red country to accomplish the same thing.) Based on the user’s identity, the system would filter the drop-down list to contain only countries that are applicable to his/her region.

CONCLUSION

While most applications require some form of security, digital dashboard security focuses on visually hiding data and resources from viewers. Though the concepts and infrastructure of traditional security are still important and applicable, it is critical to understand the basic differences when approaching a new dashboard project. The distinction will allow you to truly understand what you are trying to accomplish when applying security or data partitioning to your dashboard system.

About the Author:

 

Andrew Thauer is a Senior Software Development Consultant at Dundas.  He is a seasoned veteran in architecting dashboard systems for various Fortune 500 clients.  In addition, he serves as an advisor to both clients and junior consultants in promoting the importance of a solid framework for building dashboards.