This is the second talk that I did at the recent UKOUG conference at the East Side rooms in Birmingham. This talk discusses how you should respond if you think that your database has been breached or if you unfortunately know that you really have been breached.
The main purpose of this short blog post is to introduce the talk and to present a link to the MS Powerpoint slides.
We started by discussing the fact that data is now the new gold rush like the Yukon and Klondike in the 1890s onwards. Data is growing faster than anything and we manage data in Oracle databases and that data is now valuable so becomes a target for theft or damage.
Data hacking and breaches are now an every day occurrence and almost every person now knows what a data breach is. We cover laws like GDPR and the hefty fines that can happen if personal data is stolen. These elements confirm why we must protect Oracle databases and why the data is an easy target now for thieves.
The next part I covered is what do hackers do; steal data (read it), change data (update it) and destroy data (delete it). Also we cover how attackers do this, what do they exploit in your systems and processes to gain access to your data. We also discuss who is the attacker, internal, external, third parties, public? Finally we looked at the methods used to attack the data. These are essentially the open doors that you have left open to allow them in; this could be through bugs in your applications, bad configuration, bad processes and more.
Next we laid out the complete breach handling process and all the steps before focusing in on the breach response team, the leader and how to handle an incoming breach. We finished with a brief discussion on writing a report and how to fix the security and the breached system. Finally we looked at what you should be doing now to prevent a breach and also to add things to make breach response and analysis easier.
Here is the MS PPT slides:
What should you do if your Oracle database is hacked? - link here. Please have a read and be prepared for a breahc before it happens or take action to prevent a breach.
#oracleace #sym_42 #oracle #forensics #databreach #liveresponse #datasecurity
Blog
Pete Finnigan's Oracle Security Weblog
This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.
Top 10 Things to Consider in Securing an Oracle Database
I presented recently at the UKOUG tech conference 2024 in Birmingham, UK at the Eastside rooms. This was a good conference and I had two talks there. This blog is about the first of those and includes a link to the MS Power Point slides as well.
This talk focused on what can go wrong with the data you hold and process in your Oracle database and how it can be vulnerable to attack or rather how the data held and processed can be vulnerable to attack. We also covered some background on data breaches and attack types and we position the task of securing data; we are securing data and not securing Oracle. We briefly covered cloud and of course Oracles security options.
The rest of the talk was to cover the top 10 security things to look at in the Oracle database to secure your data. The spoiler is that there is not a simple list of ten things that you can do in ten minutes that makes your data and database more secure. Its easy to see why this is the case. Oracle is a generic engine that allows you to process any data model and create any applications. So its not possible to have a generic security that just works. The security is part of the development of your data model, tables and code; its your job.
The power point slides for my talk Top 10 Things to Security Review in an Oracle Database are linked here. Please have a look.
#oracleace #sym_42 #oracle #security #databreach #hacking #datasecurity #data #database #ukoug #ukoug2024
This talk focused on what can go wrong with the data you hold and process in your Oracle database and how it can be vulnerable to attack or rather how the data held and processed can be vulnerable to attack. We also covered some background on data breaches and attack types and we position the task of securing data; we are securing data and not securing Oracle. We briefly covered cloud and of course Oracles security options.
The rest of the talk was to cover the top 10 security things to look at in the Oracle database to secure your data. The spoiler is that there is not a simple list of ten things that you can do in ten minutes that makes your data and database more secure. Its easy to see why this is the case. Oracle is a generic engine that allows you to process any data model and create any applications. So its not possible to have a generic security that just works. The security is part of the development of your data model, tables and code; its your job.
The power point slides for my talk Top 10 Things to Security Review in an Oracle Database are linked here. Please have a look.
#oracleace #sym_42 #oracle #security #databreach #hacking #datasecurity #data #database #ukoug #ukoug2024
Is Your Oracle Database More Secure in the Cloud?
I get asked a question often "Is your database more secure if its moved to the cloud?" and it does not matter which cloud we are talking about; could be Oracle OCI or Amazon or...
This is an interesting question from a lot of people over many years. A lot of people / customers are taken in by the association often of the word cloud and security and assume that there is some magical way that an Oracle database or database in general becomes more secure simply by relocating it to the cloud.
Lets be fair the cloud infrastructures now are mature and the interfaces to design and layout and specify security amongst other things are good and the whole infrastructure is probably better than your own in-house IT and servers and local management BUT that is not the whole picture
One big problem is that often customers do not know their data and therefore database is insecure already when hosted in-house and believe that the additional features of the cloud make it more secure.
If you have a database where you process customer data and the applications are littered with security issues such as SQL Injection bugs then does moving to the cloud fox these? - of course not. If you have half your staff accessing the database directly with development tools and reporting tools and more and the people share well known single accounts with rights to access any data then moving this to the cloud does not make the data more secure because half the staff access the data directly and it is therefore insecure. If the application design has made it so all data and code is in one schema then moving to the cloud does not fox this lack of privilege granularity. If the application design has allowed permissions on data and other rights to be the opposite of least privilege; in other words anyone connected can do anything to the data; then moving this design to the cloud does not secure the data. Or, if your DBAs use SYSDBA or oracle or DBA day in day out; then they can access and change anything and moving this to the cloud does not improve the security of the data.
Oracle security is about more than the location of the database; it's about the applications design including permissions and grants and access and the code and the security of the users, the data and the database settings itself. The security of the data is not the Cloud settings and cloud design; it is the database and application and data design.
If you think about this, it is obvious and we must tackle the securing of the data in the database primarily, the users and database settings; this leads to the obvious conclusion that if a database is insecure on-premise it is still insecure in a cloud or vice-versa; if a database is secure on premise then its secure in the cloud.
The cloud security matters but it does not magically make your data secure. In cloud we must also consider what model we are buying; who is in charge of the cloud and services and who is responsible for what? if we allow a third party to manage the database for instance; it is the same as allowing a third party to manage the database on premise or at their location; there is a risk that others outside can access your data directly or indirectly.
Let us be clear, this is not about cloud specifically but about the security of data at all levels of the design and deployment.
An insecure database cannot be magically be made secure by putting it in any cloud; only you can do that with good design, management and processes
#oracleace #sym_42 #oracle #database #security #cloud #data #breach #cloudsecurity
This is an interesting question from a lot of people over many years. A lot of people / customers are taken in by the association often of the word cloud and security and assume that there is some magical way that an Oracle database or database in general becomes more secure simply by relocating it to the cloud.
Lets be fair the cloud infrastructures now are mature and the interfaces to design and layout and specify security amongst other things are good and the whole infrastructure is probably better than your own in-house IT and servers and local management BUT that is not the whole picture
One big problem is that often customers do not know their data and therefore database is insecure already when hosted in-house and believe that the additional features of the cloud make it more secure.
If you have a database where you process customer data and the applications are littered with security issues such as SQL Injection bugs then does moving to the cloud fox these? - of course not. If you have half your staff accessing the database directly with development tools and reporting tools and more and the people share well known single accounts with rights to access any data then moving this to the cloud does not make the data more secure because half the staff access the data directly and it is therefore insecure. If the application design has made it so all data and code is in one schema then moving to the cloud does not fox this lack of privilege granularity. If the application design has allowed permissions on data and other rights to be the opposite of least privilege; in other words anyone connected can do anything to the data; then moving this design to the cloud does not secure the data. Or, if your DBAs use SYSDBA or oracle or DBA day in day out; then they can access and change anything and moving this to the cloud does not improve the security of the data.
Oracle security is about more than the location of the database; it's about the applications design including permissions and grants and access and the code and the security of the users, the data and the database settings itself. The security of the data is not the Cloud settings and cloud design; it is the database and application and data design.
If you think about this, it is obvious and we must tackle the securing of the data in the database primarily, the users and database settings; this leads to the obvious conclusion that if a database is insecure on-premise it is still insecure in a cloud or vice-versa; if a database is secure on premise then its secure in the cloud.
The cloud security matters but it does not magically make your data secure. In cloud we must also consider what model we are buying; who is in charge of the cloud and services and who is responsible for what? if we allow a third party to manage the database for instance; it is the same as allowing a third party to manage the database on premise or at their location; there is a risk that others outside can access your data directly or indirectly.
Let us be clear, this is not about cloud specifically but about the security of data at all levels of the design and deployment.
An insecure database cannot be magically be made secure by putting it in any cloud; only you can do that with good design, management and processes
#oracleace #sym_42 #oracle #database #security #cloud #data #breach #cloudsecurity
