2. Database Security
Database Confidentiality, Integrity, and Availability
(CIA components)
C: Protecting the information from disclosure to unauthorized
parties
Data encryption, SSL, permissions, access control
I: Protecting information from being tampered by
unauthorized parties
Message hash, sign
A: Ensuring that authorized parties are able to access the
information when needed
DDOS – back up
3. Confidentiality
Flaws of data Confidentiality
• Data is stored in an unsecured manner
• Lack of compliance with Corporate Data Privacy Policy
• Transfer of unsecured data to various vendors
• Lack of control of data usage and access
• Leak of personally identifiable data and health
data, etc.
4. Data Encryption
• Data encryption for Confidentiality
• Only authorized users can read the data with
granted keys.
• Encryption prevents unauthorized users from
reading encrypted data and prevents data leakage
• Popular Encryption algorithms: Data Encryption
Standards (DES) and Advanced Encryption Standards
(AES).
5. Intrusion Detection and Prevention
• SQL injection detection for SQL database
Input validation
Query parameterized statement vs. query string
• JSON (JavaScript Object Notation) injection detection
for NoSQL database
• Bad access command/statement detection
• Data leakage detection
6. Policy & Procedure
• Plan and Guidance
• Role and responsibility
• Classification of data: data and information is classified
into different levels of confidentiality to ensure that only
authorized users access the information.
• Least privilege policy
• User administration
• Password policy
• DB application security
• Auditing
7. Integrity
• Data and information is accurate and protected from
tampering by unauthorized persons.
• Data and information is consistent and validated.
8. Permission and Access Controls
• Enforce User Access Controls (UAC) that define
user/group access control privileges and permission
to specific database, tables, columns and associated
operations
• Once the database is installed, the password to
database must be secured and not compromised.
Periodic password checks and modified are
recommended
• Least privilege policy
• Locking user accounts if that are not in use and
removing accounts if never used anymore
9. Availability
• Database is available at all times only for authorized
users and authenticated persons
• Database is protected from being shut down due to
external or internal threats or attacks, can not have
unplanned downtime.
• Overloads, performance constraints and capacity
issues resulting in the inability of authorized users to
use databases as intended
10. Solutions
• Restrict the amount of storage space given to each
user in the database.
• Limit the number of concurrent sessions made
available to each database user.
• Backup the data at periodic intervals to ensure data
recovery in case of application issues.
• Databases should be secured against security
vulnerabilities.
• To ensure high availability, usage of database clusters
is recommended.
11. Threats to Database Security
1. Granted excessive privileges and permissions, and
privilege and permission abuse on database
2. Unauthorized privilege exploitation by hackers
3. SQL injection by hackers
4. Weak audit
5. Weak authentication
6. Database rootkits
7. Exposure of backup data
13. Mobile Database Security
Data on mobile devices need additional security protection
• BYOD (Bring Your Own Devise) mobile work environment
nature:
Data may be acquired by malicious parties or malware who
attempting to recover sensitive data on device
• Encrypting the sensitive data on mobile or not storing sensitive
data on mobile devices. Even if a mobile device is always in the
possession of its owner
• Authentication for access to the data on mobile device or the
organization's data
– Using domain authentication to enforce the device
authentication capabilities instead of just using device’s pin
14. Authentication
• A SQLite database is convenient for storing mobile data on
smartphone but is not well protected.
• SQLite is not a multi-user database, which means that anyone
who has direct access to the file can read the database content.
• SQLite must be permitted by the file access control mechanism
first. Authentication can be added to the DBMS: the user or
application provides its identity; and the database
authenticates the validity of the user or application. Only
legitimate users or application can access the data in the
database, e.g. created, queried, modified, inserted, deleted,
modified.
15. DAC and MAC Access Control
• Discretionary Access Control (DAC) enforces security by means
of user identifiers(uid) and group identifiers (gid); only the
owner of the data (i.e., the Content Provider) holds the r/w
permissions on the file.
• Mandatory Access Control (MAC) is based on clearance, i.e.,
security labels (secret, top secret, confidential, etc.). Data
objects are given a security classification, and the user will be
denied access if his clearance is lower than the classification of
the object.
• SQLite is single user database (whoever has direct access to the
file can read the data), the use of DAC alone is not adequate
and enough.
16. Data Encryption
There are two data encryption schema for SQLite
1. Strong Encryption of DB on the DBMS level, i.e. perform
encryption or decryption while DB reading/ writing where the
encryption function is embedded into the DBMS, and the
encryption and decryption process is transparent to users.
2. Encrypt DB on application layer, where encryption or
decryption can be operated on some fields of the
records(fields)
3. SQLChiper is an extension of SQLite which provide data
encryption based on user password.
17. Auditing Mechanism
• Auditing SQLite can be implemented with the logging
mechanism provided by the operating system.
For example, on Linux system, the syslog system call can be
used to log important operations.
• Audit mechanism in DBMS can also be implemented in
application layer. In DBMS, API can be provided to log
important operations.
• Either of these two methods needs to modify the source code
of SQLite and enable the multithread options at the same
time.
18. Mobile Sync
• Working offline is an expected feature of mobile applications.
Store app data locally, and implement data synchronization that
keeps your local and server data in sync but data leaks are the
concern.
• A reset link to a webmail account such as Gmail or Hotmail is
hardly secure, and when they get hacked, the security of the
synced data is compromised.
• Ensure users don't have the same password for every app or
service.
• If possible, discourage users from storing sensitive work data in
these cloud services that IT does not control.
• External connections should be encrypted as well by SSL.
19. Remote lock device and wipe data
If device is lost or data is at risk: Locate, lock and wipe:
• Locate: Locate your lost device and display the location on a
Google map. Register your device with one of the many
available "find me" services to locate and recover lost devices
• Lock: Remotely locks down your lost device, that nobody can
use your phone without your access, even somebody else
exchanges the SIM card on your phone.
• Wipe: Remotely wipe out important data on your device.
20. SQL injection attack and Defense
SQL injection by passing the user input to SQL statement, SQL
injection may take place.
Query("SELECT * FROM usertable WHERE _id='"+m_id+"'",null );
Injected input strings may look like the followings
• 1’ or ‘1’ = ‘1
• 1’ or username not null –
Defense: Using parameterized binding with “?”
Input validation and filtering
21. SQLite Content providers
• Content provider is a primary building blocks for sharing data
in SQLite to multiple apps. Provider offer data encapsulation
based on URI's. Any URI which starts with content:// points to
a resources which can be accessed via a provider via CRUD.
• A provider allows apps to access data stored in an SQLite
database, on the file system, in flat files or on a remote server.
• A content provider is only required if you need to share data
between multiple applications. Ex., the contacts data is used
by multiple applications and must be stored in a content
provider.
• If you don't need to share data amongst multiple applications
you can use a database directly via SQLiteDatabase
23. Security for Content Provider
• As application data is by default private, a content provider is
convenient to share you data with other application based on
a CRUD methods interface which implements CRUD.
• A content provider must be declared in the manifest file and
made available to other Android applications: declare your
content provider using android:exported=false|true
parameter in the AndroidManifest.xml file.
• It is good practice to always set the android:exported
parameter to ensure correct behavior across Android
versions.
• Unless you must share a Sqlite to many different apps, don’t
provide content provider
24. Review questions:
• What is Database security?
• What are the common security threats to database systems?
• How to protect database?
• What are the special problems in mobile database security?
• How to provide mobile database security?
25. Project: Information Assurance and Network Security – Database Security
Laboratory for the project – PLab: Information Assurance and Security Education on
Portable Labs
Webpage of PLab: https://sites.google.com/site/iasoncs/home/database-security
Four Hands-on Labs:
Database Access Control Model
(1) SQL Example
(2) Database Access Example
Database Injection
(3) SQL Injection
(4) NoSQL Injection
Requirement of the project report:
• Describe the purpose of each lab
• Attach the screenshots/results of each lab
• Observation from the result that match the purpose of the labs that you described.
