Data Protection
There is no perfect system in the world which is hacker proof. Hackers are developing more sophisticated weapons and methods. As we all know, “chain is no stronger than its weakest link.”
Within our systems, including BI, there are a bunch of different applications being used. Each application and layer should be secure enough to have a completely secure system. When a human factor gets involved in the process, there is always the possibility of mistakes that cause safety risks. Therefore, all environments hosting/handling sensitive data including BI tools should be closely monitored by third-party security tools.
Strategy provides platform analytics for monitoring the environment usage details which helps administrators to identify any security issues.
Authentication permission is also critical to control access to data, depending on the role and responsibility of the user. Strategy has a robust security model that allows you to create users and groups, determine how to authenticate them, check what data they can see and what functional privileges they have. Furthermore, Strategy provides detailed access logs to monitor the environment, providing a clear view of any issues with data access.
Strategy has the following security control levels:
In terms of authentication method, you can use standard, LDAP, Integrated Authentication, Windows, Database, etc. depending on your organization’s standards. Regardless of which authentication is being used, forcing a strict password policy is crucial for better security. Also, adding the Strategy user management into the employee off-boarding process will help to eliminate potential data breach risks due to leaving resources. When any employee leaves the organization, the account should be disabled, and this process should be strictly controlled.
Organizations may have different role definitions depending on a user's responsibilities in the organization. Within Strategy, role user groups can be created to provide different set of Strategy functionalities to users based on their roles. This will also help organizations to limit the user's data access by limiting their assigned functionalities such as importing data, creating database instance objects, etc. You should consider creating your own role definitions based on the organization needs and security requirements instead of just relying on out of the box role definitions. It will help you to force your organization’s own security policy starting at the role level.
When it comes to securing data, object security is also critical. In Strategy, by using object security, user access can be controlled starting from data connection objects to projects, dashboards/reports, attributes/metrics, etc. If there is no proper objects security implementation or best practice in place, it is really easy to expose sensitive data to unrelated audiences. One of the key mistakes in this step is overlapping object security definitions which may expose sensitive data to unrelated users by mistake. To reduce this risk, defining object security with clear isolation from another object security key, starting with Database Instances and on to the most granular objects in Strategy.
Based on this isolation, different user groups should be created with proper naming, which should be clear enough about the purpose of this user group. If the same user group will be used in more than one object security requirement, then the user group name should clearly express that.
If there is no really specific reason, then the user groups for Object Security, Data Security and Roles should not overlap as well. This kind of user group management practice will give the organization great flexibility to cover different combinations of role, object and data security needs.
If the database instance object has been created for any specific application (reports/dashboards), then access to these Database Instance/Database Connection/Database Login objects should be assigned only to the relevant Object Security Group other than environment administrators and developers.
Organizations need to be really careful about the user roles for databases which store very sensitive data such as personally identifiable information (PII), protected health information (PHI), top secret data, etc. Any user with Data Import functionality can connect to these databases because of the assigned object security and browse any data based on the underlying database connection credentials. If this is necessary, database passthrough connection, database level extra security measures, etc. should be considered.
If there is no specific reason, the object security groups should be created by project. The group names also should include project name or abbreviation so that the purpose of this group will be clear for everybody, and it will help to reduce mistakes.
Within Strategy projects, the objects are organized as Schema objects and Public objects. If we have specific object security requirements, we should keep in mind that when we are grouping the Schema or Public objects. This should align with object security requirements, so that assignment will be less complex reduce risk.
After we define object security, our users can use any reports/dashboards they have access to. Now, we need to decide which data elements can be seen by the user within the reports/dashboards. Strategy Security Filters are being used to address this need. One of the common mistakes while handling data security is assigning by user instead of user group. Technically, there is no problem doing it this way but in terms of maintenance, it is costly because of the complexity and it may cause some data security issues. Managing data security by user groups will make the maintenance and monitoring easy and it will reduce the security risks too.
Security
Companies are deploying more and more applications over the Web, making security requirements much more stringent. Strategy addresses these requirements with an elegant architectural design that is optimized for high performance and high scalability while providing secure information to all BI constituents.
Having all these functionalities in Strategy does not mean that out of the box installation, everything will be fully secure. If you did not setup the firewall rules properly, or if you deployed the web and Intelligence Server into the same server, you can easily make your system open to attacks. Strategy platform administrators should closely work with the different teams in the organization to be able to implement the right strategy, not only based on the organization’s internal standards, but also BI industry best practices as well.
Strategy provides a robust security infrastructure and functionalities, but if you don’t follow some best practices, you will still have security issues at the end, and it will be because of human error. I recommend following best practices to maintain the right security model for your environment.
For truly sensitive data, having an approval process with a ticket by using employee service management platform will help to share the responsibility and create awareness of risks and responsibilities.
All these rules or best practices should be documented and communicated clearly with stakeholders. Performing regular checks on the security practices and reviewing the processes on a regular basis will help a lot to improve the security and find any fix gaps.
Also, a monitoring mechanism, such as a dashboard or alert, should be in place and closely monitored by the stakeholders. These monitoring dashboards/reports/alerts can even be opened to application owners in Strategy, so they can monitor the security of their own applications and take an action if there is anything wrong.
All applications/technologies that we use in our BI implementation are always changing with new security vulnerabilities being identified. It is important to conduct regular security tests to capture these vulnerabilities and apply the proper fixes.
Please keep in mind that depending on your industry, environment and regulations in your domain, you may need to find additional best practices.
At the end of the day, companies will be sustainable and successful by keeping a tight shield between business intelligence and security.
A note from the Community team
Learn how install, configure, maintain, and monitor Platform Analytics here: Platform Analytics Guide.
This guide covers user and group management in Workstation.
Get started building your schema with the videos on this playlist on the Learning Center.
