Details

Written by Dave Nelson

Category: Blog

Created: 27 September 2009

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.

Details

Written by Dave Nelson

Category: Blog

Created: 21 September 2009

Securing an enterprise resource planning (ERP) application such as SAP or Oracle’s E-Business Suite (EBS) can be a daunting task. ERP environments are massive collections of databases, applications and interfaces to other systems. Just trying to figure out what is core to the ERP suite itself can be difficult.

I personally am not a database administrator (DBA). I know enough SQL to work my way through an audit, build reports and generally follow a technical discussion. What I cannot do however is build a schema from scratch or do heavy performance tuning. But that’s ok. From a security standpoint we don’t need to be an expert with every possible application or infrastructure component.

When considering security for an ERP you really have three layers to worry about. Infrastructure, which includes your servers, OS, firewalls, routers, etc. would be the first layer. The second layer is the database layer which includes the data dictionary, tables, fields, etc. The third and final layer is the application with which end users interact with the database and create records or transactions. The focus of this article is the actual database layer. We focus a lot on the infrastructure and applications so I wanted to shed some light on the actual database.

Note: Commands in the following sections refer to Oracle environments. They may need some tweaking for other databases such as Sybase, MS SQL or MySQL.

So in such a complex environment, where do we begin? Let’s start with simple user access. In an ERP system, user authentication will often be done within the backend database environment. This is a good place to start looking at security. Running the command SELECT * FROM DBA_USERS will provide you listing of all the users of the database. This includes attributes such as password, default tablespace and profile. With this you can begin a review to see if there are any stale users or potential shared accounts.

Another good query is SELECT * FROM DBA_PROFILES which will list out all the profiles and their attributes. This is a great method to determine the settings for profiles and begin to look at actual user access.

Once you have the users and profiles enumerated you can then move on to roles. Run SELECT * FROM DBA_ROLE_PRIVS and SELECT * USER_ROLE_PRIVS. You can now compare a user with their role and determine their core level of access.

With this information you should be able to begin building a basic security profile of the system. Does every user have the Sysadmin role? Have any of the profile option defaults such as SignOn:Notification been modified? If you have little confidence in security at the user access level you might as well skip going further. There is simply no way to ensure data integrity if you can’t control who has access to that data and what they can do with it.

Hopefully this will help you in your attempts to tame the beast which is ERP. I’ll provide some additional tips later this week.

Details

Written by Dave Nelson

Category: Blog

Created: 14 September 2009

One thing I've noticed over the past year is that the majority of information on the web relating to digital forensics is geared toward two audiences. The first is law enforcement and the second are consulting firms. This makes complete sense. Law enforcement probably does more evidence collecting and review that anyone else and most companies don't need (or want) a full time forensics team. So it completely understandable that the bulk of materials cater to these groups.

What concerns me is how underserved those in corporate incident response are by the larger forensics community.  Even if incident response at the corporate level is a small market, it is a market nonetheless. Many times companies want to add these capabilities to their in-house arsenal but have no idea where to start. If you are in that camp....keep reading. This article is just for you.

Companies which are considering adding digital forensic investigation capabilities in-house need to ask themselves several questions upfront.

1. Why do we need this capability?

2. Who's going to provide the services and where will they report?

3. Is the cost to purchase and maintain a lab and provide continuing education worth the expense?

Questions 1 and 2 are typically easy to answer. Number three is more difficult. A typical 1 week engagement from one of the well know consulting groups like IBM, Deloitte and others can easily surpass $10,000. Can you provide this in house cheaper? If you plan to do investigations once or twice a year, probably not. If you plan to do it once or twice a month, then likely so. Many times though we forget to look at all of the costs associated with standing up a unique environment like a forensic lab. It shouldn't be hooked to your network which creates management concerns around patching, updating, etc. The hardware most likely will be vastly different that what you purchase for other needs. If you choose to utilize commercial software packages they must be continually updated and software maintenance is a must.

Once an organization decides to offer these services, some immediate steps need to be taken to ensure uniformity in your investigations. An incident response plan must be developed which lays out who can request or initiate an investigation, what the grounds for cause are, who can perform the investigation, who sees the results and what actions should or must be taken based on the outcome. One thing organizations must protect against is the witch hunt mentality. You've got suspicion someone is up to no good but nothing more than that. Just a hunch. I advise my clients never to start an investigation this way. Make sure there is always a reason to investigate. Last thing you want is for your employees to feel there is a culture of mistrust and accusations within the organization. At best your morale will sink to new lows. At worst you could be sued by employees for harassment, privacy or other accusations.

The next thing to guard against is who can call for an investigation. I usually like to see a 2nd level manager be in the approval chain. Let's say Bob is an employee who's manager suspects he's creating fraudulent transactions. If Bob works for Sally and Sally works for Meg then Sally would make the request for investigation and Meg has to approve it. This again helps reduce the chance for a witch hunt and ensures a level of accountability in the process.

You'll also want to make sure investigations are only completed by those who've had some specialized training in acquiring and handling evidence, digital forensic processes and reporting of results. I wish I could say you'll never have to worry about your internal investigations ending up in civil or criminal court but I can't.  You should always approach new cases as having the potential to have aspects of civil or criminal law to them. This will save you a lot of headache later.

In terms of who should have access to the final reports, that will vary by organization. Needless to say it should be restricted by need to know. Also remember that many times an initial investigation will lead to one or more follow on investigations and the fewer people who are privy to this fact the better.

So as you begin to build a forensic unit within your organization, here are some things you'll want to consider.

1. Develop an Incident Response Plan prior to doing any investigations

2. Create a dual or dotted line reporting structure to maintain independence

3. Build a self-sustaining lab and staff it appropriately

4. Create a set of criteria for requesting and initiating investigations to ensure objectivity

5. Build a communication framework for investigators to ensure they have support of executives, HR and Legal.

6. Develop a plan for when and how to call for outside help including law enforcement or more experienced investigators.

By following these steps you'll be well on your way to providing these services in house. I can't promise everything will be picture perfect. In fact I can almost guarantee at one or more points along this path you'll wonder if this was the right decision. Adding forensic capabilities to your internal service offering will change the culture at your organization. Make sure you're leadership, all the way to the top, are on board and understand this decision.

5 Ways to Build Your Case with Digital Evidence

Use this guide to understand how a digital forensics investigator can support your work in a variety of legal scenarios.