This action might not be possible to undo. Are you sure you want to continue?
com Someone specializing in computer forensics or network security is not necessarily expert in databases. Yet they will often become involved with the database because, after all, that’s where the data is. This is an overview of how to approach and manage that database, and also to demystify some aspects of a database. First is SQL. Structured Query Language is well known as a computer language specialized in making queries on a database. SQL is also an acronym that some vendors have used in the name of their product; such as Microsoft’s SQLserver or product names such as MySQL or SQLite. You do not need to know SQL and this article is not about SQL. But one cannot discuss the topic of databases without mention of SQL – so let’s just get that out of the way up front. Second is ‘data mining’. This is the same thing as SQL. It is just a little bit more user friendly and descriptive term, than ‘writing an SQL statement’. Data mining, via SQL, provides a view of data inside the database. A huge amount of data is overwhelming to inspect or find anything. So you use data mining (aka SQL) to filter that data – such as ‘show me transactions on December 1 between 6:00am and 7:00am’. Practically speaking there is two distinct types or level of data miners. Data mining at the widest and lowest level is non technical. These are applications made so that marketing people (or finance or legal or….. etc .etc.) can enter parameters and get results – such as sales level of green widgets on Thursdays. This type software is a big business – and these type users generally are not able to hack. But the higher level specialist that sets up that software or writes raw SQL statements is someone that actually is able to touch table data directly. Speaking of data mining; a couple years past you may have read about some creative hacking that involved “SQL Inserts”. That was data mining or sql statements that were being processed by the database that was behind a web application. Many web applications have a web server front end and a database back end. The hackers found that some web applications would pass thru raw sql statements to the back end database so that they could become free lance data miners via the internet site and ask the database to show information they wanted to see. Even though all databases respond to well defined flavors of SQL, there are a lot of different brands of databases. Much like different brands of automobiles they have different features and different price points from the vendor. One could say that Microsoft Access is a pickup truck while Microsoft’s SQL Server (or IBM’s DB2 or Oracle etc etc. ) is an 18 wheeler. They all have different size or cargo ability, and
a differing set of features – plus of course a differing price point. Some database vendors have oriented their product to specific uses while other databases are horizontal and useable across a wide range of industries. Some databases have a user interface, and some do not. A protocol analyzer, a router, and a lot of other devices & applications, typically have an embedded database with no user interface. The user of the product is generally not aware of the database. Developers of those products don’t want to reinvent the wheel creating a database needed to hold data inside the product, so they will license a light and efficient database that already exists in the market. But regardless of all these variations all databases fundamentally distill down to being tables. By ‘tables’ I mean fields & rows. Think of a spread sheet. Fields are left to right and records (or rows) go up to down. This is what a database is – tables. Tables hold the data – and that’s it. Nothing more and nothing less. By demystifying the database to being nothing more than a set of spread sheets, the security specialist can better get their hands around the security issues that might be involved. SQL is probably a language you don’t understand. SQL is the manner in which you look at, and manipulate the data in those tables. The database is not SQL. The database is just a set of tables. A database is fundamentally passive just as a spread sheet is passive. It is an SQL query that will display data that you want to see, or ‘append’ new records, or ‘update’ fields, and take actions that add or delete information in the database. What I am saying is that while a database running a huge operation or giant corporation may take up a significant chunk of a data center and involve millions of dollars of operational cost – one can (and one should) view it as nothing but a simple set of spread sheets. This simplification will help you keep from being intimidated by the database complexity – plus also segregate apart those items to look for inside the database versus those items to look at outside the database. Is your concern that a database has been inappropriately copied? Fundamentally this is not different than whether or not a spread sheet has been inappropriately copied. Is your concern that a database has been inappropriately accessed? Fundamentally this is not different than whether or not a spread sheet has been inappropriately accessed. I invented two concerns about inappropriate copying or inappropriate access of a spread sheet. Can either of these questions be answered definitively by looking at the data inside the spread sheet? No. In fact the data inside the spread sheet doesn’t necessarily give you any insight to those answers at all. So there are definitely limits to what the database itself may contribute to your investigation. A database is just a file (often more than one). An illegal copy/paste isn’t going to change any of the data inside the database. Identity theft, credit card data,
customer data: the topic may differ, the brand of database may differ, but a file copy is a file copy – and it is doubtful if the data inside the database itself will give you a clue to the party that initiated that file copy. So one of your key decision points is whether or not there is a high probability of value to look inside the database itself. If your issue involves data inside the database then you will need an alliance with a professional that is experienced with the brand of database in question. Generally database specialists are just that – specialists. Databases are a deep application and one can spend a career inside one brand. There are fundamental theories and best practices and languages such as SQL which are totally horizontal and common to all databases. But at the same time a database can be a very complicated product set unique to a vendor that change across time/version such that an expert in one brand will be very unproductive working in a completely different and unknown database product. The high end databases have extensive and formal certifications involving weeks of course work. Most professional database analysts will decline to work in a database which they are not certified. Whether or not you can trust the database administrators/designers of the database in question is a human security question outside this article!! The butler did it. If the security issues involve records/data that may have been intentionally deleted and are not viewable by whatever user interface exists for that product then this fundamentally is no different than when criminals attempt to erase a hard disk. Depending on the database’s version and vendor the database (or the underlying operating system) may have some embedded ‘roll back’ capabilities. Plus of course most all databases have routine backups made and archived. Non-stop applications often have mirrored sites which can provide comparative data. Finally, just like the erased hard disk, those able to dissect disk space at the forensic level may be able to find something. Depending on the database’s design and the version from the vendor – there can be a wide range of logging. It may be extensive or it may be nonexistent – and probably somewhere in between. A database typically is password protected, but beyond that point may not log user activity. Some logging is simple time stamping of when a new record is made, and nothing more. Sometimes it logs a change but can’t tell you which field was changed – or tell you what that field’s prior value use to be (hopefully a back up will tell you). In a totally different dimension the normal data inside the database may be the crux of this issue. This is definitely true in accounting forensics. For instance embezzlement often involves lots of low level transactions to shell organizations. Data mining for low level transactions and cross referencing to supplier names and looking for patterns is the key method for finding suspicious behavior. Another example is where we have all read about situations where compromising information was found in emails. This often is found by word & phrase searching.
To wrap up; in some situations data mining and database expertise can be the heart of the security issue resolution. But don’t jump to that conclusion. In a lot of situations the compromise of a database gets no assistance at all from the data inside the database itself. When approaching a new project do not get tangled up by the size or complexity of a database. Simplify the database down to nothing more than a set of tables and determine whether your priority security issues are inside or outside the database.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.