Business Intelligence, or BI, is the art of using a company's data to derive meaningful insights that can help a business flourish. But, whenever an organization grants anyone access to their data, it is also essential that proper security measures be implemented to ensure that the data is used only for the purposes which the company intends. In this article, we provide some guidelines on best practices when it comes to securing your BI environment.
This article was written with QlikView in mind, but almost all the concepts here apply to any BI solution. Action Items are marked in bold. When it comes to securing a BI environment, each of the following points must be carefully considered:
- Implementation of best-practice IT standards on computer machines;
- Use of best efforts to ensure that company data and applications do not leave company computers;
- Use of best efforts to ensure that company data and applications do not leave approved development environments;
- Use of best efforts to ensure that only authorized personnel have access to environments, applications, and data;
- Being able to identify when a security breach has occurred, and
- Creation of a worst-case plan for security breaches.
Implementing IT Standards
First, obviously, all developers and consultants who create applications for an organization should do so using the organization's own computers. This allows the IT department to ensure that certain minimum standards of security are met. These standards can include password complexity requirements, automatic locking of idle machines, etc. Compliance with ISO/IEC 27001:2005 standards is a good goal for an IT department to strive for.
Company Data Staying on Company Computers
Second, there is a fine balance between creating a secure development environment and locking the environment down to the point that a developer actually finds it difficult to work. For example, some companies prevent flash drives from being used on their computers. I would not advise approaches like that. First of all, there are many legitimate reasons why a developer would need access to resources outside the company's network and preventing him from getting to those will, at a minimum, lead to frustration. Second, if a developer indeed intends to remove company data/applications from company computers, and is determined enough to do so, there is nothing that can realistically be done to stop him without completely crippling development machines (and even then you probably would not succeed, since the developer can use a camera to take a picture of his screen, which is something I've personally seen happen). It is, therefore, important to find developers that can be trusted. I would advise that the following be required from all people who will have any access to company data whatsoever: (i) rigorous background checks and drug screening, (ii) references from previous employers, and (iii) from contractors, certain minimum business insurance levels.
Company Data Staying on Development Machines
Third, most enterprise organizations will want to ensure that they have a robust centralized development environment in place. For example, rather than encouraging development on personal computers, an organization may want to direct developers to use a specialized development server, which they can access remotely. There are many advantages to having a centralized development environment ranging from automated backups, to insurance against a PC being stolen, to ease of collaboration among developers. Besides, data sets may be large enough that development on personal computers is impractical due to resource constraints. In addition to a centralized development environment, it is also essential that both raw and transformed data reside (to the extent possible) within a properly-architected data warehouse. This article won't dwell on best practices when it comes to data warehouse architecture, but having a properly architected data warehouse comes with a myriad of advantages, including (i) a central source of “truth” within the company, so that various departments and business units can produce reports using identical data, rather than having to apply ETL operations themselves, (ii) added layers of security, allowing for granular control of company data by database, table, column, and/or row, and (iii) audit capabilities to allow administrators to see exactly which user and machine requested certain data in the event of a security breach. Connections to company data warehouses should only be permitted from approved development environments, by installing necessary drivers and performing necessary configuration on those machines only.
Only Authorized Users on Development Machines
Fourth, it is important that only company-authorized developers have access to development environments. Some best practices to achieve this goal include: (i) providing authorized users with their own login credentials to the development environment itself, (ii) providing each authorized user with data warehouse credentials that are different than the user's development environment credentials and also different from other users' data warehouse credentials, (iii) training users on the importance of keeping login credentials confidential (and instituting stiff penalties for violation of these standards, as well as pointing out that any inappropriate action performed with a person's username implies that the activity was performed by that person himself), (iv) allowing access to development environment from company personal computers only, and (v) requiring a secure VPN connection when users use their company PCs to access development environments remotely.
Identifying Security Breaches
Fifth, it is important to recognize that while QlikView Section Access is often heavily relied upon for application security, it is almost completely ineffective if a developer who has physical access to a QlikView Workbook (QVW) removes it from the company environment. First of all, Section Access will only have a very limited effect on developers themselves since they are generally given ADMIN rights within Section Access to facilitate their development efforts. Plus, of course, a developer can simply create a company of a QVW with Section Access removed entirely. It is generally advisable to use the keyword NTNAME when implementing Section Access, since that is slightly harder to spoof than USERID. However, the fact remains that if a QlikView application is removed from the company environment, the odds are very high that an unauthorized user will be able to access it; even NTNAME access can easily be spoofed by using QlikView web tickets. In addition, a developer can export data from a data warehouse into flat file or QVD storage and remove that data, rather than a QVW application. So, given that it is impossible to completely prevent data from being stolen, it is crucial that a breach at least be detected. There are probably several good approaches for doing so, but here is an example of a combination of security measures that will make a breach detectable in most cases:
- Block all outgoing internet access on development environments, which will prevent users from directly removing files from the environment;
- While it is not a good idea to prevent the development environment from interacting with other company machines altogether (see Company Data Staying on Company Computers section, above), controlling the way in which files can be transferred to/from the development environment is a different matter—you can use advanced Group Policy settings to (a) limit the development environment's network access to only incoming Remote Desktop connections and mapped network drives, and (b) disable all file transfers over RDP;
- Install and configure an audit tool (e.g. ShareMonitor) to monitor your network mapped drives and keep a record of the files that each user transfers to/from the development environment; and
- In the event of a suspected breach (and whenever an employee who had access to company data leaves the organization), an administrator should review the logs stored by the audit tool for suspicious transfers from the development environment to the user's own company PC. If any breach is suspected, the administrator should immediately notify the appropriate department within the organization.
Plan for Security Breaches
Sixth, if all else fails, and you have reason to believe that confidential data and/or applications have left your environment, your company's legal department may wish to take action against the responsible person (which is why I suggested requiring business insurance for contractors, above). Putting lawsuits aside though, it is important that your organization create a plan of action to deal with data being stolen. Considerations when formulating this plan may include: (i) government requirements on reporting certain sensitive stolen data (HIPAA-protected data, for instance), (ii) whether there is any risk that the stolen data could wind up in the hands of your company's competitors, and (iii) implications to a company's image by announcing that a data breach has occurred.
My hope is that this article acts as a catalyst in getting folks to rethink some of their current security measures. It is far from an exhaustive discussion, though. I would welcome (and am actively soliciting!) additional suggestions by security experts in the comments section below.
