Database Security
Dr. Wei Chen, Professor
Department of Compute Science
Tennessee State University
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
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.
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).
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
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
Integrity
• Data and information is accurate and protected from
tampering by unauthorized persons.
• Data and information is consistent and validated.
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
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
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.
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
Database Security Protection
• Impose database security policies and regulations
• Database security practices
– Access control
– Auditing
– Authentication
– Encryption
– Integrity controls
• Application design security
• Replication/synchronization and backups
• Intrusion detection for Database rootkits, malicious code
injection
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
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.
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.
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.
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.
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.
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.
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
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
https://www.tutorialspoint.com/android/android_
content_providers.htm
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
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?
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.

MobileDBSecurity.pptx

  • 1.
    Database Security Dr. WeiChen, Professor Department of Compute Science Tennessee State University
  • 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 dataConfidentiality • 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 • Dataencryption 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 andPrevention • 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 andinformation is accurate and protected from tampering by unauthorized persons. • Data and information is consistent and validated.
  • 8.
    Permission and AccessControls • 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 isavailable 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 theamount 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 DatabaseSecurity 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
  • 12.
    Database Security Protection •Impose database security policies and regulations • Database security practices – Access control – Auditing – Authentication – Encryption – Integrity controls • Application design security • Replication/synchronization and backups • Intrusion detection for Database rootkits, malicious code injection
  • 13.
    Mobile Database Security Dataon 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 SQLitedatabase 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 MACAccess 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 aretwo 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 • AuditingSQLite 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 • Workingoffline 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 deviceand 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 attackand 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
  • 22.
  • 23.
    Security for ContentProvider • 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: • Whatis 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 Assuranceand 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.