The subject of a response to a breach is huge; there are many factors that must be taken into account as part of the investigation and also going forwards after the initial breach and into the fixing, correction, protection phase.
This is a huge subject that cannot be done detailed justice here as a blog BUT lets dive in and discuss the high level points of investigating a breach of an Oracle database. We will go through roughly chronologically at a high level and at the end bring in some elements that should be done now in advance:
- Planning : In advance of any breach you should take some actions.
- Appoint an incident response co-ordinator : Identify someone who will manage the response when it happens. This ideally should not be someone deeply involved in a breach. I.e. the DBA sounds like a good option BUT they will be needed in the response at a technical level and they could potentially be part of the attack
- Identify and create an incident response team : Create a team in advance that will be put into action as soon as a breach occurs. Where that team knows what to do and how to do it
- Create an Incident response process : Write down the steps that should be taken under any potential breach so that a structured response can be taken
- Create a toolkit : Build a toolkit to use when a breach occurs that is validated and tested and where everyone knows how to use them
- Provide Training: Ensure that all of the response team in advance of a breach are trained on how to respond to a data breach in an Oracle database and trained on how to use the relevant tools and how to review and analyse data that can be part of the breach
- When a potential breach occurs verify it : If a breach is reported then the first step is not to disrupt business initially and verify that it really is a breach. How to do this is different based on each breach. For instance if someone says that personal data was breached and that data was for sale on the dark net or being promoted for free on public social media sites. In this case if we can show that the data is really ours - by content and order then we can get started and agree there is a breach. Another example could be that evidence is shown that someone is selling data or taking data out on disc or other means. This step is different per breach and we are trying to prove that the breach is real
- Enable the Team : Once we know the breach is real, enable the team. The team co-Ordinator takes charge of everything and works to a check list that is your incident response process
- Don't initially disconnect and switch off : The first reaction can be to disconnect the database from the network or pull the power cord. This may reduce the further risk BUT it removes the change to get all transient data
- Perform Live Response : Collect the live data that is held in memory; users logged in, contents of current SQL and more
- Collect less transient data : Collect the less transient data
- Collect other data : Collect other relevant data such as server logs, web logs and more
- Repeat the process on all servers/databases : Repeat the same process to gather data from all relevant systems
- Shutdown / Disconnect : If its possible disconnect the database and server and shutdown
- Perform Forensic analysis: Now we must build a timeline of relevant evidence and actions from the data that has been gathered in the live response. We must narrow the timeline to the actual breach; when it started and when it ended. Initially this timeline will be much wider but as the investigation grows we will narrow it to the main events that contribute to the breach
- Answer questions : We must answer some basic questions; 1) how did the attacker get it?, 2) What rights did the attacker have?, 3) What did they see, steal? 4) What did they change?, 5) What could they have done with more skills?
- Create a Report : At this stage we cab create a report that summarises the attack and answers the questions and suggests what is next
- Fix, Rebuild or?: If we know exactly what happened we cab decide how to rectify the database and security and applications. The ideal scenario is to fix the database or data and of course security. Rebuilding will be a risk if the backups span the actual attack
- Implement auditing : Implement a detailed audit trail so that any future breach is much easier to investigate and resolve
- Implement data security : My experience is that often data security is not as good as it should be and in some cases its shocking. Implement a good secure data security regime
The above details the high level flow of the actions to take if there is a breach. One thing that pops out of an Oracle database forensic analsyis is that unlike analysis of a PC we cannot simply remove the discs of a database and byte copy them for analysis, for a number of reasons; license?, size, tools to analyse the database as data on disk.
Another key issue is the Heisenberg principal in Oracle. The more we question the database; the more we change the database and change the evidence. We also cannot simply take checksums of discs for the reasons above as we would in a PC analysis.
One of the biggest issues is that if the breach is READ based then without pre-defined database level audit trails in the database detecting any read action is difficult
It is clear that forensic analysis and live response of an Oracle database breach is difficult so it makes sense that training in this area is performed in advance of any potential breach so that the relevant teams know what to do and how to do it. It also makes sense to have tools ready for any potential breach and training in the use of those tools
Quite clearly it makes sense to secure your Oracle database before a breach and have detailed audit trails!!
Plan ahead
#oracleace #sym_42 #oracle #databreach #security #forensics #liveresponse #hacked #audittrail #audit
