Database Role Activity

DB Role and Privileges Worksheet

DB Role and Privileges Answers

Remember Code Change SOD?

Database Security Configuration 1. Verify that database permissions are granted or revoked appropriately for the required level of authorization. Risk: If database permissions are not restricted properly, unauthorized access to critical data may occur.

Database Security Configuration 2. Review database permissions granted to individuals instead of groups or roles. Risk: Assigning permissions to individuals rather than roles/groups increases maintenance required for security, and greatly increases the chances of making security mistakes.

Database Security Configuration 3. Ensure that database permissions are not implicitly granted incorrectly. Risk: Poorly managed database permissions can allow access to all data and can lead to unauthorized access to data.

Database Security Configuration 4. Review dynamic SQL executed in stored procedures. Risk: If stored procedures and functions are not constructed properly, they be manipulated to gain unauthorized access to data and functionality.

Database Security Configuration 5. Ensure that row-level access to table data is implemented properly. Risk: If row-level security is not well designed, the DBA may be unable to restrict access to a subset of rows in a table.

Database Security Configuration 6. Ensure that PUBLIC permissions are revoked where not needed. Risk: Default PUBLIC permissions will most likely provide more access than is warranted than business need requires.

Oracle Access Worksheet

Oracle Access Answers

Example Oracle Output GRANTEE GRANTED_ROLE ADM DEF DBA DELETE_CATALOG_ROLE YES YES EXECUTE_CATALOG_ROLE YES YES EXP_FULL_DATABASE NO YES GATHER_SYSTEM_STATISTICS NO YES IMP_FULL_DATABASE NO YES JAVA_ADMIN NO YES JAVA_DEPLOY NO YES PLUSTRACE YES YES SELECT_CATALOG_ROLE YES YES DBSNMP CONNECT NO YES DPAUL DWREADER NO YES DSHERMAN DWREADER NO YES DWOWNER PLUSTRACE NO YES EXECUTE_CATALOG_ROLE HS_ADMIN_ROLE NO YES

Operating System Security 7. Ensure that access to the operating system is restricted to server administrators and back up operators. Risk: If users have access to the operating system, this can be used to circumvent access controls built into the database and the application(s) on top of the database.

Operating System Security 8. Ensure that permissions on the directory to which the database is installed are restricted to authorized individuals with a business need. Risk: File level access to the database can be used to circumvent access controls to database and application, to alter or corrupt the data, or to disrupt access for authorized users.

Operating System Security 9. Ensure that permissions on the registry keys used by the database are restricted to authorized individuals with a business need. Risk: Failure to secure the registry keys that are used to store configuration values that are important to the secure functioning of the database can lead to a breech of security.

Password Management 10. Check for default usernames and passwords. Risk: Failure to control default usernames and passwords is a violation of University policy, and can lead to unauthorized access, data corruption, and loss of availability.

Default Accounts and Default Password Oracle Default Passwords SYS = CHANGE_ON_INSTALL SYSTEM=MANAGER Scott = Tiger DBSNMP = DBSNMP OUTLN = OUTLN Other Locked Default Accounts

Easily Guessed Passwords 11. Check for easily guessed passwords. Risk: Using passwords that can be easily guessed can lead to unauthorized access. Password complexity is required by University policy.

Password Management 12. Check that password management capabilities are enabled. Risk: If the DBA does not configure the settings, these features will not be enabled, lowering the security of the database.

Password Management Passwords may be established remotely OS Authentication Remote Password File

University Password Policy Same password requirements for servers and applications – 8 character minimum – Periodically changed –Complexity –Failed Login Attempts –Passwords not Shared

Audit Trails & Monitoring 13. Check that auditing is enabled. Risks: Audit trails are required to: o Determine who accessed which systems o Determine what activities were performed o Identify suspicious access o Monitor for attempts to exploit vulnerabilities o Find and track deviations from baseline

Audit Trails & Monitoring –More critical in a DB setting –Often claimed to be too resource intensive

Encryption 14. Verify that network encryption is implemented. Risk: Data sent in the clear can be intercepted by unauthorized parties.

Encryption 15. Verify that encryption of data-at-rest is implemented where appropriate. Ensure that encryption key management is part of the disaster- recovery plan. Risk: Data are most likely to be stolen from the database while at rest, not while traversing the network.

Patch Management and Integrity 16. Verify that the latest patches for the database have been installed. Risk: Failure to apply security patches will leave the database vulnerable to compromise.

Patch Management and Integrity 17. Verify that the database is running a version the vendor continues to support. Risk: An unsupported version may no longer receive patches, leaving the system open to new vulnerabilities.

Patch Management and Integrity 18. Verify that policies and procedures are in place to identify when a patch is available and to apply the patch. Risk: If policies and procedures are not in place to identify when a patch is available, the DBA may be unaware of new patches.

Patch Management and Integrity 19. Evaluate what the database administration group is doing to ensure the integrity of the database, (looking for root kits, viruses, backdoors, etc). Risk: If a compromise is not detected, an unauthorized individual may maintain access for an extended period of time.

Application and Database Auditing Exercise