Database Crime Scene Prevention

Imperva's Amichai Shulman looks at database attack and defense.

Some types of attacks leave no trace in the internal database audit trail. For example, most of the database communication protocol attacks display this behavior. Other types of attacks can be launched after abusing vulnerabilities in the internal auditing mechanism. In this example (http://www.imperva.com/resources/adc/adc_advisories_ms_sql.html) an attacker was able to connect to a MS SQL Server database without his account name being registered by the audit mechanism.

In summary, as long as the audit trail is based on internal database mechanisms it is rather straightforward for an attacker to remove any trace of his covert activities and identity.

How to Stop an Attack One Step at a Time

Now that we understand the steps a perpetrator would take to make your database the scene of a crime, let's take a look at the steps that can be taken toward crime prevention. For each of the five steps, there are mitigation techniques that would interfere with a would-be perpetrator's attacks. While no single mitigation technique is in itself fool-proof, it is important to employ a range of mitigation techniques in what is known as a "layered security" approach. By following these recommendations, your database environment will become much more secure.

Because it is neither practical nor cost effective to limit the accessibility of tools, we will skip Step 1 -- Tools of the Trade.

2. Stop Initial Access

The following steps can be taken to protect your database and prevent a perpetrator's initial contact.

  • Apply internal network access controls to the database server. Make sure that workstations cannot access non-database services on the database server machine.

  • Do not allow anonymous access control to your database server.

  • Remove or block default accounts.

  • Change the default password for those default accounts that cannot be removed or blocked.

  • Apply proper password policy to database accounts. Enforce "strong" password policies.

  • Put in place mechanisms that will detect in real time exhaustive searches of credentials. These attacks are easily identified by a large number of failed authentication attempts in a relatively short time frame. Put in place mechanisms to block network access of machines trying to perform exhaustive credentials search.

3. Halt Privilege Abuse

Take steps to control access and usage to ensure that legitimate commands are not used in unauthorized circumstances, etc.

  • Apply context based access controls. These mechanisms allow you to define access privileges based on the following criteria:

    - Network address of the workstation

    - Client software

    - Time of day

    - OS user

  • Apply query level access controls. These mechanisms allow you to define the criteria allowed in database queries and structure of queries, thus avoiding bypass of some client-side application logic.

4. Prevent Privilege Elevation

Take steps to prevent the perpetrator from becoming a DB Admin or Root -- with all the attendant privileges associated with these privileged accounts.

  • Deploy a database IDS/IPS solution with the following capabilities:

    - Reactive protection: detect and block known vulnerabilities based on a frequently updated set of signatures

    - Proactive protection: detect and block abnormal protocol messages possibly representing database network communication protocol attacks.

  • Apply query level access controls.

5. Don't Let Them Cover Their Tracks

Finally, if all of your other mechanisms fail to prevent the crime, you and the authorities will want an audit trail that fingers the perpetrator. Deploy an independent database audit mechanism. This approach ensures that logging does not affect database performance and that an attacker cannot tamper with the auditing mechanism once connected to the database server.

Tags cybercrimedatabase

Show Comments