Marek Rychly mrychly@strathmore.edu Strathmore University, @ilabafrica & Brno University of Technology, Faculty of Information Technology Enterprise Security 30 November 2015 Marek Rychly ES, 30 November 2015 1 / 36
Outline 1 Course Content Lectures, Assessments, Projects Evaluation Background on the Course 2 3 Marek Rychly ES, 30 November 2015 2 / 36
Lectures Course Content Lectures, Assessments, Projects Evaluation Background on the Course 1 (security terms/glossary, architecture, incidents, models) 2 Identity Management and Access Control (authentication and authorization, discretionary/mandatory access control, roles) 3 Database Application Security Models and Policies (security models for client-server and web-apps., system/data/user sec. policies) 4 Virtual Private Database, Security in Statistical Databases (security by views/triggers, application context, securing aggregation queries) 5 Database Security Issues and Features (transparent data encryption, inference/poly-instantiation) 6 Application Security (SQL-injection and other issues) 7 Database Auditing (data selection, manipulation, and control audits) Marek Rychly ES, 30 November 2015 4 / 36
Core Reading Materials Lectures, Assessments, Projects Evaluation Background on the Course Hassan Afyouni. Database Security and Auditing: Protecting Data Integrity and Accessibility. Cengage Learning, 2005. ISBN 9781285700984. URL https://books.google.com/books?id=wpyeawaaqbaj. Ron Ben Natan. Implementing Database Security and Auditing. Elsevier Digital Press, 2005. ISBN 978-1-55558-334-7. URL http: //www.sciencedirect.com/science/book/9781555583347. Marek Rychly ES, 30 November 2015 5 / 36
Evaluation Course Content Lectures, Assessments, Projects Evaluation Background on the Course 20% assignment (submitted to mrychly@strathmore.edu by end of year 2015) 40% project (submitted to mrychly@strathmore.edu by end of the study week, 26 Feb) 40% final exam (in the exam week, 29 February to 4 March 2016) Marek Rychly ES, 30 November 2015 6 / 36
Assignment (20%) Course Content Lectures, Assessments, Projects Evaluation Background on the Course 1 select one of relational database management systems (RDBMS), except for Oracle database (see Comparison of relational database management systems at Wikipedia) 2 for the selected RDBMS, study documentation of its database security features and possible configurations 3 provide a summary 1 of the database security features and possible configurations of the selected RDBMS that were discussed in the first three lectures of this course (identity management, access control, supported security models and policies) 1 any external sources you use in your text must be properly cited Marek Rychly ES, 30 November 2015 7 / 36
Project (40%) Course Content Lectures, Assessments, Projects Evaluation Background on the Course 1 describe goals and objectives of db. security in a sample company (a made up company which needs to manage confidential data) 2 design identity management, secure data storage and access control solution for the company (security model, policies, user management, roles, profiles, rights, etc.) 3 design auditing plans to support database security in the company (entities, actions, and users to audit, audit trail storage) 4 provide SQL scripts implementing the above mentioned security measures in a local instance of Oracle RDBMS (create profiles, roles, users, tables and views in a virtual private database of encrypted data, audit functionality, etc.) Marek Rychly ES, 30 November 2015 8 / 36
Prior Knowledge and Skills Lectures, Assessments, Projects Evaluation Background on the Course The course does not require any prior knowledge or skill except for those covered by the ADES course. However, the following may help you to understand the lectures: 1 operation system design principles (process and memory management, authentication and authorization, etc.) 2 basics of computer networking (IP network, protocols, etc.) 3 general awareness of the current IT security news (common vulnerabilities and exposures, security patches, etc.) 4 ability to use Oracle database and (PL/)SQL (schema, system catalogue, access management, etc.) Marek Rychly ES, 30 November 2015 9 / 36
Database Security Course Content Definition (Database security) The mechanisms that protect the database against intentional or accidental threats. Definition (Threat) Any situation or event, whether intentional or accidental, that may adversely affect a system and consequently the organization. 1 A database represents an essential corporate resource. (should be properly secured using appropriate controls) 2 Securing the database includes controlling physical, personal and organizational security. (i.e., securing products/components, people, processes in the organization) Marek Rychly ES, 30 November 2015 11 / 36
Fundamental Questions for Information Security What are you trying to protect or maintain? (important assets to protect) What are your business objectives and what do you need to accomplish and support these objectives? (required technologies or solutions to support the business) Are your objectives compatible with your security architecture? What risks are associated with inadequate security? What are the implications of not implementing security? Will you introduce new risks not covered by the current security? How do you reduce that risks? What is your tolerance for risk? (inspired by Overview of Network Security, Cisco) Marek Rychly ES, 30 November 2015 12 / 36
Information Security Conceptual Architecture (adopted from Information Security: A Conceptual Architecture Approach, Oracle ) Marek Rychly ES, 30 November 2015 13 / 36
Confidentiality, Integrity, Availability (CIA) and Non-repudiation Protecting information systems from loss of Confidentiality ensure that information is not made available or disclosed to unauthorized entities, individuals or processes. Integrity protect the accuracy and completeness of information. Availability keep information accessible and usable when an authorized entity demands access. Non-repudiation provide an undeniable proof that an alleged event or action actually happened or was carried out by a particular entity in a particular origin. (adopted from ISO IEC 27001 2013 Translated into Plain English, Praxiom Research Group Limited) Marek Rychly ES, 30 November 2015 14 / 36
Defence in Depth (aka Castle/Onion Approach) multiple layers of security controls (defence) (placed throughout an IT system from its public interface to internal data storage) compromising outside layers do not cause significant damage (there is no such thing as a perfect security layer, method, or product) buy an organization time to detect and respond to an attack (adopted from Defense in Depth: Best Practices for Securing a Teradata Data Warehouse ) Marek Rychly ES, 30 November 2015 15 / 36
Authentication, Authorization and Accounting (AAA) Authentication is the verification of a user credentials. (a way to restrict future actions to specific users with the valid credentials) Can challenge the user for something they know (a password), something they have (a token), or something they are (biometrics). Authorization is the verification that an action is allowed. (determines which resources and operations the user is entitled to use and how; must occur after the successful authentication of the user) Accounting is the process of keeping track of the user s activity. (for auditing, billing, cost allocation, trend analysis, capacity planning, etc.) Marek Rychly ES, 30 November 2015 16 / 36
Vulnerability Assessment and Patch Management VA tools to make inventory, audit, and to compare utilized systems with known flaws and vulnerabilities. Vulnerability Notes Database, Carnegie Mellon University (CERT) Common Vulnerabilities and Exposures (CVE), NVD-US Open Sourced Vulnerability Database, Open Security Foundation PM to apply critical patch updates correcting vulnerabilities. (e.g., Critical Patch Updates, Security Alerts and Third Party Bulletin by Oracle) Hardening to reduce the surface of vulnerability in a system. (a single-function lightweight system is more secure than a multi-purpose one) by disabling unnecessary services, closing network ports by removal of unnecessary software, modules, etc. by locking unused user-names or logins by using well-established secure configurations and frameworks (PIE, PaX, SELinux, isa_harden Windows Server Policy, etc.) Marek Rychly ES, 30 November 2015 17 / 36
Intrusion Detection and Prevention Systems (IDPS) IDPS to address threats within the perimeter and internal network. (identify and log malicious activity, attempt to block/stop it, and report it) Firewalls provide a first, but not perfect, layer of defence (IPS). (they usually work as packet-filters, are shallow in terms of what they look at) Network based and host based intrusion detection systems. (to detect an attack in network and on individual hosts) by detection of statistical anomalies (statistical anomaly-based) by checking signatures of protected assets (signature-based) by running honey-pots to attract possible attackers (appears to be a legitimate system but is actually isolated and monitored) Marek Rychly ES, 30 November 2015 18 / 36
Information Security Auditing and Monitoring Auditing is one of the most important security techniques. (no security without audit, no need to audit without the need for security) (adopted from IBM Guardium ) Marek Rychly ES, 30 November 2015 19 / 36
Defect, Vulnerability, Threat, Attack,... defects are vulnerabilities that can be exploited for attacks attacks are comprised of multiple steps, of attack vector an attack is feasible for a threat to traverse a boundary by interacting with an attack surface which possess a vulnerability the attack results into an exploitation that have a negative impact on business objectives involving business assets risk is defined by a probability of the exploitation and its resulting impact (adopted from John Steven: Threat Modeling Vocabulary, Cigital ) Marek Rychly ES, 30 November 2015 20 / 36
Attack: Tool, Vulnerability, Action, Target, Result (adopted from A common language for computer security incidents ) Marek Rychly ES, 30 November 2015 21 / 36
Attack as Security Incident (adopted from A common language for computer security incidents ) Marek Rychly ES, 30 November 2015 22 / 36
Database security has to be enforced on all levels. (people, applications, network, operating system, DBMS, data files, data) Data requires highest level of protection. (they should be in the core layer protected by the Defence in Depth approach) All layers (security access points) should be secured. (adopted from Afyouni, H.: Database Security and Auditing, Protecting Data Integrity and Accessibility ) Marek Rychly ES, 30 November 2015 23 / 36
Database Security Methodology (adopted from Afyouni, H.: Database Security and Auditing, Protecting Data Integrity and Accessibility ) Marek Rychly ES, 30 November 2015 24 / 36
Database Security Model (adopted from Afyouni, H.: Database Security and Auditing, Protecting Data Integrity and Accessibility ) Marek Rychly ES, 30 November 2015 25 / 36
Database Security Model: Authentication Choose an appropriate (strong) authentication option. (by a password stored encrypted in a db. server; by a token held by a user, including PKI; by a third party service, e.g., Kerberos, LDAP, operating sys., etc.) Understand who gets system administration privileges. (privileges may be defined outside of db. server, e.g., at the operating system level, so each OS administrator may easily act as db. administrator) Choose, promote and verify the use of strong passwords. (mixed-case letters, numbers, punctuation marks, minimal length, without dictionary words, different password for each account/service, etc.) Implement account lockout after failed login attempts. (forever/for a particular period, increasing delays between the failed attempts, etc.; lock a source of an attack, not the attacked account, to prevent a DoS attack) Create and enforce password profiles. (to defined a password lifetime, reuse, lockout, verification function, etc.) Marek Rychly ES, 30 November 2015 26 / 36
Password Strength (credit: xkcd.com, R. Munroe) Marek Rychly ES, 30 November 2015 27 / 36
Database Security Model: Authorization Three dimensions: the authorization of a particular subject to perform a particular action on a particular object. the subject: a user, a group of users (a role) the action is an authorization type (read, update, create, etc.) the authorization object: a single or group of objects, or an entire db. Choose an appropriate access control model (ACM). Mandatory Access Control (MAC) subjects and objects labelled (Biba: read up & write down; Bell-LaPadula: write up & read down) Role Based Access Control (RBAC) subjects authorized by roles (role is a position an individual fills in an organization) Discretionary Access Control (DAC) (a user can set security level settings of his/her objects for other users) Rule Based Access Control (RBAC or RB-RBAC) (dynamically assign roles to users based on particular criteria, e.g., to allow access to objects during certain hours of the day only) Control usage of the ACM by security policies and procedures. (who can control and who must approve the access control settings) Marek Rychly ES, 30 November 2015 28 / 36
Database Security Model: Encryption All passwords stored in a database must be encrypted. (a one-way-only/hash encryption is preferred, passwords cannot be stolen) Also other data with critical confidentiality should be encrypted. encrypted at the application level and than stored in a database (can be processed by an application/db. client and users while cannot be indexed and processed at the database level by a DBMS) encrypted at the database level and than stored in database files (can be processed by a DBMS and authorized users while protected from unauthorized access at the operating system level) encrypted at the operating system level only (can be read by an attacker who breaks into the operating system hosting a DBMS, directly, without an access to the database) A DBMS should support transparent data encryption (TDE) to encrypt data at the database level. Marek Rychly ES, 30 November 2015 29 / 36
Data Redaction and Data Encryption (adopted from Oracle Advanced Security ) (adopted from Transparent Data Encryption, Oracle ) Marek Rychly ES, 30 November 2015 30 / 36
Database Security Model: Audit Record audit trails for particular user activities. for received queries (i.e., SELECT statements) for Data Manipulation and Definition Lang. statements (DML&DDL) (i.e., INSERT, UPDATE, DELETE, CREATE, ALTER, and DROP statements) for Data Control Language statements (DCL) (i.e., GRANT and REVOKE statements) for database events (e.g., login, logout, checkpoint, etc.) for errors occurred (especially for security errors, such as bad login, insufficient privilege, etc.) DBMS must enable an administrator to set and configure auditing. by setting TRIGGERs on audited entities (e.g., tables or their particular columns and rows) by an integrated audit framework (e.g., Oracle s AUDIT command and DBA_AUDIT_* system views) Marek Rychly ES, 30 November 2015 31 / 36
Components of Database Audit Environment (adopted from Afyouni, H.: Database Security and Auditing, Protecting Data Integrity and Accessibility ) Marek Rychly ES, 30 November 2015 32 / 36
The security concepts will be demonstrated on Oracle DBMS. (an enterprise-level object-relational database management system) You can download and install Oracle Database 11g Express Ed.. Or you can download and run Oracle Enterprise Data Quality VM in VirtualBox. In both cases, you can connect and manage databases by means of Oracle SQL Developer tool. Marek Rychly ES, 30 November 2015 34 / 36
Summary Summary Database security is a part of. Confidentiality, integrity, availability, and non-repudiation. Authentication, authorization, and accounting/auditing. Defect, vulnerability, threat, attack, incident,... In the next lecture: Identity Management and Access Control (authentication and authorization, discretionary/mandatory access control, roles) Marek Rychly ES, 30 November 2015 35 / 36
Thanks Thank you for your attention! Marek Rychly <mrychly@strathmore.edu> Marek Rychly ES, 30 November 2015 36 / 36