1. Database Security Fundamentals of Database system, 5 th Edition, Ramez Elmasri and Shamkant B. Navathe

2. Introduction to Database Security Issues Types of Security  Legal and ethical issues:  the right to access certain information. Some information may be deemed to be private and cannot be accessed legally by unauthorized persons  Policy issues  as to what kinds of information should not be made publicly available- for example, credit ratings and personal medical records  System-related issues  whether a security function should be handled at the physical hardware level, the operating system level, or the DBMS level  The need to identify multiple security levels  identify multiple security levels and to categorize the data and users based on these classifications-for example, top secret, secret, confidential, and unclassified. 2

3. Threats to databases Loss of integrity  Improper modification of information.  Modification  creation, insertion, modification, changing the status of data, and deletion.  by either intentional or accidental acts.  If not corrected  may contaminate system  corrupt data  inaccuracy Loss of availability  Objects unavailable to user with legitimate right. Loss of confidentiality  unauthorized disclosure of confidential information  intentional, unanticipated, or unintentional  could result in loss of public confidence, embarrassment, or legal action 3

4. Countermeasures To protect databases against these types of threats four kinds of countermeasures can be implemented:  Access control  Inference control  Flow control  Encryption 4

5. Countermeasures : Access control The security mechanism of a DBMS must include provisions for restricting access to the database as a whole  Handled by creating user accounts and passwords to control login process by the DBMS. 5

6. Countermeasures : Access control In a multiuser database system  DBMS must ensure that certain users or user groups to access selected portions of a database without gaining access to the rest of the database. A DBMS typically includes a database security and authorization subsystem that is responsible for ensuring the security portions of a database against unauthorized access. Two types of database security mechanisms:  Discretionary security mechanisms  Mandatory security mechanisms 6

7. Countermeasures : Access control Discretionary security mechanisms:  Used to grant privileges to users  access specific data files, records, or fields in a specified mode (such as read, insert, delete, or update). Mandatory security mechanisms:  Used to enforce multilevel security  by classifying the data and users into various security classes (or levels)  then implementing the appropriate security policy.  For example  User at Level 1 can see data in level 1 and lower (level 0), but not higher (Level 2)  An extension of this is role-based security  Typical security classes are top secret (TS), secret (S), confidential (C), and unclassified (U), where TS is the highest level and U the lowest: TS ≥ S ≥ C ≥ U 7

8. Countermeasures : Inference control The security problem associated with databases is that of controlling the access to a statistical database, which is used to provide statistical information or summaries of values based on various criteria.  Must allow access to certain information needed but not all and not detailed information on specific individuals.  Must not allow information to be inferred or deduced from statistical query The countermeasures to statistical database security problem is called inference control measures. 8

9. Xtra: Statistical Database Statistical databases are used mainly to produce statistics on various populations. The database may contain confidential data on individuals, which should be protected from user access. Users are permitted to retrieve statistical information on the populations, such as averages, sums, counts, maximums, minimums, and standard deviations. 9

10. Xtra: Statistical Database A population is a set of tuples of a relation (table) that satisfy some selection condition. Statistical queries involve applying statistical functions to a population of tuples. 10

11. Xtra: Statistical Database For example, we may want to retrieve the number of individuals in a population or the average income in the population.  However, statistical users are not allowed to retrieve individual data, such as the income of a specific person. Statistical database security techniques must prohibit the retrieval of individual data. This can be achieved by prohibiting queries that retrieve attribute values and by allowing only queries that involve statistical aggregate functions such as COUNT, SUM, MIN, MAX, AVERAGE, and STANDARD DEVIATION.  Such queries are sometimes called statistical queries. 11

12. Xtra: Statistical Database It is DBMS’s responsibility to ensure confidentiality of information about individuals, while still providing useful statistical summaries of data about those individuals to users. Provision of privacy protection of users in a statistical database is paramount. In some cases it is possible to infer the values of individual tuples from a sequence statistical queries.  This is particularly true when the conditions result in a population consisting of a small number of tuples. 12

13. Countermeasures : Flow control Another security is that of flow control, which prevents information from flowing in such a way that it reaches unauthorized users. Channels that are pathways for information to flow implicitly in ways that violate the security policy of an organization are called covert channels. A flow policy specifies the channels along which information is allowed to move. 13

14. Countermeasures : Encryption A final security issue is data encryption, which is used to protect sensitive data (such as credit card numbers) that is being transmitted via some type communication network. The data is encoded using some encoding algorithm.  An unauthorized user who access encoded data will have difficulty deciphering it, but authorized users are given decoding or decrypting algorithms (or keys) to decipher data. 14

15. Database Administrator (DBA ) The database administrator (DBA) is the central authority for managing a database system.  The DBA’s responsibilities include  granting privileges to users who need to use the system  classifying users and data in accordance with the policy of the organization The DBA is responsible for the overall security of the database system. 15

16. Database Administrator (DBA ) The DBA has a DBA account in the DBMS  Sometimes these are called a system or superuser account  These accounts provide powerful capabilities such as:  1. Account creation  2. Privilege granting  3. Privilege revocation  4. Security level assignment  Action 1 is access control, whereas 2 and 3 are to control discretionary authorization and 4 is used to control mandatory authorization 16

17. Database Audits The database system must also keep track of all operations on the database that are applied by a certain user throughout each login session.  To keep a record of all updates applied to the database and of the particular user who applied each update, we can modify system log, which includes an entry for each operation applied to the database that may be required for recovery from a transaction failure or system crash. 17

18. Database Audits If any tampering with the database is suspected, a database audit is performed  A database audit consists of reviewing the log to examine all accesses and operations applied to the database during a certain time period. A database log that is used mainly for security purposes is sometimes called an audit trail. 18

19. 19 Application Security

20. 20 Application Security, the protection of an application against security threats. The current state of Application Security  security has been an afterthought. Rather than focus on application  focus on surrounding environment  Focus not on application security  Focus on protection of data in transit and storage  e.g. using cryptography  But the threats to applications have evolved This lack of security foresight has cost billions in lost revenue and now threatens the information technology infrastructure

21. 21 In developing an application, you must look at all possible threats  Attacker only needs to focus on 1 Misconceptions:  I have firewall I am safe  Firewall is good but it is not a complete solution by itself  We encrypt the data on route  Are you using ANY encryption? Following a standard? Aware of current weaknesses of encryption?  We adopt SSL (Secure Socket Layers)  SSL is great at encrypting traffic over the network  but it does not validate your application's input or protect you from a poorly configured server.

22. How Do You Build a Secure Web Application? 22 It is not possible to design and build a secure Web application until you know your threats. Recommendation: Add threat modeling into your application's design phase.  The purpose of threat modeling  analyze your application's architecture and design and identify potentially vulnerable areas that may compromise your system's security (unintentionally or maliciously).

23. How Do You Build a Secure Web Application? 23 After you know your threats, design with security in mind by applying proven security principles.  Follow secure coding techniques to develop secure, robust, and hack-resilient solutions.  The design and development of application layer software must be supported by a secure network, host, and application configuration on the servers where the application software is to be deployed.

24. A holistic approach to security 24 "A vulnerability in a network will allow a malicious user to exploit a host or an application. A vulnerability in a host will allow a malicious user to exploit a network or an application. A vulnerability in an application will allow a malicious user to exploit a network or a host." — Carlos Lyons, Corporate Security, Microsoft To build secure Web applications, a holistic approach to application security is required and security must be applied at all three layers

25. A holistic approach to security 25 protect from TCP/IP-based attacks implement countermeasures ensuring traffic integrity Apply secure configuration settings – e.g. Patches, updates, registry, etc http://msdn.microsoft.com/en-us/library/ff648636.aspx Make use of Application Vulnerability Categories as a guide for developing application and evaluating the security of a Web application. Because the categories represent the areas where security mistakes are most frequently made

26. Anatomy of an Attack 26 The basic approach used by attackers to target your Web application:  Survey and assess  survey the potential target to identify and assess its characteristics, its vulnerabilities, potential entry points  Exploit and penetrate  Exploit vulnerabilities, get in  usually through normal entry (logon page, common pages)  Escalate privileges  They immediately attempt to escalate privileges  e.g. administration privileges  Maintain access  Having gained access to a system, an attacker takes steps to make future access easier and to cover his or her tracks  backdoor, take over weak accounts  Deny service  Attackers who cannot gain access often mount a denial of service attack to prevent others from using the application.

27. Application Threats 27

28. Core Security Principles 28 Compartmentalize  Reduce the surface area of attack.  What resources can an attacker get to?  Firewalls, least privileged accounts, and least privileged code are examples of compartmentalizing. Use least privilege  By running processes using accounts with minimal privileges and access rights, you significantly reduce the capabilities of an attacker if the attacker manages to compromise security and run code.

29. Core Security Principles 29 Apply defense in depth  Use multiple gatekeepers to keep attackers at bay.  Do not rely on a single layer of security  always consider that one of the layers may be bypassed or compromised. Do not trust user input  Your application's user input is the attacker's primary weapon when targeting your application.  Assume all input is malicious until proven otherwise  apply input validation strategy

30. Core Security Principles 30 Check at the gate  Authenticate and authorize early —at the first gate. Fail securely  If an application fails, do not leave sensitive data accessible.  Do not include details that may help an attacker exploit vulnerabilities in your application. Secure the weakest link  Is there a vulnerability at the network layer that an attacker can exploit? What about the host? Is your application secure?  Any weak link in the chain is an opportunity for breached security.

31. Core Security Principles 31 Create secure defaults  Is the default account set up with least privilege? Is the default account disabled by default and then explicitly enabled when required? Reduce your attack surface  Reduce the surface area of attack by disabling or removing unused services, protocols, and functionality.  Does your server need all those services and ports? Does your application need all those features?  If you do not use it, remove it or disable it

32. Class Assignment 32 In groups of 5 complete both parts of the assignment. Part 1 : you must find information and write an introduction to the following threats. It must be simple and easy to understand.  cross-site scripting (XSS), SQL injection, buffer overflow attacks Part 2: Investigate and write about S-SDLC (Secure Software Development Life Cycle). Reminder: If you keep giving me cut- n-paste versions of assignments, your marks are going to suffer.

33. Extra reading 33 http://software-security.sans.org/blog/category/top25/ http://msdn.microsoft.com/en-us/library/ff647927.aspx