Insider threat to data security

Referring again to the  Verizon 2010 Data Breach Investigations Report, it shows that 48% of data breaches involved some sort of insider in the organization.
Two example of this were reported on the Office of Inadequate Security website recently. Both cases allegedly involve insiders abusing their access privileges to data.

• Twelve indicted in $10 million bank fraud conspiracy operated by a “network” that included bank employees.
• Bank employee accused of selling account numbers.

The lesson here is that all data access must be audited. The audit information must be stored in a secure location in order to allow for report generation and, if necessary, to carry out forensic analysis at a future date. Once an appropriate data access policy is implemented, employees should be advised that it exists. This in itself acts as a deterrent to anyone thinking of wrongfully accessing or modifying data.

Another database compromised in Ireland

Irish recruitment website Recruit Ireland was taken offline on the Feb 8th following the discovery that it's database had been compromised and it is suspected that names and email addresses were stolen for spamming purposes ( Data breach at recruitment site )There are no details yet of how the attach on recruitireland.com took place or when it took place.

On Jan 10, the website of the political party Irish Fine Gael was hacked and 2000 email addresses were stolen from it.

  

Here are few point to consider on the topic of securing the data in your databases:

• Database security is the poor cousin of network security and PC/laptop security. The networks are locked down with firewalls. PCs/laptops have virus scanners, personal firewalls, spyware protection, etc. It's no longer enough to rely on these security measures at the perimeter of the organisation in order to secure the data in the database.  A website that displays / adds / updates data in the database can provide that attacker with a route into the database.
• Remember if one laptop gets stolen you loose all the data on that laptop but if the intruders make it to your database then all your data is compromised. 

So

 

Carry out a security audit on your database(s) to discover:

• Who (people) / what (applications) uses them
• What data they look at / change
• What level of access to data that each user / application has
• What level of access to data that each user / application actually require
• Who are your privileged users (DBAs, system administrators, developers, applications) and how can you monitor what they are doing? 
• Follow a check-list to lock your database down (e.g. change default passwords, close old accounts, etc.)

 
Having your database locked down is not then end of the story. You need to actively maintain it's security and monitor it for suspicious activity.

• Keep database software patches up to date. If you run a 24/7 operation this will require a lot of planning because more than likely some downtime will be required.
• You will need to audit the database activity in order to have an audit trail for forensic analysis if a data breach occurs.
• Protect your audit trail from privileged users.
• Actively monitor database activity to identify any suspicious activity and notify the system administrators in real time. The last thing you want is to discover a data compromise days or weeks after it happened at which stage your customers know about it before you did.
• Audit the activity of privileged users (DBAs / application). Administrators may not like the idea of being monitored but if there is a data breach then they will be suspect. If a clear audit train exists then the administrators can be ruled out quickly.
• Identify unusual changes to the database schemas. This may indicate that an attacker is copying data into a table that they created in order to get it out of the system.
• Consider encrypting your database data files. If the intruder has access to your operating system but not your database then they could steal the database data files and extract the data from them without having logon credentials to the database. It makes it more difficult but this is still possible.
• Encrypt your database backups. If not then an intruder could steal your backup and restore the whole database on their own system.

There are more steps to secure and monitor the database but these ones above are just to get people thinking about what should be done. It will cost time and money to properly secure the data in your databases but this must be compared against the cost of a data compromise - cost of tidy up, fines & reputation damage.

Fine Gael and database security

Yesterdays hack of the Fine Gael website (http://finegael2011.com/) has highlighted the need for individuals and organizations who collect  personal data in Ireland to be aware that they must to take all steps that they can to protect this data.  Full details on these obligations can be found on the Data Protection Commissioners website www.dataprotection.ie.

There has been no details of the security vulnerability that was exploited yet but to me it sounds like a SQL Injection attack.

Verizon 2010 Data Breach Investigations Report

I have just looked through the Verizon 2010 Data Breach Investigations Report http://www.verizonbusiness.com/resources/reports/rp_2010-data-breach-report_en_xg.pdf

It was published 6 months ago but there are 2 interesting points in it for me

The first point comes from "Table 7 Types of compromised assets by percent of breaches and percent of records" on page 39. It shows that while the database server accounts for 25% of compromised assets it accounts for a huge 92% of compromised records. This shows that once the attacker gets to your database they have access to the crown jewels.

The second point comes from "Figure 42. Cost of recommended preventive measures by percent of breaches" which shows the cost of implementing the preventive measures once the breach was discovered. The cost to prevent 64% of the breaches was considered "simple and cheap" . This counters the argument that it would cost too much to implement full data protection policies. "Figure 43. Categorization of recommended mitigation measures by percent of breaches" goes on to shows that 66% of breaches could have been prevented by "Configuration change to existing assets" and "alter existing practice".

Attackers will generally go for the lowest hanging fruit and from this Verizon report it looks like there is still plenty of it around.

Database Activity Monitoring tools

After reading up on Database Activity Monitoring (DAM) tools over the last few weeks I have come up with the following observations about them to help anyone who wants a quick overview of DAM tools. All this information can be found on the vendor websites. They all do things slightly differently and I stand to be corrected if I have misunderstood anything.

The vendor list includes:

• Guardium http://www.guardium.com/
• Imperva http://www.imperva.com/
• Sentrigo http://www.sentrigo.com/
• AppSecInc http://www.appsecinc.com/
  

DAM tools have come about from the requirement to audit who is doing what in the database. Of course, it is possible to use native auditing (i.e. audit by using database functionality) but then you run the risk of the DBA tampering with the audit logs if, on the off chance, they are that way inclined. Separation of duties is required by most compliance standards so the auditing must be under the control of someone outside the DBA department. This is where DAM tools come in because they site outside the database and are controlled by an individual in another department (possible the audit & compliance team). Separation of duties in this case actually benefits the DBA because if there is a security breach then the DBA's involvement can easily be ruled out. If the DBA had control over the database and the audit information then there would always be a suspicion that the DBA could have done it and had altered the audit logs to hide the tracks.
So from this, it is obvious that native auditing will not satisfy the "separation of duties" requirement and this is where DAM tools come in.

In general, DAM tools can monitor database activity at two points - on the network or on the database host server. Depending on the vendor, they may be used separately or in combination with one another.

Monitoring the database SQL that passes over the network has the advantage that there is no load put on the database server but the disadvantage is that they have no knowledge of local connections made to the database. A network based DAM tool will require new hardware to be attached to the network to sniff the traffic.

To overcome this shortcoming of a pure network based solution it is possible to install an agent on the database host to monitor the local traffic to the database. This agent will work in conjunction with the network sniffer. The obvious concern with an agent is that it will have a performance hit on the database server so to keep the load on the database to a minimum these agents simply relay audit data back to a central location where it can be monitored and / or analyzed.

If the DAM tool is purely a software solution then no network sniffer is required. However, you will still need somewhere to store all your audit data.

Once you have the ability to monitor all database traffic, then the next step is tell your DAM implementation what exactly you want to monitor and what to ignore. There are GUI interfaces for this. I haven't played with any evaluation copies yet so that is all I can say.

When the rules are in place, you will have a system to monitor who is accessing what on your databases and you can set up alerts to tell you when suspicious activity takes place. You may also be provided with pre-configured reports to assist you with all the various compliance checks.

So far the implementation is a passive one for monitoring who is doing what in your database and reporting on suspicious activity. It is possible to extend this solution to actively monitor so that pre-determined suspicions activity can be blocked in much the same way as an application firewall blocks traffic. We have now moved from a system that purely monitors to one that can take action. This can be referred to as a database firewall.

A neat use of active monitoring is "virtual patching" where by a rule can be put in place to prevent a known database vulnerability being exploited by blocking the traffic if it looks suspicious. The ultimate solution to vulnerabilities is to apply the patch but when dealing with critical databases there are usually change control processes in place that require proper testing of any software patch. This results in a time lag between the release of the patch and it's application to the database which will leave the database exposed to newly discovered vulnerabilities. A DAM rule can be put in place to recognise when an attempt is made to exploit a known vulnerability and so the database connection can be blocked and the incident reported (i.e. a virtual patch is in place to protect the database). The database administrator has now been given some breathing space in order to get the patch on to the production in a controlled manner.

Some things to consider when evaluating a DAM tool:

• Impact on the database server (CPU and memory)
• Can it handle encrypted client-server communication
• Does it need encryption / description keys to see encrypted traffic
• Can it see what SQL a stored procedure executes or does it just record that a particular stored procedure has been run.
• Can it track what an application user is doing when pooled connections are being used.
• Where is the audit data stored and is the location tamper proof?
• Does it store the complete SQL statement in the DAM data repository? If so you run the risk of keeping sensitive data in your DAM repository.
• Pre-configured reports to help with compliance regulations

M.Sc research and Database Activity Tools

I officially finished by M.Sc yesterday after a full 12 months of study. The last task was to give a presentation on my research paper to 2 examiners. All went well so I am hoping for a good mark. The research was on a completely different topic to database security but does has some relevance to IT security in general - the title was "On-line text-independent writer verification system and its vulnerability to forgery". In a nutshell, I built a system that can use a piece of a person's handwriting to verify if they are who they claim to be. I then evaluated how the system coped with forgery attempts as the forger learned more about how the writer actually writes (i.e. start off with nothing, then get access to a photocopy of the writing and then get access to a video recording of the writer writing the text).

Over the last week I have started to do some research on Database Activity Monitoring (DAM) tools, database firewall tools and vulnerability scanners. The vendor list includes:

• Guardium http://http://www.guardium.com
• Imperva http://www.imperva.com/index.html
• Secerno http://www.oracle.com/secerno/index.html
• Sentrigo http://www.sentrigo.com
• AppSecInc http://www.appsecinc.com

More on this later ....

IRISS Conference 2010

I plan to attend the Irish Reporting and Information Security Service conference in Dublin on 18-Nov-2010. Full details are at http://www.iriss.ie/iriss/iriss_conference_2010.htm

I will be interested to hear what Billy Hawkes (Data Protection Commissioner) has to say because it is his office that will drive awareness of the need to protect data if he follows the lead of the The Information Commissioners Office in the UK
( http://www.cervello.co.uk/2010/08/data-security-regulation )

Also of interest will be The Business model of Cybercrime: Where does all the money come from? because Robert McArdle has the same M.Sc as I am just finishing (M.Sc in Security and Forensics Computing)