UNIT 5: Access Control and Encryption

DATABASE ACCESS CONTROL

Database access control is a method of allowing access to company’s sensitive data only to
those people (database users) who are allowed to access such data and to restrict access to
unauthorized persons. It includes two main components: authentication and authorization

Authentication
Authentication is a method of verifying the identity of a person who is accessing your
database. Note that authentication isn’t enough to protect data. An additional layer of security
is required

Authorization
Authorization, which determines whether a user should be allowed to access the data or make
the transaction he’s attempting. Without authentication and authorization, there is no data
security.

Any company whose employees connect to the Internet, thus, every company today, needs
some level of access control implemented.
Database Access Control
There are two basic SQL commands for implementing database access control.
Grant
The SQL command for granting privileges has the following syntax.

GRANT { privileges | role }

[ON TABLE]
TO { user | role | public }
[IDENTIFIED BY password]
[WITH GRANT OPTION]

The first line of the command describes what we would like to grant. We can grant either
privileges - like SELECT - or an entire role, such as admin.
We can optionally scope our grant to a specific table.
Our grant must have a recipient, be it a particular user, role, or public. Public refers to the
entirety of users/roles that interact with the database.
We can optionally require users to identify themselves using a certain password if they wish
to revoke this grant.
Finally, we can optionally allow the grantee to further propagate their access with the WITH
GRANT OPTION clause.
For example, if we would like to grant Alice the ability to perform a SELECT on any table,
and propagate that access to others, we could issue the following command:

GRANT SELECT ON ANY TABLE TO Alice WITH GRANT OPTION;

Alternatively, we could grant access for INSERT , UPDATE and/or DELETE .

Revoke
The SQL command for revoking privileges has the following syntax.

REVOKE { privileges | role }

[ON TABLE]
FROM { user | role | public }

The first line of the command describes the privilege or role that we would like to revoke.
We can optionally scope our revocation to a specific table.
Finally, we must revoke access from a particular entity. This entity can be a user, role, or the
general public.
For example, to revoke the access we just gave to Alice, we issue the following command:

REVOKE SELECT ON ANY TABLE FROM Alice

Types of Access Control

 Discretionary Access Control (DAC)

 Mandatory Access Control (MAC)
 Role Based Access Control (RBAC)
 Attribute Based Access Control (ABAC)

Discretionary Access Control (DAC)

A discretionary access control system is a system in which a user with access to a certain
level of data can give access to the same level of data to someone else based on their
judgement and choice.
The first access-control list (ACL) is made by the administration but any access granted to
someone by someone already on the list is hard to monitor. Although the list can be checked,
revised, and updated anytime by the administration.
This process makes the flow of data much easier and a lot more user-friendly than any other
system. But, contrary to the flexibility it offers, this system is also less secure as the flow of
information can’t be administered regularly.

Due to the less secure passage, this system offers a flow of information, which makes it unfit
for organizations that require high-level security of their data such as in fields like - medical,
finance, military, government offices, etc.

As in any other system in this system also whether to give access to data or not to an
employee is decided by administration only. An important point worth mentioning here again
is that once the access is granted to a user only then they can give access to someone else, but
they cannot give access to any of the data to which they do not have access.

Uses:

 In organizations where a high-level security system is not needed

 In startups & small businesses
 In schools, coaching, centers

Advantages:

 User Friendly: Managing data and permissions is easier with DAC. The user interface
is very easy to operate thus no need to go through the pain of planning it all out at
once.
 Flexible: While working, often a need to share data with co-workers comes up. DAC
system allows any user with access to certain information to grant access to others as
well, hence making the working process smooth.
 Less Headache for Administration: DAC doesn’t require regular maintenance does
not take much time. Sharing of data is much easier as the administration does not need
to interfere whenever a piece of information is needed to be shared with a user.
Disadvantages:

 Less Secure System:- As access can be given from one person to another, data is not
very well secured under DAC. Thus, it is not much feasible for the administration to
overview ACL now and then, which may lead to leakage of information to someone
outside the organization.
 Hard to keep track of data:- As the DAC system is not centralized, the only way
administration can monitor data flow is by going through ACL. Thich is only
convenient in the case of a small organization where employees are fewer.

Conclusion:
As the DAC system is not much secure or one could say least secure among role, mandatory
and discretionary systems, it is not advisable to use where very confidential data is needed to
be protected. But its working flexibility makes it favorable for small organizations or offices
where the number of total employees is around 30-50.
Mandatory Access Control System (MAC)

Mandatory Access Control (MAC) is a system to allow or deny access to private information
in an organization. What makes MAC different from other system is that it works on a
hierarchy pattern. Under this system, the whole team force must be divided into categories
according to their roles and responsibility and according to the information they must be
allowed to see. To make that happen the administration needs to put a lot of efforts at the
time of planning the information flow properly. It would be only a one-time effort to set
things up in order, after that it would only require updates as per change in the position/role.

Under MAC, the access flows in a way that an employee with access to higher-level data will
also have access to the data available to their lower-level ranks. If we put it in simple words,
it like a flow chart of information and the person in middle will have access to ground level
data but not any level further up.

Often at workplaces where MAC system is to be used, categorizing the information flow in
different categories like - ground level, confidential, secret and top-secret is suggested. Every
system that an individual might be using would have been given prior access as per the
requirements.

Uses:

 MAC has a wide range of usage in different sectors which requires a system that can
secure confidential data without any constant supervision.
Majorly used in sectors like - government offices, military, health care, financial,
engineering projects, etc.

Advantages:
 High-level data protection (most secure system among role, mandatory and
discretionary system): With MAC, one can be sure that their most confidential data is
well protected and leaves no room for any leakage.
 Centralized Information: Once data is set in a category it cannot be de-categorized by
anyone other than the head administrator. This makes the whole system centralized
and under the control of only one authority.
 Privacy: Data is set manually by an administrator. No one other than admin can make
changes in category or list of users' accesses to any category. It can be updated only
by admin.

Disadvantages:

 Careful Setting-Up Process: MAC must be set up with good care otherwise it will
make working chaotic. It is because sometimes a piece of information needs to be
shared among co-workers in the same organization but MAC restricts anyone to do
so.
 Regular Update Required: It requires regular updating when new data is added or old
data is deleted. The administration is required to put some consideration into the
MAC system and ACL list now and then.
 Lack of Flexibility: MAC system is not operationally flexible. It is not an easy task to
initially input all data and create an ACL that won’t create any trouble later.
Conclusion:

MAC is the most secure system due to which it is recommended in offices where highly
confidential data is needed to be protected and not in any private offices where a less secure
system would be enough.

Role-Based Access Control (RBAC)

Role-based Access Control Management is a system through which a company’s
management can control access or restrict certain area or information depending upon the
position of the employee in a company or his/her work profile.
Under this form of access control management an employees’ position in the company
determines which information must be shared with them.
Since some information must be kept only to senior management and in certain specific
sectors like health care organization, financial institutions, the management also have to
restrict entrance to data rooms, vaults, locker room, meeting rooms etc. as such access must
be allowed to certain people only.
Roles may be categorized according to tasks they need to carry out, like: -
Technical – access to only the technical team
Administrative – administration concerned only
Security – access to only persons responsible.

Uses:

 Bank or financial sector – vaults, locker rooms and data rooms must be well protected
to ensure safety
 Storage rooms in hotels, hostels, offices, & warehouses
 Commercial/Residential Apartments – To allow entry of only known individuals, thus
ensuring the safety of people living in the society.
 Ease for Visitors – in offices or even in apartments, with RBAC, it is much easier and
faster to just enter OTP for entrance.

Advantages:

 Improves Work Efficiency: Using RBAC makes it much easier for office
management to change access according to change in the role of office staff. This is
much more convenient to do rather than administering every entry and exit and
approving every time.
 Security Against any Inside Information Leak: As the access to certain information or
room will only be given to a certain set of people responsible and trusted, it reduces
any type of leakage of confidential information or even entry of any unwanted
individual.
 Time-Saving: Under RBAC Management, one would only require a card or password
(according to system functionality) to get access to any information/room. This is
contrary to prior methods wherein security officials use to ask and confirm ones’
credentials and then that person would be allowed to enter after everything seems
fine, which is very time-consuming.
 Helps to Keep Record: RBAC system not only just ensures safety but, also records
data of entries and exits which makes it easy to analyze work hours as well.

Disadvantages:

 Complex For Large-Scale Organization: In a large organization, thousands of

employees work in different roles. Managing access for a large number of employees
is difficult with RBAC.
 Management Limited to Role: Under RBAC management, restrictions can be fixed
based only on the role of individuals and not the operations performed by them.
Conclusion:
Implementing RBAC in an organization requires detailed analysis and consideration before
the final implementation. Once this analysis is done, setting up of RBAC system can become
a simpler process.
With RBAC, organizations can ensure the safety of specific areas and information up-to a
great extent. In modern organizations, RBAC is a proven way to manage safety requirements
at the workplace.

ATTRIBUTE-BASED ACCESS CONTROL (ABAC)

Attribute-Based Access Control (ABAC) - advanced authorization model using attributes
over roles for precise application security and access control
When building an application, there is one crucial thing we have to make sure of:
The right people have the right access to the right assets. This is what authorization is all
about.
While Role Based Access Control (RBAC) determines access based on predefined roles
(Like Admin, Editor, and Viewer, for example), Attribute Based Access Control (ABAC)
deals with, you guessed it - attributes.
ABAC determines access based on conditions applied to attributes (or characteristics) rather
than roles, allowing the definition of fine-grained complex access-control rules.
The use of ABAC aligns with the growing complexity and diversity of modern applications,
where conventional access control methods fail to address intricate, ever-changing security
requirements.

Why Attribute-Based Access Control?

Unlike traditional models, ABAC can adapt to complex, distributed environments, making it
ideal for applications requiring high customization and contextual sensitivity in access
decisions. It thrives in scenarios where user roles are insufficient to capture the full spectrum
of access needs, offering a tailored and robust solution.

Components of ABAC:

 Subject Attributes: These encompass user-related characteristics, including roles,

departments, and security clearances. They form the backbone of the user identity
within the ABAC framework, providing a detailed profile that guides access
decisions.
 Resource Attributes: These relate to the assets or objects (files, applications, APIs)
being accessed. Attributes like file type, sensitivity level, and ownership are crucial in
defining the nature of the resource in the access control equation.
 Action Attributes: These define the nature of a user's interaction with a resource.
Actions usually describe the type of action performed (Like read, write, edit, or
delete) and can be paired with action attributes, such as “frequency” (For example - a
limit on how many times an action can be performed).
 Environmental Attributes: These capture the broader context of the access request,
including time, location, and device used. This dimension adds a dynamic aspect to
ABAC, allowing policies to adapt to changing contexts.
 The ABAC framework integrates these components to create a rich, multi-
dimensional approach to access control, enabling precise and adaptable policies for
varying scenarios.

Benefits of ABAC:

 Granularity: ABAC enables highly precise policy-making by considering a wide

range of factors when making a decision. This granularity extends way beyond basic
role-based controls, allowing for specific, context-driven access decisions.
 Flexibility: Policies in ABAC can be dynamically adjusted to changing
organizational needs. Consider a multinational corporation that needs to adjust access
rights based on varying data protection laws in different countries. ABAC policies can
be quickly adapted to comply with these legal variations without completely
overhauling the access control system.
 Scalability: ABAC efficiently manages increasing volumes of users and resources. In
a rapidly growing tech company, for instance, as new employees join and new
projects are initiated, ABAC can seamlessly scale to accommodate these changes
without needing constant policy reconfiguration.
 Enhanced Security and Compliance: ABAC's detailed access control significantly
improves security. In a financial institution, ABAC can restrict access to sensitive
financial records based on a combination of user role, location, and transaction
context, thereby reducing the risk of data breaches and ensuring compliance with
financial regulations.
 Reduced Administrative Overhead: ABAC minimizes manual intervention by
automating access decisions based on attributes. In a university setting, for instance,
access to academic records can be automatically adjusted based on a student’s
enrollment status, course registration, and academic role, thus reducing the
administrative burden on IT staff.
 Each of these benefits illustrates how ABAC's nuanced approach to access control can
be practically applied across various sectors, showcasing its versatility and
effectiveness in addressing complex security challenges.

Challenges of ABAC:

Adopting Attribute-Based Access Control (ABAC) offers many benefits, but it's essential to
be aware of its challenges:
 Complex Implementation: Establishing ABAC requires defining a broad set of
attributes across users and resources. This complexity can be particularly challenging
for smaller organizations with limited technical resources, as it demands a deep
understanding of the operational and security dynamics. This complexity can be
alleviated by using best practices such as decoupling policy and code.
 Intricate Policy Management: ABAC involves creating detailed, context-specific
policies, which can be numerous and intricate. This complexity necessitates
meticulous management to ensure policies remain relevant and effective as the
organization's needs evolve. These policies can be managed by creating or adopting a
policy management solution.
 Performance Overhead: ABAC's detailed attribute evaluation process can impact
system performance. In scenarios requiring rapid access decisions or in large-scale
deployments, the resource intensity of processing multiple attributes and complex
policies can lead to latency issues.
 Risk of Policy Conflicts: Given the granular nature of ABAC policies, there's a
potential for conflicting rules, especially when numerous attributes and conditions are
involved. Resolving these conflicts requires careful policy design and regular reviews
to maintain consistency and clarity in access control decisions.
 Data synchronization: Applications often rely on data sources (Internal or external)
to aid in the decision-making process (Think of limiting access based on payment
status - information that is contained and managed in Stripe). Getting all the relevant
attribute data into your decision point in time can pose quite a challenge
(Though tools like OPAL can alleviate it).
 Effectively addressing these challenges is crucial for organizations to harness the full
potential of ABAC, ensuring a robust, flexible, and efficient access control system.

SQL BASED ACCESS DEFINITION

The Access Definition governs the overall Extract Process. An Access Definition specifies
the tables, relationship traversal, and selection criteria for the data you want to extract. It also
provides parameters for Actions – user-defined SQL statements executed at predefined points
in an Extract or Insert Process. You can select a named Access Definition or create a new
Access Definition for a single Extract Request.

The Access Definition enables you to:

Specify the set of tables to be included in the Extract Process. You can specify the name of a
single table and request that Move provide the names of all related tables. One table is
identified as the Start Table, or table from which data is first extracted.
Select relationships to be traversed to extract the data. Move has default rules for how
relationships are traversed between the specified tables. You can select from a list of all of
the relationships defined to the database and to the Optim™ Directory. (The relationships
contained in the Directory supplement the relationships contained in the database.)
Define criteria for the rows to be extracted by specifying:

Selection criteria for any selected table using SQL syntax:

 A selection of rows chosen while browsing the data (Point and Shoot).
 A sampling of rows, accomplished by extracting every nth row.
 A maximum number of rows for a single table.
 A maximum number of children per parent.
 Grouping (e.g., extract 20 customers from each of the 50 states).
 Establish Actions to be executed when data is extracted or inserted.
 Ensure that the desired data is extracted using the Show Steps function to review how
Move will traverse the database.

Role-Based Access Control (RBAC)

Role-based Access Control Management is a system through which a company’s
management can control access or restrict certain area or information depending upon the
position of the employee in a company or his/her work profile.
Under this form of access control management an employees’ position in the company
determines which information must be shared with them.
Since some information must be kept only to senior management and in certain specific
sectors like health care organization, financial institutions, the management also have to
restrict entrance to data rooms, vaults, locker room, meeting rooms etc. as such access must
be allowed to certain people only.
INFERENCE

 Inference is a database system technique used to attack databases where malicious

users infer sensitive information from complex databases at a high level. In basic
terms, inference is a data mining technique used to find information hidden from
normal users.
 An inference attack may endanger the integrity of an entire database. The more
complex the database is, the greater the security implemented in association with it
should be. If inference problems are not solved efficiently, sensitive information may
be leaked to outsiders.
 Two inference vulnerabilities that appear in databases are data association and data
aggregation. When two values taken together are classified at a higher level than one
of every value involved, this becomes a data association. When a set of information is
classified at a higher level than the individual level of data, it is a clear case of data
aggregation. The sensitive data leaked through inference involves bound data, where
an attacker finds out a range of data holding expected data or negative data, which is
obtained as a result of certain innocent queries. An attacker might try to access
sensitive information through a direct attack, indirect attack or tracking.
 A wide variety of inference channels have been discovered in databases. One way of
inference is querying the database based on sensitive information. In this method, the
user queries the database sequentially and from the series of outputs received, infers
patterns in the database and information lurking behind the usual displayed data. A
series of queries by a normal user may reveal some information that can easily be
guessed. Statistical data may also fall prey to inference. In a statistical database,
aggregate statistics on a group of people are made public, while individual
information is hidden. The threat against statistical database security is that queries
can be shelled out on aggregate statistics over a period of time and arithmetic
operations may be performed that enable the attackers to hack individual member
information.
 Inference detection can be achieved through the semantic inference model, security
violation detection and knowledge acquisition. The semantic inference model
combines dependency, data schema and semantic knowledge. It represents all possible
relations between attributes of data sources. Security violation detection combines a
request log with a new query request and checks if the request is allowed as per the
pre-specified set of instructions. Based on the analysis, it decides whether the query
has to be answered.

What is an Inference Attack?

 When a user can get confidential information, without directly accessing it,that is an
inference attack. This information is sensitive and is above the reach of common
users. This kind of data mining takes place to have information about trade secrets,
without access to files. The inference attack helps the hacker to get some information
that is usually predicted, leaked, or analyzed but is authentic.

 Database security: People today know how important it is to maintain a healthy

database. The database acts as the backbone of your system and needs security
measures. Here’s how you can keep a check on your database .This means that your
database must provide you with information. All hardware and software supporting it
must be up to date.
 Integrity: A system must be robust to cater to unauthorized access. It must prevent
unsanctioned alterations.
 Confidentiality: There must be barriers to unauthorized data disclosure With this,
more layers help to elevate database security. Manual privacy control, encryption
authentication, network accessibility, auditing, and backups must be checked and
controlled all the time. Even after a rigid data security plan, there is a chance for
intrusion from social engineering and inference channels.
 Inference control: Although inference cannot be fully prevented, there are some
ways to control and manage the issue. These methods are performed by professionals
and are divided into three sub-disciplines.
 Micro data protection: The goal of this technique is to create micro data tables,
which are different from the original tables. This makes differential information and
confidential information remain hidden. Companies hire professionals to mask the
original data or create synthetic unauthentic data in this technique.
 Tabular data protection: This technique is used by the government and other
agencies to hide information. They use or present data with average values and
median ranges.
 Queryable data protection: The approach in this technique is to hide the numeric
data and replace it with qualitative data based on queries generated by asking a
question that is open-ended and needs the effort to resolve.
 All these techniques must be chosen secretly for better security against inference, only
the team designed for the purpose must know the exact database techniques to combat
inference. A proactive approach can also be exercised, which means designing a
framework of privacy at the inception of data collection to prevent future problems.

Rising Inference problem:

 With a rise in technology and specialization, many prevention techniques help to

control inference but, this has also left us with loopholes that can get us in trouble too.
Companies handle and manage their database.
 But, sometimes due to large data packs, some companies outsource the data to
security agencies. This usually raises eyebrows about the integrity and safety of data.
Encryption techniques can be used to counter the problem, but that will still leave
certain flaws.
 Consequently, XML (extensible markup language) is now used for encoding the data.
Although the technology was introduced for better database security, many cases of
its inference attacks and indirect access to XML structures have been reported in
recent days.
 With the development of the semantic web, data is automatically structured in a way
to welcome inference and no manual intruders are needed for that. So, when dealing
with inference control one needs to understand that machine-related attacks cannot
diminish completely, but only be managed.

Can a VPN help prevent Inference attacks?

A VPN is a tool that is designed to encrypt your data safely. A reliable VPN can provide you
with enhanced security against data breaches and can be used as an added tool to prevent
inference attacks.
PureVPN with AES-256-bit encryption initiates a secure connection and ensures your data is
transmitted securely. Although a VPN will not help once the inference attack has happened as
inference is not completely controlled and the only way to combat is to add security for the
database.

Conclusion:

In recent years, its database has become vulnerable to breaches. This is because technology
has not only benefited us but also left some options for the ones who enjoy cyber thefts.
Inference attacks are usually ignored because when discussing security, the main focus is
always the physical control and hindering of direct access. We ignore indirect access threats
to our database. So, be wary of rising mechanics and minds that affect our privacy indirectly.

What is Inference in cybersecurity?

The inference is the data mining technique that is used to infer sensitive information through
indirect access.

What is the Inference problem?

The inference problem occurs when sensitive information is disclosed from the database.

What is an attribute Inference attack?

In an attribute inference attack, the hacker has some data about training outcomes and results
of individuals and based on that they can manipulate sensitive data

Database encryption

Database encryption can generally be defined as a process that uses an algorithm to

transform data stored in a database into "cipher text" that is incomprehensible
without first being decrypted. It can therefore be said that the purpose of
database encryption is to protect the data stored in a database from being accessed
by individuals with potentially "malicious" intentions. The act of encrypting a
database also reduces the incentive for individuals to hack the aforementioned
database as "meaningless" encrypted data adds extra steps for hackers to retrieve
the data. There are multiple techniques and technologies available for database
encryption, the most important of which will be detailed in this article.

Transparent/External database encryption

Transparent data encryption (often abbreviated as TDE) is used to encrypt an entire
database, which therefore involves encrypting "data at rest" .Data at rest can
generally be defined as "inactive" data that is not currently being edited or pushed
across a network. As an example, a text file stored on a computer is "at rest" until it
is opened and edited. Data at rest are stored on physical storage media solutions
such as tapes or hard disk drives.[6] The act of storing large amounts of sensitive
data on physical storage media naturally raises concerns of security and theft. TDE
ensures that the data on physical storage media cannot be read by malicious
individuals that may have the intention to steal them. Data that cannot be read is
worthless, thus reducing the incentive for theft. Perhaps the most important strength
that is attributed to TDE is its transparency. Given that TDE encrypts all data it can
be said that no applications need to be altered in order for TDE to run correctly. It is
important to note that TDE encrypts the entirety of the database as well as backups
of the database. The transparent element of TDE has to do with the fact that TDE
encrypts on "the page level", which essentially means that data is encrypted when
stored and decrypted when it is called into the system's memory. The contents of the
database are encrypted using a symmetric key that is often referred to as a
"database encryption key”.

Column-level encryption
In order to explain column-level encryption it is important to outline basic database
structure. A typical relational database is divided into tables that are divided
into columns that each have rows of data. Whilst TDE usually encrypts an entire
database, column-level encryption allows for individual columns within a database to
be encrypted. It is important to establish that the granularity of column-level
encryption causes specific strengths and weaknesses to arise when compared to
encrypting an entire database. Firstly, the ability to encrypt individual columns allows
for column-level encryption to be significantly more flexible when compared to
encryption systems that encrypt an entire database such as TDE. Secondly, it is
possible to use an entirely unique and separate encryption key for each column
within a database. This effectively increases the difficulty of generating rainbow
tables which thus implies that the data stored within each column is less likely to be
lost or leaked. The main disadvantage associated with column-level database
encryption is speed, or a loss thereof. Encrypting separate columns with different
unique keys in the same database can cause database performance to decrease,
and additionally also decreases the speed at which the contents of the database can
be indexed or searched.

Field-level encryption
Experimental work is being done on providing database operations (like searching or
arithmetical operations) on encrypted fields without the need to decrypt them. Strong
encryption is required to be randomized - a different result must be generated each
time. This is known as probabilistic encryption. Field-level encryption is weaker than
randomized encryption, but it allows users to test for equality without decrypting the
data.

Encrypting file system (EFS)

It is important to note that traditional database encryption techniques normally

encrypt and decrypt the contents of a database. Databases are managed by
"Database Management Systems" (DBMS) that run on top of an existing operating
system (OS). This raises a potential security concern, as an encrypted database
may be running on an accessible and potentially vulnerable operating system. EFS
can encrypt data that is not part of a database system, which implies that the scope
of encryption for EFS is much wider when compared to a system such as TDE that is
only capable of encrypting database files. Whilst EFS does widen the scope of
encryption, it also decreases database performance and can cause administration
issues as system administrators require operating system access to use EFS. Due to
the issues concerning performance, EFS is not typically used in databasing
applications that require frequent database input and output. In order to offset the
performance issues it is often recommended that EFS systems be used in
environments with few users.

Full disk encryption

Symmetric and asymmetric database encryption

A visual demonstration of symmetric encryption

Symmetric database encryption

Symmetric encryption in the context of database encryption involves a private key
being applied to data that is stored and called from a database. This private key
alters the data in a way that causes it to be unreadable without first being
decrypted. Data is encrypted when saved, and decrypted when opened given that
the user knows the private key. Thus if the data is to be shared through a database
the receiving individual must have a copy of the secret key used by the sender in
order to decrypt and view the data. A clear disadvantage related to symmetric
encryption is that sensitive data can be leaked if the private key is spread to
individuals that should not have access to the data. However, given that only one
key is involved in the encryption process it can generally be said that speed is an
advantage of symmetric encryption.

Asymmetric database encryption

Asymmetric encryption expands on symmetric encryption by incorporating two
different types of keys into the encryption method: private and public keys. A public
key can be accessed by anyone and is unique to one user whereas a private key is a
secret key that is unique to and only known by one user. In most scenarios the public
key is the encryption key whereas the private key is the decryption key. As an
example, if individual A would like to send a message to individual B using
asymmetric encryption, he would encrypt the message using Individual B's public
key and then send the encrypted version. Individual B would then be able to decrypt
the message using his private key. Individual C would not be able to decrypt
Individual A's message, as Individual C's private key is not the same as Individual
B's private key. Asymmetric encryption is often described as being more secure in
comparison to symmetric database encryption given that private keys do not need to
be shared as two separate keys handle encryption and decryption processes. For
performance reasons, asymmetric encryption is used in Key management rather
than to encrypt the data which is usually done with symmetric encryption.

Key management

The Symmetric & Asymmetric Database Encryption section introduced the concept
of public and private keys with basic examples in which users exchange keys. The
act of exchanging keys becomes impractical from a logistical point of view, when
many different individuals need to communicate with each-other. In database
encryption the system handles the storage and exchange of keys. This process is
called key management. If encryption keys are not managed and stored properly,
highly sensitive data may be leaked. Additionally, if a key management system
deletes or loses a key, the information that was encrypted via said key is essentially
rendered "lost" as well. The complexity of key management logistics is also a topic
that needs to be taken into consideration. As the number of application that a firm
uses increases, the number of keys that need to be stored and managed increases
as well. Thus it is necessary to establish a way in which keys from all applications
can be managed through a single channel, which is also known as enterprise key
management. Enterprise Key Management Solutions are sold by a great number of
suppliers in the technology industry. These systems essentially provide a centralised
key management solution that allows administrators to manage all keys in a system
through one hub. Thus it can be said that the introduction of enterprise key
management solutions has the potential to lessen the risks associated with key
management in the context of database encryption, as well as to reduce the
logistical troubles that arise when many individuals attempt to manually share keys.

Hashing
Hashing is used in database systems as a method to protect sensitive data such as
passwords; however it is also used to improve the efficiency of database
referencing. Inputted data is manipulated by a hashing algorithm. The hashing
algorithm converts the inputted data into a string of fixed length that can then be
stored in a database. Hashing systems have two crucially important characteristics
that will now be outlined. Firstly, hashes are "unique and repeatable". As an
example, running the word "cat" through the same hashing algorithm multiple times
will always yield the same hash, however it is extremely difficult to find a word that
will return the same hash that "cat" does. Secondly, hashing algorithms are not
reversible. To relate this back to the example provided above, it would be nearly
impossible to convert the output of the hashing algorithm back to the original input,
which was "cat".In the context of database encryption, hashing is often used in
password systems. When a user first creates their password it is run through a
hashing algorithm and saved as a hash. When the user logs back into the website,
the password that they enter is run through the hashing algorithm and is then
compared to the stored hash. Given the fact that hashes are unique, if both hashes
match then it is said that the user inputted the correct password. One example of a
popular hash function is SHA (Secure Hash Algorithm) 256.

Salting
One issue that arises when using hashing for password management in the context of
database encryption is the fact that a malicious user couldpotentially use an Input to
Hash table rainbow table for the specific hashing algorithm that the system uses. This
would effectively allow the individual to decrypt the hash and thus have access to
stored passwords. A solution for this issue is to 'salt' the hash. Salting is the process
of encrypting more than just the password in a database. The more information that is
added to a string that is to be hashed, the more difficult it becomes to collate rainbow
tables. As an example, a system may combine a user's email and password into a
single hash. This increase in the complexity of a hash means that it is far more difficult
and thus less likely for rainbow tables to be generated. This naturally implies that the
threat of sensitive data loss is minimised through salting hashes.

Pepper
Some systems incorporate a "pepper" in addition to salts in their hashing systems.
Pepper systems are controversial, however it is still necessary to explain their use. A
pepper is a value that is added to a hashed password that has been salted. This
pepper is often unique to one website or service, and it is important to note that the
same pepper is usually added to all passwords saved in a database. In theory the
inclusion of peppers in password hashing systems has the potential to decrease the
risk of rainbow (Input: Hash) tables, given the system-level specificity of peppers,
however the real world benefits of pepper implementation are highly disputed.

Application-level encryption
In application-level encryption, the process of encrypting data is completed by the
application that has been used to generate or modify the data that is to be encrypted.
Essentially this means that data is encrypted before it is written to the database. This
unique approach to encryption allows for the encryption process to be tailored to
each user based on the information (such as entitlements or roles) that the
application knows about its users.
According to Eugene Pilyankevich, "Application-level encryption is becoming a good
practice for systems with increased security requirements, with a general drift toward
perimeter-less and more exposed cloud systems”.

Advantages of application-level encryption

 One of the most important advantages of application-level encryption is the
fact that application-level encryption has the potential to simplify the
encryption process used by a company. If an application encrypts the data
that it writes/modifies from a database then a secondary encryption tool will
not need to be integrated into the system. The second main advantage relates
to the overarching theme of theft. Given that data is encrypted before it is
written to the server, a hacker would need to have access to the database
contents as well as the applications that were used to encrypt and decrypt the
contents of the database in order to decrypt sensitive data.

Disadvantages of application-level encryption
 The first important disadvantage of Application-level encryption is that
applications used by a firm will need to be modified to encrypt data
themselves. This has the potential to consume a significant amount of time
and other resources. Given the nature of opportunity cost firms may not
believe that application-level encryption is worth the investment. In addition,
application-level encryption may have a limiting effect on database
performance. If all data on a database is encrypted by a multitude of different
applications then it becomes impossible to index or search data on the
database. To ground this in reality in the form of a basic example: it would be
impossible to construct a glossary in a single language for a book that was
written in 30 languages. Lastly the complexity of key management increases,
as multiple different applications need to have the authority and access to
encrypt data and write it to the database.

Risks of database encryption

 When discussing the topic of database encryption it is imperative to be aware
of the risks that are involved in the process. The first set of risks are related to
key management. If private keys are not managed in an "isolated system",
system administrators with malicious intentions may have the ability to decrypt
sensitive data using keys that they have access to. The fundamental principle
of keys also gives rise to a potentially devastating risk: if keys are lost then the
encrypted data is essentially lost as well, as decryption without keys is almost
impossible.