1. General

1.1. Preface

This manual provides an architectural and conceptual overview of SCURTY, the Security Framework for the Oracle Database. The Oracle Database Enterprise Edition offers a lot of excellent database security features that are rarely used because of their complexity in administration. SCURTY acts as an umbrella for these security features by providing functions that hide complexity from the user as well as from the administrator. SCURTY adds well-considered, comprehensive logic that simplifies security feature usage and that integrates seamless with the database. By this it enables an easy to use way to provide a highly sophisticated level of security.

1.2. About data

Defining security measures only makes sense if the whole picture is kept in mind. It is a common mistake to apply strict security measures in one area and to overlook some others. For a database this means to think about the target that should be met, before thinking about the details. It is important to settle the objective from a bird’s eye view before looking at the row- and column-level.

To get this distant view it is useful to look at the definitions of data and information:

Information is divided into pieces of facts like name, address or phone number and these pieces are stored as data. To make data useful it needs to be transformed back into information. This happens when data is processed, organized, structured or presented in a given context. For example an application presents a set of data and by that transforms this data into useful information. If the context is missing, e.g. the application shows only a phone number without the corresponding name, the data (and the application) is more or less useless.

Every organization has information that it must store and manage to run their business. Examples are records of customers, products and employees. The size of the organization often but not always predicts the size of information to be stored. If the organization consists of different departments or is distributed over several locations access to a common central data store might be essential. And on the other hand, if the information to be stored and managed grows above a certain level a database system provides the most efficient access. These are the main reasons for the popularity of database systems and they provide a good set of security measures that can be applied.

1.3. Data protection

The more information is stored in one place the more this place needs to be protected. The reasons data needs to be protected are manifold, some of them are:

  • Data theft or destruction may halt the business

  • Business secrets and personal data should only be accessible by people that need it

  • Manipulation of data e.g. in industrial plants, whole sale, retail or banking areas must be restricted to authorized personnel only, otherwise machines might be damaged or the business may get out of control.

All database systems on the market allow to protect data more or less efficient. The Oracle Database is clearly at the more efficient end, especially Oracle Database Enterprise Edition which includes security relevant features that are not present in Oracle Database Standard Edition. The Oracle Database provides a rich set of security functions that can be used to protect data in different ways and from different attack vectors. Each function provides protection for a specific aspect, e.g. password protection of user accounts protects from unauthorized access to the database system. There is no single security feature or function that makes a database secure in all respects. A reasonable combination of well configured security functions are able to protect data in different situations.

Information stored in a database is used by different database applications. Each application can be accessed by a set of people called users. Some users may have access to several or all applications and some only to one or a few of them. The information accessible in an application is not necessarily the same for all users. In contrary, most often it is well defined who should see or modify which information. And in fact regulations and laws like GDPR (General Data Protection Regulation) and data privacy acts require this explicitly, at least for personal data: “Personal data shall be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures (‘integrity and confidentiality’).” (GPDR Art. 5(1)f)

All of the above sounds logical. So, why is security not in place everywhere? Why is access to systems and data often possible with unbelievable low controls? Because normally it is time-consuming and expensive to implement security and even more time-consuming and expensive to do ongoing administration of this security. This is the point where SCURTY shows its full strengths: it radically lowers the effort needed to implement and run security in an Oracle Database. It does not add new security features to the database, these features are already there, waiting to be used. SCURTY combines all the features in a sensible way and reduces the effort needed to an absolute minimum. This is achieved by automating creation and maintenance of user accounts, database roles, security policies and much more. SCURTY is the interface between users that know the requirements and the excellent security features in the database. No one else and nothing else is involved. Users do not need to know technical details, they only have to tell SCURTY what they need. SCURTY then runs processes in the background that create, modify or remove the corresponding database objects.

1.4. About security requirements

Lots of different threats exist that use different approaches to get access to data. These different approaches are called attack vectors. This is the reason why different security features exist in the Oracle Database. Each of the features covers one or more attack vectors. And it’s also the reason why it is not possible to use some security features and to “be safe” afterwards. The features to be used depend on the requirements.

It is important to reflect on the current situation on the one hand and on the requirements on the other hand. It is not possible and not reasonable to implement top level security in every place. But it is important to know about strengths, weaknesses and potential solutions for the systems in place. With this knowledge a decision has to be made that is always a compromise between security on the one hand and ease of use as well as cost on the other hand.

The following examples may provide a starting point for these considerations:

  • Is the data sensitive?

    If data in a database is made available to public (like the menu of a restaurant, or in general data displayed on a public website) there is no need to further restrict read access. But for sure it is different with write access to the same data. Another example is if the data contains business critical information or information related to human beings. This data most often requires well-considered access rights on a fine grained level. Fine grained means it might not be sufficient to restrict access on a table level. It could be reasonable to restrict access on table rows and/or columns depending on the person or business function requiring access.

  • Is the database running on a highly protected system or does the server provide a moderate security level only?

    Protection in this context could mean physical (from stealing the disk or the box), from a network perspective and/or from the operating system used. Physical protection is done by controlling physical access to the machine. Network protection is manifold and it is often not easy to tell the exact security level. Security from the operating system (OS) means if it is regularly patched, if it is maybe a hardened (more secure) version or if the OS user accounts are managed strictly.

    To protect a database running on a server with only moderate security, for example stronger authentication methods might be useful. This could start by using database user profiles and go all the way to third party authentication services and certificate-based authentication.

    Regardless of the protection level of the system, it is nearly always advisable to encrypt data at rest. This protects from subsequent damage from stealing the hardware (disks, the whole server or backup mediums) and from stealing the files (database files, backup files) e.g. over the network. Encryption is an Oracle Database feature that can be implemented without lots of effort.

  • Should different groups of users see different data?

    The answer to this question is most often “yes”. Several mechanisms exist in the Oracle Database to achieve selective access rights, but only some of these mechanisms are broadly used. With SCURTY all the mechanisms are involved without adding the usual overhead.

  • What is the cost if data is damaged or stolen?

    There is no exact answer to this question but it makes sense to at least think about the threat severity. Trade secrets, financial or personal data are examples for potentially high threat severity.

This small set of examples just gives an idea about the considerations that should be involved when establishing a level of security for a system. The result should be a target level of security that is acceptable for the kind of system. The cost-value ratio then defines which measures to take. Unfortunately there exists no absolute security. Each security measure lowers the probability of an incident. To do nothing is not a good idea in this area.