Data Warehouse. T rusted Application. P roject. Trusted System. T echnology. System. Trusted Network. Physical Security

Size: px

Start display at page:

Download "Data Warehouse. T rusted Application. P roject. Trusted System. T echnology. System. Trusted Network. Physical Security"

Archibald Britton Sharp
5 years ago
Views:

2 T rusted Application Trusted System Trusted Network Physical Security System T echnology Data Warehouse P roject

4 Filetransfer Access right just on the data transfer directories Mailbox L oadprocess Data Warehouse F ull acces s right on the data warehous e

10 Introduction Information security is an important demand on an IT-project in the today s technological environment. The complexity is increasing with a large extent of networking and its various possibilities of access. A company has not just to guarantee the availability and integrity, but also the confidentiality of the data. Every unauthorised access on systems and data has to be rejected. Uncovered attacks of hackers are spectacular in media. But also in the company itself it is obvious to fulfil the need to have principle, implementing the segregation of duties by restricting access. The Group Internal Audit of UBS AG has built up an own SAS data warehouse to have data ready for the financial auditors. Because of the sensitivity of the assets we had to implement high security features. Therefore we developed a security concept for our own data warehouse. To make a data warehouse (or other data bases) a high trusted security system, measures have to be taken at different levels. In my paper, I will deal with particular security concepts which are of interest to data warehouse projects. I will not discuss general security requirements for a company. I will focus on the conceptional level and refer to our implementation as an example.

Security Levels Looking at it from the aspect of data security, the following levels of security can be classified according to the respective measures.

11 Security Levels Looking at it from the aspect of data security, the following levels of security can be classified according to the respective measures. Physical Security: Sensitive systems can be protected in particular safety areas like data centres with rigorous access control and protection against environmental and hazard risks. Trusted Network: An internal network can be safeguarded against the outside by firewalls. A firewall system controls the access and the data transfers from the outside world into the trusted internal network of a company. The additional encryption of the data offers more security. A central function is the access control of processes and users by strong authentication algorithm. Trusted System: The operating system security includes all measures which protect the central and critical function of an operating system. For example, users have to change their passwords, but under no circumstances they are allowed to access someone else s password. The access of processes and users on data, for example on a data warehouse server, has to be restricted in accordance with the responsibilities ( need to have principle). The access control is based on the authorisation concept. An other important area is database security, which can be implemented in the operating system, within the data base or in the applications. Trusted Application: This includes database security if it is built in the application. But also the security of a client/serverconnection (SAS -SAS -connection) has to be analysed, particularly if the interface links a trusted server with an untrusted desktop. Out of this security measures, I like to deal with three particular subjects in this paper. Because physical, network and operating system security mostly are the tasks of specialised groups in a company, I concentrate on the areas which a data warehouse project has to consider. 1. Access control of the data transfer processes on information in the data warehouse. 2. Authorisation concept and database security. 3. Client/server-connection (SAS/CONNECT and SAS/SHARE ) from a desktop to a data warehouse or data mart server.

12 Access Control of Processes This part describes the security risks of transfers and load processes of data into a data warehouse. Often data is regularly delivered from operative systems to the data warehouse using filetransfers like FTP. Postprocessings are used to start the data load process automatically after the data transfer. This programs call the data loading programs (SAS or others). Because the postprocessings are directly linked with the load processes by calls, also the postprocessings need the access rights of the loading processes. They build up a chain inheriting the access rights. Therefore, the postprocessings have access rights on the data in the data warehouse itself, not only read but also write access. The risk of such a chain of processes is the possibility to get access on data in the data warehouse over the external interface. To fulfil the segregation of duties, the transfer-load processes have to be divided in two independent chains of processes which have access rights according to their tasks. The postprocessings just have access rights on the directories for the transfer processes (delivery directories) and the load processes have access rights on the delivery directories and the data in the data warehouse. An elegant solution is the use of mailboxes, as we have implemented it in our data warehouse. After the filetransfer into the delivery directories, the started postprocess writes a message with the name of the transferred file into a mailbox. A wait-process gets active as soon as the message has been written into the mailbox. It starts the loading programs (a parameter is the filename) to load the data into the data warehouse. The transfer and the load process have read and write access on the receive directories. But only the load process has full access rights on the data warehouse. The data warehouse is fully uncoupled from the external interface of the data transfer and therefore protected against attacks.

Authorisation: One of the most powerful authorisation concept is the Role-Based-Access Control (RBAC). The users are participants of roles corresponding to their function in the company.

In RBAC the users are functionally assigned to roles, which allows to access the objects over operations (actions).

13 Authorisation: One of the most powerful authorisation concept is the Role-Based-Access Control (RBAC). The users are participants of roles corresponding to their function in the company. The access and the operations on objects are defined over roles. The advantages are flexible adaptation to company security polices and the reduction of security management. In RBAC the users are functionally assigned to roles, which allows to access the objects over operations (actions). A user is a person, a role is a collection of job-functions and an operation represents the access mode on one or more (data) objects. Between users and roles, roles and operations, operations and objects exist many-to-many relationships. Example: FOREX in the Internal Audit Group, UBS AG

14 Our organisation is a matrix. One axis represents the product view, the other the regional view. For each product area (i.e. investment banking, asset management,...) we have defined a role. Every staff of one division is allocated to this role. In the regional area each location has an own role, to which all staff of this region are allocated to. They have only access on the products in their region. It is possible to build hierarchies of roles. For example, there could be defined one role for each product of a region. Thus the role product of all regions is the sum of the part roles of the product per region. Because we do not need a more detailed concept than the product / region view, we have done it without this hierarchical level. The next higher level is the data administration. This function contains all product and regional roles so that the data administrator has access to all products and all regions in the data warehouse. The operations (the rights of access) on the respective objects has to be defined for each role. In an operative data base system operations can be designed along the transactions. For example, customer data is readable for a lot of staff, but only a few staff looking after the customers have access rights to the operation new customer. In a data warehouse normally the operations can be reduced to the read operation, because users are just allowed to read and not to update the data. However the data administrator has full access rights (read / write / delete) to the data. The RBAC allows designing any layering of the access rights to the objects to implement complex business models and guarantee the segregation of duties. A great advantage of the RBAC-model is the simple and secure administration. A user just has to be granted or revoked to roles. Thus, for example a user, auditing a product outside his division, is granted to the necessary role and revoked again after the audit has finished. Implementation RBAC The implementation of the RBAC models differs from system to system. Principally it can be implemented in two ways: in the operating system or the data base management system. For our data warehouse we use SAS as database (SAS datasets) and OpenVMS as operating system. Because SAS has no features to implement the authorisation concept, we had to build up the RBAC-model in the operating system. This implementation is quit simple under OpenVMS, because it has strong access control features. On UNIX it is not that easy so often an additional data base together with SAS is used. Before I present our solution I am going to discuss two general database security problems.

15 Database Security In a data base (SAS or others) the security problem is simple if all data is either sensitive or not (see appendix data-classification). The implementation takes best place in the operating system. More difficult is a solution if any data is sensitive and any not. It has to be differed between the inference problem on the attribute level and the multilevel database on the record level. Inference Problem A record may have sensitive attributes. If principally no unauthorised access is allowed on this attributes, the attributes can be protected with a higher security level in the database itself (if the database system offers this feature) or views can be defined containing just the uncritical attributes. But if statistics are also allowed on the sensitive attributes on a lower access right level, it is possible with adroit queries to draw the conclusion to a sensitive attribute. Today only two control mechanism are known: suppression and concealing. Suppression: Statistics are not reported or printed if they lay beyond a critical value, for example value zero and 1 or values under 10. Concealing: There are principally reported just approximate values. Approximate values can be a range (the values are between 100 and 200), rounded values (ex. rounded on 10), statistics on samples or a query-control engine. The last method is very costly, because the engine has to check each query against the previous reports and to find out whether conclusion to the sensitive attributes is possible or not. Mostly the inference problem is not implemented, because there exists no perfect solution. But it is important to know the risk. We have solved the problem on the organisation level: unauthorised persons have to let run their queries and statistics by authorised staff. The reports are checked and handed out, if there is no critical information on them. Multilevel Database If a database file contains sensitive and non sensitive records, there are various simple and complex methods to guarantee data security. The most important methods are the following: 1. The datafile is split up physically into a sensitive and a non sensitive part. The access control can be implemented easily in the operating system. 2. The sensitive records are stored encrypted. Only authorised staff who know the key have access on the data. The key management is an issue. 3. Trusted front-end with filters: a filter adds automatically security conditions to a query. Therefore each record has to contain information about the security level. 4. Different views can be created depending on the security level. Access on a view can be implemented in the operating system. In our data warehouse we have chosen the easiest solution and split up the database. The Implementation of the SAS Data Warehouse of Group Internal Audit We completely store the data in our data warehouse in SAS datasets. Because SAS does not have direct authorisation features, we had to implement our authorisation concept in the operating system. With OpenVMS we have chosen an operating system with robust authorisation features that can fulfil our security requests.

16 For each UBS-division and each region we have created an own disk-directory. The data is physically stored in the directory of the divisions (for example: FOREX in the division investment banking), but splitted up in a file per region. This makes sense because usually a product is audited just in one region, thus the unity of a product of all regions is rarely used. In order that the users of the regions can access the data, we have implemented hardlinks from the region directory to its physical, regional file in the division directory. The system s behaviour is like the region file would be stored in the region directory. Each of these files are assigned to the following access rights in the ACL (ACL=access control list): the role investment banking user, the role of the particular regional user and the role database manager. All users have read rights on the datafiles, but just the data manager role has read / write / delete access on the data. In this sense we have defined all roles and implemented it on the operating system in the ACL with identifiers.

17 Client/Server-Connection In a SAS Data warehouse the client/server connection is based on SAS/SHARE or SAS/CONNECT. I am going to analyse this two modules after their strengths and weaknesses under the view of data security. A client/server-connection should at least fulfil the following requests: 1. The password and username for connecting is transferred encryptedly. 2. The data may be transferred encryptedly from the server to the client, depending on the security level of the data. 3. No direct access to the operating system. 4. Regular password change. 5. High network traffic is to avoid. SAS/CONNECT as well as SAS/SHARE have positive and negative points concerning data security. This bases on SAS/CONNECT without a spawner program, which should probably give more security, because for OpenVMS there is no spawner available. SAS/SHARE : 1. Optionally username and password can be encrypted. 2. The data between server and client is transferred unencryptedly. 3. No direct access to the operating system, because a user account can be set as disuser on the operating system (no direct login). The authorisation takes place over the shareserver using the access control list of the operating system. 4. How the password can be changed is unclear. 5. Probably high network traffic, because the query starts from the client. SAS/CONNECT : 1. Username and password are transferred in clear text since SAS/CONNECT is put up on a hidden terminal based connection. 2. The data between server and client is transferred unencryptedly. 3. Because a user owns a login on the operating system level, he has direct access to the operating system. 4. The password can be changed. 5. The network traffic is minimal because the queries are fully executed on the remote server. Whether these disadvantages are obvious for a data warehouse project or not, has to be decided in the individual case as well as the measurements concluded from that. We have build in more security features on the client side (LAN) to guarantee the requested data security.

18 Final Remarks How many security measurements a project implements in a data warehouse is a question of weighing up the costs and risks. The minimisation of the risks can be quite cost-intensive. On the other side risks can be consciously accepted, because a possibly claim is acceptable. But it is important to know the risks. The greatest dangers are the unknown risks. They may cause grater claims to a company when coming true materialising. Appendix data-classification: An example for the data-classification: Class Description Protection Need Scope of Protection 0 generally accessible none generally accessible (in electronic form: protection against unauthorised changes) 1 for internal use normal access and viewing restricted to bank employees (within the scope of their business activities) no comprehensive analysis of customer relations or business activities possible 2 confidential elevated access and viewing restricted to the persons designated by the data owner customer relations or business activities cannot be inferred by unauthorised third parties 3 strictly confidential qualified additionally to class 2: access and viewing only for particular persons or groups of persons designated by the data owner 4 secret absolute additionally to class 3: access and viewing only for particular persons designated by the data owner Christina von Rotz Associate Director, IT Analyst UBS AG Group Internal Audit Bahnhofstrasse 45 P.O. Box, CH-8098 Zürch Tel: Fax: christina.von-rotz ubs.com

Risk. Systemystem. A SAS Datawarehouse on OpenVMS (AXP)

Risk. Systemystem. A SAS Datawarehouse on OpenVMS (AXP) Group Audit Department Project ICARUS Information Collecting Risk Andnd Uncovering Systemystem A Datawarehouse on OpenVMS (AXP) UBS Giampaolo Trenta Juni 98 / 1 The Group internal Audit department (GADE)