Checklist for Auditing Databases
Verify that database permissions are granted or
q Review database permissions granted to individuals instead of groups or roles.
q Ensure that database permissions are not implicitly granted incorrectly.
q Review dynamic SQL executed in stored procedures.
q Ensure that row-level access to table data is implemented properly.
q Revoke PUBLIC permissions where not needed.
q Restrict access to the operating system.
q Restrict permissions on the directory to which the database is installed.
q Restrict permissions on the registry keys used by the database.
q Check for default usernames and passwords.
q Check for easily guessed passwords.
q Check that password management capabilities are enabled.
q Check that auditing is enabled.
q Verify that network encryption is implemented.
q Verify that encryption of data-at-rest is implemented where appropriate. Ensure that encryption key management is part of the disaster-recovery plan.
q Verify that the latest patches for the database have been installed.
q Verify that the database is running a version the vendor continues to support.
q Verify that policies and procedures are in place to identify when a patch is available and to apply the patch.
q Check the integrity of the database by looking for root kits, viruses, backdoors, and Trojan horses.
This chapter should be used to generate thoughts and ideas regarding audit program steps more specific to the application being
It's perfect when you have a perfect audit program you can apply quickly to your perfect application. However, the reality is that you're faced with new ideas and approaches for solving business problems with new technology that requires a new audit program. As you struggle with the questions to ask, you will find the frameworks and best practices below helpful.
Generalized frameworks are useful for meetings where you've been put on the spot to come up with questions and possible risks associated with a new application. You might even find yourself walking into a meeting, taking out a blank sheet of paper, and writing "PPTM," "STRIDE," and "PDIO" at the top before the meeting ever starts.
People, processes, tools, and measures
(PPTM) is a great brainstorming framework to examine an application from the macro level. Detailed specific technical review steps dominate this chapter. PPTM helps you to come up with your own steps quickly and
People in PPTM describes every aspect of the application that deals with a human. Ensure that the right people are involved in the planning, design, implementation, or operations for the project and that the right stakeholders are involved. If the application involves end users, then ensure that the application has controls around provisioning and deprovisioning access and that the end users have been involved in the
Process in PPTM describes every aspect of the application that is involved in a policy, procedure, method, or course of action. Review the interaction of the application with interfacing systems and verify compliance in security models or ensure firewalls are in place to protect the application from external applications, users, business
Tools in PPTM describe every aspect of the application that deals with a concrete technology or product. Ensure the right hardware and environment exists to support the application and that the application interfaces with recommended technologies appropriate to your intended policies and procedures. Verify the application and infrastructure are
Measures Measures in PPTM describe every aspect of the application that is quantifiable conceptually, such as the business purpose or application performance. For example, verify the application meets well-documented and well-thought-out acceptance criteria. The application should solve the business problem it is intended to solve. Logs should be meaningful, and you should be able to measure the performance of the application and ensure you can support it.
STRIDE is a methodology for identifying known threats. The STRIDE acronym is
Identity spoofing is a key risk for applications that have many users but provide a single execution context at the application and database levels. In particular, users should not be able to become any other user or assume the attributes of another
Tampering with Data
Users can potentially change data delivered to them, return it, and thereby
Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each
Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to
Also consider if the user's web browser may leak information. Some web browsers may ignore the no-caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser just in case it leaks or
Finally, in implementing persistent values, keep in mind that the use of hidden fields is
Denial of Service Application designers should be aware that their applications may be subject to a denial-of-service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users and not be available to anonymous users.
For applications that don't have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, and to avoid exposing large files or unique links per user in order to prevent simple denial-of-service attacks.
Elevation of Privilege
If an application provides distinct user and administrative roles, then it is
PDIO comes from Cisco Systems and stands for
planning, design, implementation, and operations.
Sometimes it's important to consider the potential challenges at each stage of a project. You might find this framework useful as you look at a new application and think ahead to the upcoming challenges. There might be a problem, for example, if system administrators are