1. 1 Advanced Database Course (ESED5204) Eng. Hanan Alyazji University of Palestine Software Engineering Department

2. 2 Database Security

3. 3 Security  Secrecy: Users should not be able to see things they are not supposed to.  Security: is keeping unauthorized entities from doing things you don’t want them to do.  A security policy: is a statement of what is and what is not allowed.  A security mechanism: is a method, tool, or procedure for enforcing a security policy.

4. 4 Security types  Computer Security: Generic name for the collection of tools designed to protect data and to thwart hackers.  Network Security: Measures to protect data during their transmission.  Internet Security: Measures to protect data during their transmission over a collection of interconnected networks.

5. 5 Database Security  Database Security is the protection of the data against accidental or intentional loss, destruction, or misuse.  Database system security is more than securing the database.  Secure database.  Secure DBMS.  Secure applications.  Secure operating system in relation to database system.  Secure web server in relation to database system.  Secure network environment in relation to database system.

6. 6 Basic Component of data security Generally Security is:  Confidentiality.  Protection of data from unauthorized disclosure.  Who is authorized to use data?  Integrity.  Assurance that data received is as sent by an authorized entity.  Availability.  Can access data whenever. C I A S S = Secure

7. 7 Confidentiality  Confidentiality: The property that information is not made available or disclosed to unauthorized individuals, entities.  Not the same as privacy.  Privacy: The right of an entity (normally a person), acting in its own behalf, to determine the degree to which it will interact with its environment, including the degree to which the entity is willing to share information about itself with others.  Privacy is a reason for confidentiality.

8. 8 Integrity  Integrity: Users should not be able to modify things they are not supposed to.  Data integrity: The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner.  System integrity: The quality that a system has when it can perform its intended function in a unimpaired manner, free from deliberate unauthorized manipulation.

9. 9 Availability  Availability: authorized users should be able to see and modify things they are allowed to.  The property of a system or a system resource being accessible and usable upon demand by an authorized system entity, according to performance specifications for the system. i.e., a system is available if it provides services according to the system design whenever users request them.  Note: Turning off a computer provides confidentiality and integrity, but hurts availability...

10. 10 Goals of Security  Prevention  Prevent attackers from violating security policy.  Detection  Detect attackers’ violation of security policy.  Recovery  Stop attack, assess and repair damage.  Continue to function correctly even if attack succeeds.

11. 11 Security For:  Vulnerability: An error or weakness in the design, implementation, or operation of a system.  Vulnerability = a weakness in a security system.  Attack: A means of exploit some vulnerability in a system.  Threat: An adversary that is motivated and capable of exploiting a vulnerability.  Threat = circumstances that have a potential to cause harm.

12. 12 Security Problems  Information when stored, is subject to:  Copying (and distributing) by unauthorized person.  Modification by unauthorized person.  Information when sent over network, is subject to:  Eavesdropping by unauthorized person.  Modification by unauthorized person.  Organization’s network is subject to:  Access internal resource.  Denial of service attack.  Be used as springboard to attack other networks.

13. 13 Security Attacks  Eavesdropping:  Messages get tapped on its way from source to destination.  Tampering:  Changing contents of messages, inserting erroneous messages, possibly replacing valid ones.  Replay:  Capture earlier (may be encrypted) messages and send it again.  Impostering (masquerading):  Impostering client to get access to service,  Impostering server to get information from client.

14. 14 Examples of Attackers:  Scan your system for confidential documents.  Corrupt information on your system.  Use your system to store pirated software.  Cause your system to crash.  Use your credit card number stored in computer.  Block access to your system.  Install applications in your system.

15. 15 Threats to data security can come from:  Accidental losses:  Attributable to Human error.  Software or hardware failure:  By using procedures on user authorization, uniform software installation procedures, hardware maintenance.  Theft and fraud.  Loss of privacy (personal data).  Loss of confidentiality (corporate data).  Loss of data integrity (invalid/corrupt data).  Loss of availability.

16. 16 Security policy  Security policy = set of permissions.  A set of requirements and guidelines to ensure a desired level of security for the activities performed in the system.  Examples:  Messages can only be read by the intended recipient.  Files can only be written by respective owners.  Service should be free from replaying attacks.  The system is secure if and only if the security policy cannot be violated.

17. 17 Security Categories 1. Physical Security. 2. Technological Security.  Application Security.  Operating System Security.  Network Security. 3. Policies & Procedures.  All Three Required for securing database and grantee data is protected.

18. 18 1. Physical Security:  Limit access to physical space to prevent asset theft and unauthorized entry.  Protecting against information leakage and document theft. Examples:  Computing resources.  Storage (live and backups).  Communications and remote access.  Support (power and cooling).

19. 19 2. Technological Security: 2.1 Application Security:  No flaws in identity verification process.  Configure server correctly (local files, database content) 2.2 Operating System & Network Security:  Applications use operating system for many functions.  Operating System code likely contains vulnerabilities.  Regularly download patches to eliminate.  Network Security: mitigate malicious traffic.  Tools: Firewalls & Intrusion Detection Systems.

20. 20 3. Policies & Procedures:  Guard sensitive corporate information.  Employees need to be aware, be educated to be somewhat paranoid and vigilant. Example:  Personal attack:  Taking advantage of unsuspecting employees or person. (e.g. attacker gets employee to divulge his username & password)

21. 21 Security Concepts  Seven Keys Security Concepts: 1.Authentication.  Ensure the user is who he/she claims to be. 2.Authorization.  Deal with who can access what and in what mode. 3.Confidentiality.  Protect content of data from being reviled to unauthorized party. 4.Data / Message Integrity  Ensure data has not been changed

22. 22 5.Accountability  Ability to determine the attacker or principal. 6.Availability  Service/resource is accessible to legitimate use 7.Non-Repudiation  Message sender cannot deny later having sent it.

23. 23 Authorization  Checking whether a user has permission to conduct some action.  Identity is the key for Authority.  Is a “subject” allowed to access an “object” (open a file)?  Access Control List: mechanism used by many operating systems to determine whether users are authorized to conduct different actions.

24. 24 Access Control Model  An Access Control Model includes:  Subjects  Computers,Processes, The system.  Objects  Data, Programs.  Actions  The subjects can performed on the objects(select,Insert, delete,...)  Security Policy  Defines the authorization rules (permissions).

25. 25 Security System Objects Subjects Access control

26. 26 Access Control Lists (ACLs)  Set of three - tuples  (User, Resource, Privilege)  Specifies which users are allowed to access which resources with which privileges.  Privileges can be assigned based on roles (e.g. admin). UserResourcePrivilege Alice/office/Alice/*Read, write, execute Bob/home/Bob /*Read A Simple ACL

27. 27 Security Models  Access Matrix Model:  Represents two main entities: objects and subjects  Columns represent objects  Rows represent subjects  Objects: tables, views, procedures, database objects  Subjects: users, roles, privileges, modules  Access levels: a subject has access to objects at its level and all levels below it.

28. 28 Access matrix Security Models

29. 29 Access Modes:  Static Modes  Dynamic modes

30. 30

31. 31 Roles  Named group of related privileges that are granted to users or other roles.  Used to group users.  Can reduce hundreds of thousands of security settings to hundreds of security settings.  If user is in multiple roles, will gain privileges of each role.

32. 32 Privileges  Privileges allow users to perform specific actions in the database. There are two types of privileges: 1.Object Privileges: allow the user to have access to the data within an object or execute a stored program. 2.System Privileges: allow the user to logon to the system and create or manipulate objects.

33. 33 Object Privileges  ALTER : Change the definition of a table.  SELECT : Query the data in a table or view.  DELETE : Delete records from a table or view.  INSERT : Add records to a table or view.  EXECUTE : Run stored procedures and functions.  INDEX : Create an index on a table.  READ : Allow the user to view from a directory.  UPDATE : Modify the data in a table or view.  REFERENCE : Create a reference to a table.

34. 34 Account System Privileges  Each ACCOUNT can be allocated many SYSTEM PRIVILEGEs and many ROLEs  An ACCOUNT has all the PRIVILEGEs  A ROLE can have many SYSTEM PRIVILEGEs and it may also have a relationship to other ROLEs  ROLEs simplify the administration of the database.  A set of privileges can be assigned to or removed from a ROLE just once.

35. 35 Oracle Security  Oracle security components:  An ACCOUNT is a user account  A PROFILE is a set of system resource that are assigned to an account.  A PRIVILEGE is the right to perform a task  A ROLE consists of groups of PRIVILEGEs and other ROLEs

36. 36 SQL GRANT Command  The GRANT command gives permissions to users to access and change data.  GRANT privileges ON tablename TO { grantee... } [ WITH GRANT OPTION ] Possible privileges are:  SELECT: user can retrieve data.  UPDATE: user can modify existing data.  DELETE: user can remove data.  INSERT: user can insert new data.  REFERENCES: user can make references to the table.  GRANT: is used to grant privileges to users.

37. 37 REVOKE command  The REVOKE command removes permissions from users to access and change data.  Removes privileges to access a table.  REVOKE {SELECT, INSERT, UPDATE, DELETE} ON tablename FROM username. Example  Remove privileges from Smith to insert or delete from emp  REVOKE INSERT, DELETE ON emp FROM smith

38. 38 Application Security Models  Models:  Database role based.  Application role based.  Application function based.  Application role and function based.  Application table based.

39. 39 Security Model Based on Database Roles Application authenticates application users:  Maintain all users in a table.  Each user is assigned a role.  roles have privileges assigned to them  A proxy user is needed to activate assigned roles;  all roles are assigned to the proxy user  Model and privileges are database dependent.

40. 40 Security Model Based on Database Roles Schema User: Oracle user that owns all database objects. Application User: Oracle user that need access to those schema objects.

41. 41 Security Model Based on Database Roles  Implementation in Oracle:  Create users  Add content to your tables  Add a row for an application user  Look for application user’s role  Activate the role for this specific session

42. 42 Security Model Based on Application Roles  Application roles are mapped to real business roles.  Application authenticates users.  Each user is assigned to an application role.  Application roles are provided with application privileges (read and write)

43. 43 Security Model Based on Application Roles

44. 44 Security Model Based on Application Functions  Application authenticates users.  Application is divided into functions.  Considerations:  Isolates application security from database.  Passwords must be securely encrypted.  Must use a real database user.  Granular privileges require more effort during implementation.

45. 45 Security Model Based on Application Functions

46. 46 Security Model Based on Application Roles and Functions  Combination of models.  Application authenticates users.  Application is divided into functions:  Roles are assigned to functions.  Functions are assigned to users.  Highly flexible model.

47. 47 Security Model Based on Application Roles and Functions

48. 48 Security Model Based on Application Tables  Depends on the application to authenticate users.  Application provides privileges to the user based on tables; not on a role or a function.  User is assigned access privilege to each table owned by the application owner.

49. 49 Security Model Based on Application Tables

50. 50 Questions? ?