For this last point on securing Oracle E-Business Suite (11i) I want to talk about the infrastructure. My last couple of posts have been database specific from a software perspective. I now want to look at securing our databases from a hardware perspective.
Lots of companies deploy internet facing firewalls. They create a DMZ or demilitarized zone which houses their web, email, DNS and other internet facing servers. This DMZ area is virtual wasteland. It’s more secure than the internet but less secure than our internal networks. In essence it really shouldn’t be trusted.
Our internal networks however are usually fully trusted and considered safe and secure. You couldn’t be more wrong. It’s akin to putting up a privacy fence all the way around your property and locking the gate. In this scenario, you assume that your yard on the inside is more secure than the street on the outside but you still lock your front door. Even inside your house you may have important areas secured such as a small safe, file cabinet, jewelry or firearm storage, you get the picture.
What we often do in securing our networks is to put up a fence, lock the gate, lock the front door and then leave the cash, bank info, jewelry, firearms and other valuables out on the living room floor with a huge sign reading “All the good stuff is right here, take what you need.”
Databases are treasure troves of information yet we rarely wrap additional protection around them on internal networks. I recommend every database server should be placed behind a firewall. The access control list (ACL) should explicitly allow only connections from the application servers, backup servers or other critical components. In today’s environments, end users should rarely need direct access to the actual database. They will typically get their access via a web application of some sort.
By limiting direct access to the database you are reducing the chance that someone who can bypass your application and database level logical controls, such as usernames/password, granted privileges, roles, etc. the ability to interface with it on a hardware or system level. Just like putting your jewelry in a safe inside your locked house. Not everyone who needs access to your network needs access to your databases.
As we start to realize that our internal networks aren’t a whole lot safer than the DMZ or even the internet, we need to provide additional security zones. This will help provide another layer of protection for our most critical assets. Does this create a little more administrative work? Does it cost a little more money? Sure. Is it worth it? Only your risk assessment can tell you that. You have done a risk assessment haven’t you?
The ISSA Des Moines Chapter will be hosting a free-for-all hacking event at Iowa State University's Internet Scale Event and Attack Generation Engine (ISEAGE) Lab in October.
The ISEAGE lab will be configured as a model real world environment and opened up for attendees to attack as they see fit. Attendees to the event can work on their or in teams to attack the hosts in the ISEAGE lab. Tools such as Metasploit, Backtrack and others will be available. This is a great way to get some real world experience, learn from peers and network with others in the security field.
Date: Monday 10/26/2009
Location: ISEAGE Lab at ISU
Time: 9am to 2pm
Cost: Free for chapter members, $25 for non-members (if you join at the event, $20 goes toward membership)
Lunch: Provided for all attendees at no cost
If you are interested in attending please contact me by 10/19. We need an RSVP to ensure we order enough food.
So last week I promised to provide more tips on securing and monitoring Oracle E-Business Suite (11i). I wasn’t able to get it all in during the week but I’ll make up for it this week.
One of the key concerns of any security or audit professional is tracking actions which have been taken by end users. This is especially true for tracking administrative access. If you’ve properly provided for separation of duties and limited end user access, a malicious user can only get so far before they need to rely on others to make their planned attack successful.
As soon as you add collusion to the mix of requirements for a successful attack, the risk typically drops for two reasons. The first is you have to have two bad apples. The second is that with more people involved, the larger the footprint. These both lead to a higher chance of discovering the attack and possibly even thwarting it.
Administrators on the other hand have the keys to the kingdom. End-to-end access in some rare (and never recommended) cases. Separation of duties on the technical side is just as important as on the business side. Developers should never have access to move code to production; system administrators shouldn’t have the ability to modify security monitors, and so on.
When configuring Oracle databases there is an easy way to get some basic security auditing information about what your users have done. Running the command SELECT * FROM SYS.DBA_STMT_AUDIT_OPTS; will help you identify if actions taken by DBA or other sensitive accounts are being monitored. If they are not, your first order of business is to turn auditing on. Be careful though as auditing can eat up disk space and processor time quickly.
Another good idea is to run SELECT * FROM SYS.DBA_ROLE_PRIVSWHERE ADMIN_OPTION = ‘YES’; to see which roles have been created with the WITH ADMIN option. This option allows those who have been granted a specific privilege to grant that to others. This is an easy way to let your access security get out of control before you even know the problem exists.
By checking to ensure auditing of privilege account access is turned on and that only very specific roles are able to grant access you are able to lock down your environment and have a small window into the core security of your system.