Database Role Activity. DB Role and Privileges Worksheet

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.


• 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.


• 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.


• 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.


• 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.


• 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 OutputGRANTEE 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 ManagementPasswords 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.


• 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.


• 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.


• 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

Documents

Database Role Activity. DB Role and Privileges Worksheet