Posted by: Arian Eigen Heald
Admins and Auditors, Compliance, Data Breaches, Database, Database security, DataManagement, Identity theft, IT audit, Oracle, PCI DSS, SAP, SAS 70, Security, SOX, SQL Server
So many financial auditors, CEOs, CFOs and others rely on electronic data to understand the complexities of General Ledger, Accounts Payable, etc. In this era of SAP, ADP, electronic time clocks, etc., the one common denominator is the database underlying each application.
Applications aren’t something you just run on one PC anymore (I know I’m preaching to the choir, here). Financial applications, especially, are all networked, and the storage is usually a relational database like Oracle, MS SQL, Sybase, DB2 or MySQL. Relational databases are wonderful for business because you can correlate so many different facts.
So why are they so scary to me? Because they are rarely audited.
I need a network ID to log in, so the database is safe, right? No.
The application has security controls, so my database is safe, right? No.
DBAs (Database Administrators) know exactly what I am talking about here. All those items are just the outer edge of security. If I have a network jack and a database ID and password, I can bypass those controls easily.
Some applications have a database ID and no password, or an easy-to-guess password. And very frequently, that ID has access to everything, including reads, writes and deletes.
If I have that ID and a network jack, I can log into your database using ODBC, Microsoft’s Open DataBase Connection client software that is installed by default on Windows operating systems. I can use Excel, Access, or other database software to pull all your data out.
Or change your data.
And P.S., connecting with ODBC uses clear text usernames and passwords, which is how I once captured a DBA’s ID and password with a sniffer.
Fortunately for all of us, there are usually other financial controls that can capture errors or changes in the database. Usually.
NEXT: How to Audit Databases