Database Application Security Models and Policies

Transcription

1 Database Application Security Models and Policies Marek Rychly Strathmore & Brno University of Technology, Faculty of Information Technology Enterprise Security 14 December 2015 Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

2 Outline 1 Application and Database Security Models Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities 2 Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

3 Application and Database-level Identities (from the previous lecture) Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities Application users are identified by an application. (contrary to db. users that are identified by a DBMS) There are different strategies for mapping of app. do db. users: one application user ) one database user (identity management and resource control can be done in a DBMS) + only authorized db. actions can be performed, by users and the app. access control granularity of db. objects (tables, views, etc.) multiple application users ) one database user (the app. decides which db. user to use, e.g., according his role in the app.) + only authorized db. actions can be performed by the app. (bypassing app. access control does not allow all actions) difficult mapping of groups of app. users to db. users all application users ) one database user (i.e., one db. user per app.; the app. does identity mgmt. and access ctrl.) all db. actions can be performed by the app. in a particular database (bypassing app. access control allows all actions in the database) + access control can be implemented in the app. without any limitations Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

4 Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities Authentication and Authorization (AA) in App./Db. Authentication: verifying that a user is who he claims to be Authorization: determining actions he is authorized to perform Different strategies on where AA of a user should be performed: 1 both at the application level (the user authenticate to an application and it determines what the user is authorized to perform, i.e., the app. also implements the access control) 2 both at the database level (an application just forwards the user s credentials to a DBMS which performs authentication and authorization of the user and his actions) 3 authentication at the application level, authorization at the database/dbms level (the user authenticate to an application which informs a DBMS that the following actions are performed by the user of a particular identity, so the DBMS can provide access control/authorization) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

5 AA at the Application Level Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities The user authenticate to an application. The application determines what the user is authorized to perform. The application has to be trusted/secure. a secure application server (in a company s direct control, cannot be hacked and bypassed) not an application server out of a company not a client-side application (a fat client) The app. is usually accessing a db. via one/a few db. users. The db. user(s) has to be able to perform all actions of app. users. + Easy to implement, both simple&complex access control models. (this is the way of many open-source web-based applications) Difficult to secure, possible vulnerabilities. (when hacked, the attacker will control all data and processes in the DBMS) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

6 AA at the Database Level Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities An application just forwards the user s credentials to a DBMS which performs authentication and authorization. The application can be untrusted/insecure. (privilege escalation 1 is not possible by hacking/bypassing the app.) an app. server out of a company or a client-side app. (a fat client) a specialized db. client software for data analysis, OLAP tools, etc. The db. has to know all application users; they are also db. users. (identity management at DBMS or the possibility of single sign-on) The users have to be able to perform only authorized actions. (it is necessary to align the application-level and database-level actions) + Secure, can utilize well-established db. security solutions. (e.g., Oracle Advanced Security, Oracle Real Application Security, etc.) Difficult to align app. and db. privileges and actions, to use a pool. 1 the act of exploiting a vulnerability to gain elevated access to resources that are normally protected from a application user Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

7 Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities Authentication at App. and Authorization at Db. Level The user authenticate to an application. The application perform db. actions under the user s identity. The db. determines what the identity is authorized to perform. The application has to start as a trusted/secure. a secure application server (in a company s direct control, cannot be hacked and bypassed) not an application server out of a company not a client-side application (a fat client) The app. connects to a db. as a predefined (proxy) db. user. (this user can be used to verify an authenticating user s credentials in a table of valid credentials stored in the database; he/she cannot access private data) Later, the proxy user is switched to an authenticated user/identity. (after authentication, the db. connection can be used to access only data of the authenticated app. user s data; i.e., it need not to be protected by the application) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

8 Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities Authentication at App. and Authorization at Db. Level Advantages and Disadvantages + Easy to implement complex authentication methods. (by token, single sign-on, etc.; does not depend of a DBMS) + Identity management can be done at the app. level. (modifications of profiles, credentials, resetting app. users passwords which would for db. users passwords require DBA privilege, etc.) + Possibility of a two-step authorization. (both at the application and database levels) + Easy to use a connection pool. (unused db. connections are stored by the app. in a pool and assigned on demand to particular app. user sessions after the users authentication) + After authentication, db. connection can be used outside the app. (e.g., by a specialized db. client software for data analysis, OLAP tools, etc.) Difficult to align app. and db. privileges and actions. (however, it can be partially solved by the two-step authorization) The application needs to be trusted/secure. (at least its part performing the authentication and setting db. connections) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

9 Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities Roles and the Proxy User Concept in Oracle Database The app. users identities can be represented in db. as individual db. users without CONNECT privilege individual db. roles without password Each app. user has a single db. role for his/her identity. -- assign appuser* db. roles for app. users to a proxy user GRANT ROLE appuser1 [, appuser2,...] TO proxyusername; -- after authentication, switch to a particular db. role SET ROLE appuser1; -- after logout of the app. user, deactivate his/her db. role SET ROLE NONE; Each app. user has a single db. user for his/her identity. -- grant appuser* db. users ability to connect as a proxy user ALTER USER appuser1 GRANT CONNECT THROUGH proxyusername; -- after authentication, switch to a particular app/db. user CONNECT proxyusername[appuser1]/proxyuserpassword; -- after logout of the app. user, switch to the proxy user CONNECT proxyusername/proxyuserpassword; Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

10 Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities Database Passwords in Application Configuration An application (server) needs to authenticate to a DBMS. (as an app. user, a proxy user, or a dedicated db. user representing the application) A password for the authentication needs to be provided: by an app. user when he/she logs into the application (in the case of one app. user per a one db. user) in the application s configuration (in the case of a proxy or dedicated user) Storing the password in the app s configuration brings risks: the application (always) can be hacked (passwords known to the app. will be known to the attacker) the password needs to be let known to the application (the password is a part of an application deployment/configuration package, or it needs to be set on the application start-up) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

11 Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities Stored Database Passwords as a Vulnerability The passwords can be stored and loaded when needed from an application s sources code. (it is a very bad idea to hard-code the passwords there, the code is shared)... an application s configuration files. (also a bad idea as the config. needs to be stored somewhere, and stolen)... an application s command-line arguments. (a bad idea, the arguments values are visible in a list of running processes)... a runtime environment configuration files. (better, provided to the app. by the runtime on demand, however, still accessible)... a external (trusted) authorization service. (better, the app. needs to ask for them, this may be controlled and audited)... a user input or from a removable storage (an USB key, etc.) (better, the user input/removable storage can be manually provided just on the app. start, then inaccessible; an attacker cannot read the passwords and start a new uncontrolled db. connection, he/she can just utilize already opened connections) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

12 Database Connection Pools and Brokers Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities (adopted from Database Net Services Administrator s Guide, Oracle ) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

13 Authentication and Authorization for Application and Database-level Identities Roles and the Proxy User Concept in Oracle Database Database Passwords and Connections Vulnerabilities Db. Connection Pools and Brokers Vulnerabilities The connections are repeatedly reused by different applications. Individual usage of the same conn. must be thoroughly isolated. (otherwise, a future user of the connection can steal an identity of the current user) When provided to an application by a dispatcher, a connection 1 can be opened by a db. proxy user who does not have any privileges (the app. need to switch the user before the conn. can be effectively used) 2 can be opened by a particular user utilized by the application (the app. need not to do the authentication, it is done by dispatcher) In the 2 nd case, the application need not to know the passwords (it can be an untrusted/insecure application, see page 12) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

14 IT and Information Security Policy Security policy defines what is considered to be secure. (for an organization; its part, e.g., IT; a system; etc.) It defines a sec. strategy, operational rules and sec. measures. (what should we secure, why, how it can be done, what is prohibited, etc.) Computer/IT security policy defines security of computer systems. (network security, identity management and access control to the computers, etc.) Information security policy defines security of data/information. (to provide confidentiality, integrity, availability, and non-repudiation) Database security policy = IT & information security policy. Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

15 Database Security Policy 1 Definition of Important Information (what information should be secured) 2 Risk Assessment (why it should be secured, what are threats and their expected impacts) 3 Account Management Policy (who can perform db. operations, e.g., querying, modification, etc.) 4 Logging Policy (what db. operations should be logged for security purposes) Inspired by Database Security Guideline, DBSC Security Guideline WG. Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

16 Db. Security Policy: Defining of Important Information Identifying information that must be protected. Locating the information in an enterprise data model. (by a list of database schemas, their tables, columns, and rows) Locating IT infrastructure objects related to this information. (by a list of DBMSs of the schemas, storage servers, comm. channels, etc.) Classifying information according to their importance. The importance is based on the CIA triad. (confidentiality, integrity, availability, and non-repudiation) The classification can be in terms of well-known class. levels 2. (e.g., top secret, secret, confidential, restricted, official, unclassified, etc.) The classification should be related to a particular context. (the same information can have different classification in different contexts) 2 The classification levels should be defined in a database security policy document. Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

17 Classified Information in Multi-Level Security (MLS) The Bell-La Padula Model (BLP) (adopted from Multi-Level Security (MLS), Red Hat Enterprise Linux Deployment Guide ) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

18 Db. Security Policy: Risk Assessment Definition (Risk assessment, according to AFR ) A study of the vulnerabilities, threats, likelihood, loss or impact, and theoretical effectiveness of security measures. Managers use the results of a risk assessment to develop security requirements and specifications. Identifying threats and performing risk assessment. Conducting a threat assessment. (including malicious acts originating from inside or outside the organization, intentional and unintentional security breaches, accidents, etc.) Conducting a vulnerability assessment. (for each vulnerability, calculating the probability that it will be exploited) Calculating the impact that each threat would have on each asset. (by qualitative or quantitative analysis) Implementing necessary db. security controls based upon the importance of information and the results of risk assessment. (i.e., access control and auditing) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

19 Risk Assessment Matrix (an example) (adopted from A.A.Iacucci: Crisis Mapping and Cybersecurity Part II: Risk Assessment ) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

20 Db. Security Policy: Account Management Policy Defining user roles (database user roles according to a particular security model, see page 4) Defining the roles applicable to the database users. Determining the role of each user based upon the roles defined. Creating accounts and allocating access rights. (based upon users and users role defined above) Reviewing account management policy (to check that defined accounts and allocated access rights are still appropriate) periodical reviews (to stay up to date; there are emerging new vulnerabilities and threats) change reviews (to control changes that may possibly break the security) incident reviews (whenever inappropriately allocated access rights and/or accounts are found) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

21 User Account Management Procedures (adopted from Information Technology Handbook, The University System of Georgia ) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

22 Db. Security Policy: Logging Policy (1) Defining logging objectives (the objectives have to be specific, otherwise the logging cannot be focused) logging to detect unauthorized accesses (the unauthorized accesses has to be detected, if not prevented) logging to obtain forensic evidence (the evidence is necessary for thorough investigation of security incidents) logging to detect trends that may harm the security (e.g., increase of password-reset requests, unsuccessful login attempts, etc.) Determining obtainable audit logs (audit logs from various sources must be effectively combined; e.g., application logs, db. audit logs, operating system logs, network logs, etc.) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

23 Db. Security Policy: Logging Policy (2) Determining what access must be logged types of access related to the important information (e.g., access to confidential information, after regular business hours, etc.) conditions in which access may be considered unauthorized (e.g., large volumes of db. queries, access from an unauthorized location) optionally, all database access should be logged (at least for a short period of time) Determining what information must be included in the logs (when, who, what, where, how, and the result of the activity) Log retention (where and for how long logs will be stored; who, when, and how can access them) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

24 There exist many standards for (not-only) IT security. (legislative requirements, governmental/international security standards and regulations, industrial and corporation security policies and regulations, etc.) Sarbanes-Oxley (SOX) Healthcare Insurance Portability and Accountability Act (HIPAA) EU Privacy Directive, Payment Card Industry (PCI) These IT security standards often deal with information security. (which is implemented by database security policies) They require strong internal controls on access, disclosure or modification of sensitive information that could lead to fraud, identity theft, financial irregularities and financial penalties. Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

25 Common Compliance Security Requirements Preventing privileged users (DBA) from accessing sensitive application data. Preventing compromised privileged users accounts from being used to steal sensitive data or make unauthorized changes to databases and applications. Providing strong controls inside the database over who can do what and controls over when and how applications, data and databases can be accessed. Providing privilege analysis for all users and applications inside the database to help achieve least privilege model and make the databases and applications more secure. Adopted from Oracle Database Vault. Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

26 PCI Data Security Standard, Version 3.1 (April 2015) Build and Maintain a Secure Network and Systems 1 Install and maintain a firewall configuration to protect cardholder data. 2 Do not use vendor-supplied defaults for sys. passwd. and other sec. params. Protect Cardholder Data 3 Protect stored cardholder data. 4 Encrypt transmission of cardholder data across open, public networks. Maintain a Vulnerability Management Program 5 Protect all sys. against malware and regularly update anti-virus SW or progs. 6 Develop and maintain secure systems and applications. Implement Strong Access Control Measures 7 Restrict access to cardholder data by business need to know. 8 Identify and authenticate access to system components. 9 Restrict physical access to cardholder data. Regularly Monitor and Test Networks 10 Track and monitor all access to network resources and cardholder data. 11 Regularly test security systems and processes. Maintain an Information Security Policy 12 Maintain a policy that addresses information security for all personnel. Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

27 Requirements 1&2: Firewall & No Default Passwords A firewall at a dedicated network node or in an operating system. (or multiple firewalls between the public Internet, DMZ, and a private network) Also DBMSs often provide IP-filtering to control network access. (e.g., Oracle Db. Vault, PostgreSQL s pg_hba.conf, etc.) A good practice is to disable the remote access to a DBMS. (except for the access from selected applications and application servers) Disabling default accounts and modification of default passwords is a part of the configuration hardening discussed before. Many DBMSs produce warnings on default security configurations. (e.g., Oracle EM provides the ongoing, necessary checks of default passwords) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

28 Reqs 3&4: Storage Protection & Comm. Encryption The best practice is not to store any sensitive data. (PCI prohibits storage of the full contents of any track from the magnetic stripe ) If sensitive data must be stored, it should be redacted when not all their parts are needed (a merchant must always mask the cardholder s Primary Account Number unless a person or system has a legitimate need to know) (transparently) encrypted (by a disk storage, by an operating system, by a DBMS, by an application) Communication of a DBMS and its clients must be encrypted. (by HTTPS/TLS, by usage of a secure channel, such as a private VPN, etc.) It is recommended to randomize measurable properties of data and related processes in each session to protect against software-based automated loggers. (against OCR, key-loggers, comm. activity loggers/pattern recognition, etc.) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

29 Requirements 5&6: Anti-malware/virus & Maintenance Protecting against malware should be a part of IT security policy. (common users cannot use USB flash disks, install applications, etc.) Anti-virus should be kept up to date on all computer systems. (resources at immune servers can be damaged by infected client computers) Critical systems should have regular maintenance. (by the vulnerability and patch management discussed in the first lecture) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

30 Requirements 7 9: Access Control Access control has to be implemented. (various access control models can be used as discussed before) Authentication and authorization services must be provided. A good practice is to implement explicit deny policies. (an access is denied by default if not configured explicitly otherwise) It is important to preserve the identity of a user throughout a system transaction and implementing access controls at all layers. (see defence-in-depth concept discussed before) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

31 Requirements 10 12: Auditing, Testing, and Updating Sys. monitoring for intrusions and anomalies has to be implem. (it is important to detect a possible attack at its early stages) Access monitoring needs to be enables. (to monitor accesses of DBAs as well as to log accesses of common users) Audit data has to be stored centrally and secured. (analyses of those data must be preformed in the whole context) The audit data has to be reviewed regularly. (PCI says review logs for all system components at least daily ) Testing of security in systems is pivotal to avoiding breaches. (a breach should not be the only indicator that a system had vulnerability) There should be tools/methods to quantify the deg. of compliance. The security policy needs to be maintained and forced. (PCI says screen potential employees to minimize the risk of attacks from internal sources ; create attestation processes and configure their schedule) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

32 Summary Summary Security models of identity mgmt., authentications, and authorization at the application and database levels. Db. security policies to set up goals, objectives, and requirements. IT security often affected by a compliance with security standards. Additional reading: SOX Survival Kit for the SQL Server DBA Oracle Solutions for Payment Card Industry Compliance In the next lecture: Virtual Private Database, Security in Statistical Databases (security by views/triggers, application context, securing aggregation queries) Marek Rychly Database Application Security Models and Policies ES, 14 December / 35

33 Thanks Thank you for your attention! Marek Rychly Marek Rychly Database Application Security Models and Policies ES, 14 December / 35