An Enterprise Data Warehouse (EDW), according to California State University, is a collection of data that can be defined and shared across the whole enterprise along the lines of common dimensions to be used for analysis. While you are in the designing phase of an EDW, there are certain security and related functional requirements that needs to be considered.
Security Services Requirements
Authentication: The primary purpose of an EDW is business intelligence. The information contained in it could be confidential to restrictive in nature and will be used for formulating future market of the company. The EDW needs to have an authentication services that assures the identity of the user or system seeking access to the EDW. Authentication services can be implemented using passwords, tokens, biometrics (e.g., fingerprint readers), and encryption.
Access Control: Access control services needs to be in place assuring that people, computer systems, and processes can use only those resources (e.g., files, directories, computers, networks) that they are authorized to use and only for the purposes for which they are authorized. Access control mechanisms can be identity based (e.g., UNIX protection bits, access control lists), label based (also known as mandatory access controls), or role-based (implemented as a combination of the above, plus system privileges). Access control plays an important role in protecting against illegitimate use and in providing confidentiality and integrity protection.
Confidentiality: A typical EDW would contain Personal Identifiable Information (PII) and other sensitive information related Payment Card Industry (PCI). An EDW needs to implement services that protect sensitive and private information from unauthorized disclosure. Confidentiality services are generally implemented using encryption.
Integrity: Since EDW are used for long time purpose specifically for business intelligence, it needs to implement services that assure that data, computer programs, and system resources are as they are expected to be and that they cannot be modified by unauthorized people, software, or computer equipment. Mechanisms for implementing data integrity include cyclic redundancy checks and checksums, and encryption. The type of controls assuring system integrity includes physical protection, virus-protection software, secure initialization mechanisms, and configuration control.
Attribution: “You should be able to identify the person who shot you and not just the gun”. An EDW needs to implement services that assure actions performed on a system are attributable to the entities performing them, and that neither individuals nor systems are able to repudiate their actions. This is possible through audit trails, encryption, and digital signatures.
Availability: An EDW is usually an offline repository which is used whenever there is a need for it. It need not be part of a live or online system providing real team information. The availability is not that critical as a database supporting a live system. However, today some EDW are designed to support real time. Services need to be in place in the EDW assuring systems, applications, and data are available when they are needed. Considerable efforts may be required to safeguard data and critical system services, ensuring that correct and complete information is available. Architects needs to ensure that IT services, utilising EDW, needs to be available for authorized individuals to deliver and process reliably. An important requirement of any privacy protection schema is to ensure that critical data and services are available at all times. The mechanisms providing availability include fault-resilient computers, virus protection software, and RAID (Redundant Array of Inexpensive Disks) storage.
Security Functional Requirements
The security functional requirements that are mentioned below depends on the business requirement and the type of business the EDW is going to support.
Anonymity: While designing a system, sometime there could be business requirements that mandate to protect identity of a user using a system while maintaining audit trails of the means of accessing the system. Here a separate system used by the user could be the subject accessing the system. In case of such requirements for anonymity, an EDW needs to provide protection of the user identity. Anonymity is not intended to protect the subject identity.
Pseudonymity: There are use cases where a user or a system seeking access does not want to disclose their identity. This is a rare requirement and depends on the business that is supported. Pseudonymity ensures that a user may use a resource or service without disclosing its user identity, but can still be accountable for that use.
Unlinkability: A subject may various resources for completely different purposes. Unlinkability ensures that a user may make multiple uses of resources or services without others being able to link these uses together. This is a good case for an EDW having wealth information that could be used for different purposes.
Unobservability: In an enterprise where there could be multiple departments, one department may not want the other to know that it is accessing certain resource. Unobservability ensures that a user may use a resource or service without others, especially third parties, being able to observe that the resource or service is being used. This scenario is a good case where the business is to provide EDW services for multiple competing departments or even companies.