Protecting the Data - A Security Checklist

Protecting the Data - A Security Checklist
At the end of the day, what needs to be protected is the data. While Blue Core Research is in the business of Oracle database security, one must never lose sight of the ultimate goal – protecting the data itself.
This page does not aim to be the ultimate guide to data security, but it should raise many of the important points you should consider in your security strategy
Go to page123All

Security by Domain

There are many approaches to securing data, and a good security strategy will combine several of them. Looking at security from a domain perspective has the benefit of lining up with the organizational teams. This approach requires each domain to be properly secured to achieve good security.
Each domain must be secured to only allow authorized personnel access, and only for the purposes for which they were authorized. The security must also be performed at the primary location, backup location, DR location, in the cloud, in offices and branches, etc.
The main domains to cover are:
  • Physical Security – secure physical access to servers, storage, network terminals, desktop terminals, etc.
  • Network – secure the internal network, firewalls, VPN, wireless network, etc.
  • Application – secure both purchased and internally developed applications
  • Database – Oracle databases, SQL Server databases, etc.
  • Host – secure Unix & Windows servers (DB servers, app servers, file Servers, mail Servers, etc), failover servers, desktops, and laptops
  • Storage & Backup – disks, storage arrays, backup tapes (both online and archived)
  • Users – ensure only correct individuals are authenticated, and are authorized only for the resources required to perform their jobs
  • Admins – only required personnel have admin access, and their activities are monitored
  • The Human Element – one of the most weakest aspects of any secured environment. From helpdesk personnel resetting passwords, through tailgating people into the building. Awareness & training to help reduce people being tricked into doing things they shouldn’t

Security by Shells

Another common approach to security is by placing additional barriers the closer you get to the data:
  • Perimeter – Perimeter security separates the internal organization from the rest of the world. It is the firewall that protects your network, the access cards in the entrance to the building, etc. A good perimeter security will significantly reduce the risk of an outside attack. It is, however, not sufficient.
  • Internal – Once inside the organization, additional security measures can compartmentalize individuals and activities. For example, an access card to enter the server room, internal firewalls and routers, etc.
  • Authorized – Once individuals are authorized access to a system, they should only be able to perform specific tasks.
  • Administrator – Some individuals administer the systems and have unlimited access. Activity auditing should be applied to ensure they do not abuse their access.
These barriers can be done in each security domain, or by combining security from the different domains (e.g. you cannot use the application unless you are on the internal network).
As you can see, the deeper you get, the more lax the security becomes. This is unavoidable to a degree since heavy preventative security deep in the organization will prevent people from doing their jobs. Complementing to preventative security is detective security (such as auditing). Detective security does not affect how people perform their jobs, but alerts when they violate certain rules.
Additionally, the deeper you get, the more vulnerable the systems become – logging into a system without credentials can be impossible, while compromising it once authorized can be significantly easier.


Isolating sensitive data is an extension of security by shells. Isolation allows placing of additional security barriers around sensitive data.
When isolating sensitive data, it is important to consider the exact location of the perimeter. The perimeter should protect as few systems and users as possible, yet include as many of the consumers of the data as possible.
While sensitive data sometimes need to go beyond the perimeter and be protected outside of it, it is best to limit those external exposures and protect them as much as possible.
Defining the location of the perimeter around the sensitive data is therefore an important and delicate balancing act.

Security by Obscurity

Security by Obscurity refers to security that is based on the notion that an attacker would not be able to understand its design or implementation. It has become synonymous with no security based on the assumption that any design or implementation can eventually be discovered. It is also dismissed because it calls for complex designs and implementations that are difficult to maintain and support.
However, many companies today already have complex systems for various reasons. While those complex systems exist there is no reason not to leverage their complexity as an additional security barrier.
For example, if your organization has dozens (or hundreds) of applications and databases moving data between them as part of a big process, that complexity can prevent internal fraudsters from being able to compromise the overall process. That complexity will also hinder an external attacker, and provide a good means of separation of duties for administrators.
All it takes is to ensure that the different teams that maintain, support, and administer the different subsystems, do not have unneeded access to or unneeded knowledge of other subsystems.


Encryption can help reduce many risks. It should not be the only means your security relies on, but it is a good tool that should be used.
Encryption can be performed at different levels and by different systems, each having different benefits and limitations.
Encrypting data at rest is about encrypting data stored on disks, tapes etc:
  • Application – The application can encrypt all the data it saves. While uncommon for all data, it can be important for highly sensitive data
  • Database – Databases can encrypt all the data they store. This can be very valuable in many cases, including a stolen disk drive, stolen backup tape, copied database file, etc.
  • File System – Some file systems have encryption capabilities. This is not a common thing to use.
  • Disk – Encryption at the disk level is pretty rare, but can be important in the case of laptops
  • Backup – Most backup systems have encryption capabilities, and it is very important to do this
Encrypting data in motion is about encrypting data transmitted over a network:
  • VPN – Virtual Private Networks allow connection between two trusted networks over an insecure medium (such as the internet). Preventing users from connecting from home would be preferable, but given the reality, a VPN is the next best thing.
  • Hardware (NIC) – Encryption at the network card level is uncommon in wired networks, but very common (and vital) in wireless networks
  • TCP/IP – Encryption at the TCP/IP stack level is not very common, but has benefits in certain environments.
  • Database – Network encryption of all database communication can be important in many environments.
  • Application – Network encryption at the application level is not common except for certain types of applications (e.g. https and ssh)

Find the Weak Links

An important thing to remember is that anyone attempting to breach your security will have a different perspective about it. This perspective will ultimately determine which system will be targeted, and how. The perspective is comprised of:
  • Goal – is the attacker looking for an easy mark to boast about? is he trying to go after a specific type of data (e.g. credit cards)? go after a specific organization? or, perhaps, go after a specific type of data in a specific organization?
  • Skill – does the attacker have expertise in networks, Oracle databases, Unix,… ?
  • Position – does the attacker work for the organization? does he have credentials to certain systems?
  • Chance – did the attacker happen to run across someone’s password? find a bug in an application? read article discussing system vulnerabilities?
An attacker will choose the path of least resistance from his perspective to breach through what he considers to be the weakest link. That means that a network expert and a database expert will look for, and exploit different vulnerabilities. The same applies to an employee vs. an external hacker.
A good exercise is to explore your systems’ vulnerabilities from different perspectives. This can teach you a lot about what links would be considered weak by attackers.
Since you cannot be an expert in every domain or pretend to have skills you do not posses, it is important to consult domain experts in your organization with the appropriate skills. Use an informal personal meeting with such people to gain their perspective about your security.
There are six “tests” that should be evaluated by each expert:
  • Using their current knowledge of the systems and current privileges, what fraud or data theft could they accomplish?
  • What fraud/theft could they accomplish with additional privileges (e.g. a manager, an administrator)?
  • What fraud/theft could the accomplish with additional understanding of the system (e.g. a developer or the architect of the system)?
  • What could they accomplish without privileges or knowledge of the systems (e.g. a regular employee)?
  • What could they accomplish as a non-employee working from the outside?
  • What chance information would help them commit more fraud/theft (e.g. someone’s password, system documentation, application bug list)?
If you ask different experts in the same domain you are likely to get different answers, so the more interviews you conduct, the better understanding you will have of the vulnerabilities in your security strategy.

Final Checklist

Make sure that as part of the evaluation of your security strategy you have:
  • Evaluated the different security domains with the appropriate teams
  • Ensure all users can be properly identified and authenticated, have the right permission on the right systems, have a good process for approval of new privileges, and a good process to ensure those privileges are revoked when needed.
  • A continuous education plan for different teams to reduce the risk of the human element
  • A good perimeter security, and compartmentalization inside the organization
  • Isolation of sensitive information with a tight security barrier around it
  • Employ encryption in the appropriate places
  • Audit the activity of systems that process sensitive information
  • Discuss with appropriate domain experts what are the weak links in your strategy

What's next?

I want to know more about Core Audit!
Great! Here are a few options:
  • Read more about Core Audit features, reports, etc.
  • Try our Online Demo and play with Core Audit right now
  • Ask for a Personal Demo from one of our experts and get all your questions answered
  • Download a Free Trial and experience Core Audit on your systems
I only want more information, not a product
Not a problem, here is a list of relevant pages, and we are always available to answer any question
  • Intelligent Auditing – Read
  • Oracle security – strengths & weaknesses – Read
  • Large security scope in Oracle databases – Read
  • How to prevent a database breach – Read
  • Oracle database security – Read