Databases. Databases store the most sensitive information in companies/organizations

Transcription

1 Database Security

2 Databases Databases store the most sensitive information in companies/organizations Larger organizations have often thousands of databases distributed through the entire organization Database software has a similar complexity to operating systems Database vendor ignored security for a long time Patching is complicated (side effects, time intensive)

3 Agenda Presentation is divided into 3 parts Top-5 Security Problems of Databases Controls to Patch Top 5 Security Problems Typical Database Attackers

4 Top 5 Database Problems (Weak) passwords No database inventory Segregation of duties Missing patches Insecure code inside the database

5 (Weak) Passwords 99% of all companies/organizations have weak passwords (password=user, password=companyname,...) Passwords are identical through all databases (know one system password and connect to all DBs) No database vendor has a default tool to check for weak passwords DBAs are not allowed/able to change weak passwords (to avoid side effects) It often takes years to change weak passwords (see next example)

6 The ivory tower architecture Security and Business Rules Simple architecture Clients accessing a database via application server No direct access to the database Security and business rules are enforced in the application server Password change on database and application server

7 The ivory tower solution in the real world S&B rules You have nice data, we will use it Some people must connect with special tools like TOAD New project Another project We need a reporting solution We just do a database link Yet another project Real World Complex architecture All types of clients are accessing the database Security and business rules only enforced in the first application server Passwords are stored in many places. Normally not documented

8 Database Inventory In larger organizations it is normally unknown how many databases there are and what versions/ databases are used. No reliable (single) method to find all databases. Even the database vendors have difficulties to find them during a license audit. There is a average 5-10% rate of unknown databases Most of these development/staging databases are clones of production systems (with real unobfuscated data)

9 Segregation of Duties Different players and responsibilities OS Administrator (responsible for OS Patches, setup,...) DBA (responsible for DB Patches, setup, ) Backup-Administrator (responsible for Backups) Application Administrator (Application itself) Developers (bug fixes code, )

10 Missing patches Applying database (security) patches is often complicated, time-consuming and error-prone A typical Oracle security patch takes on average 4h time to apply (coordination + applying the patch itself) (1,000 DB * 4 h * 4 patches/yr = 16,000 hours) This time does NOT include the time to test the application

11 Insecure Code in the DB Usage of too many privileges Common security flaws like SQL Injection allowing privilege escalation The owner of this custom code (e.g. inhouse developer or 3 rd party SW vendor) is responsible for fixing this problem.

12 Controls to Patch Top 5 Security Problems (Weak) passwords No database inventory Segregation of duties Missing patches Insecure code inside the database

13 Weak Passwords - Controls Perform regular password checks for database and application passwords Document the usage of databases (Who is accessing what/when/ ) to be able change passwords without risk Start analysis (reverse engineering) of database access (e.g. using Triggers or Auditing). Takes often 3-6 months. Divide responsibility for password changes to responsible person DBAs for DBA accounts End user for their accounts Application owner for application accounts

14 Database Inventory - Controls Create an inventory of all databases and keep this inventory up-to-date Document usage of obfuscation of critical data in development /staging and production databases.

15 Segregation of Duties - Controls Train the different groups in database security to increase the awareness of the different groups Create secure coding policies to avoid insecure code from the beginning Add a section to contracts with 3 rd -party software companies to avoid that security patches are handled as change request

16 Missing Patches - Controls Install missing patches as soon as possible Use only supported versions of databases to minimize the amount of database versions Reduce the number of supported DB/OS combinations. Less combinations are easier to test and maintain.

17 Insecure Code in the DB - Controls Secure development training for developers Create secure coding policies Secure coding policies should be part of the contract for 3 rd -party SW-companies Regular review of critical applications Peer review of code

18 Classifcation of Attackers Curious DBA or Employee DBA covering its own faults Criminal employee Leaving employee External hacker Intelligence agency

19 Curious DBA or Employee Type: Curious DBA or employee Scenario: Interested in private/ sensitive information. Samples: Looking up for salary of colleagues, private numbers, s, account status of politician, Supporting private investigators (PI) Known incidents: Miles & More (Employee was looking up what politicians Identification: Mostly select statements, Few/No traces without audit, Difficult to spot

20 Curious DBA or Employee Example: Search data of colleagues SQL> select * from hr.emp where salary > 10000; Example: Search data of celebrities SQL> select * from customers where nachname='tom' and vorname = 'Cruise'; Tom Cruise, , Account 123,123.00

21 Curious DBA or Employee Example: Disable Oracle Auditing and select data SQL> oradebug poke 0x060041BA8 2 0 SQL> select * from hr.emp where salary > 10000;

22 DBA covering it's own fault Type: DBA covering it's own fault Scenario: Try to remove evidence about a (serious) fault. Probably it's not a good approach to ask the DBA to do the forensics Samples: Deleted the wrong user, killed the wrong database session, changed the wrong password Identification: Easier because timeframe is defined, backups / archive logs disappear, Modification of audit-table,

23 Criminal Employee Type: Criminal employee Scenario: Interested to earn money, damage the company, blackmail,. Samples: Getting insider information (stocks, merger&acquisition) Get company secrets (formulas, algorithm, source code, ) Blackmailing companies (with customer data, e.g. black money) Reset bills of friends and families Known incidents: LGT Bank Liechtenstein, Coca Cola recipe, Identification: Attackers invest time/ resources to hide, modifying data (invoice), Longer period affected

24 Example Reset bill of friends aka Friends & Family SQL> update billing set amount=34 where userid=47111; Change Health Insurance account number and bypass SAP completely SQL> update sapr3.tsd1k set blzzs=' ', KNRZS = '35921' where KUSCH=17;

25 Example It is normally easy to follow financial transactions. That s a challenge in (perfect) computer crimes. The following approach steals money without leaving financial traces. The attacker is not stealing money, instead of he is deleting his debts. Apply for credit for a house (e.g. 750,000 CHF) Get the money from the bank and buy the house Pay the rates for the credit for a few months. Set the credit to zero.

26 Leaving Employees Type: Leaving employees Scenario: Get as much data/ information for the new job as possible. Most common attack Samples: Export the production database Get customer reports, pricelists, Identification: Longer timeframe (1-3 month before they left the company), no/little experience in removing traces

27 Leaving Employees Example Extract sensitive data (e.g. using Excel, normal reports ) select * from customers Export entire Database (especially developers) exp.exe userid=grips/grips@grips full=y

28 External Hacker Type: External Hacker Scenario: Steal interesting stuff. Samples: Steal data for a competitor Steal credit card information Steal Source Code Break in just for fun Known Incidents: TJX, Cardsystems, Cisco Sourcecode, Identification: Many traces on the way into the system, attackers often lazy

29 Example SQL Injection

30 Intelligence Agency / Organized Crime Type: Intelligence Agency / Organized Crime Scenario: Get valuable information (military, economic) to protect the country Samples: Steal military data Intercept proposals, financial data, Known Incidents: Lopez/Volkswagen (CIA), ICE (France), Whitehouse/ Bundestag/ (China) Known Suspects: China, France, Israel, Russia, US

31 Intelligence Agency / Organized Crime Examples Buy customer lists with black money (Germany vs. Liechtenstein/Switzerland Stuxxnet

32 Thank you Contact: Red-Database-Security GmbH Bliesstr. 16 D Neunkirchen Germany