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.