If you look at the recent trend of companies trying to ensure the security of their computing environments by building security teams that are tasked with creating company-wide security policies, you will usually find one thing they all have in common. This commonality is the extreme emphasis on network and perimeter security and the lack of policies pertaining to securing individual database servers or databases.
Countless network engineers of all types are taking their tests, studying up on the latest network security software, changing their business cards to read Security Engineer, and writing pages of network and desktop security policies. All this activity is good and should be encouraged, but you have to ask yourself “What happens if the bad guys get inside the perimeter?” or “What stops an attack that is designed to look like normal operating procedures?” Too repeatedly security groups and security policies exclude critical, but easily accomplished internal security measures by ignoring the security needs of the company is databases and applications.
It is with this over-site in mind that I have created this book. Looking back at some of the major Oracle and SQL Server threats and attacks that have taken place over the last few years, I have easily come to the conclusion that none of them should ever have taken place. I mean, how hard was it to put a sa password in place that would have prevented Spida from taking place, and how much time do you need to apply a security patch when the patch that would have prevented SQL Slammer was issued 6 months before the worm attacked?
These attacks were successful due to the fact that most companies have not taken database security needs into account during their quests to protect their perimeters from attacks or have left database and application security needs and policies up to their database administrators and developers, who often do not have the time or the authority to make large-scale security changes. As we can tell from the SQL worms and the multiple SQL injection attacks that have gained notoriety in the last few years, this approach of leaving everything up to the DBAs doesn’t seem to be working.
This is not because the DBAs do not have the knowledge level required to secure their databases; it is usually because database security is a lesser concern for a company. The DBAs are not given enough time or resources to adequately test all the service packs and security patches that are issued, nor do they have the authority to override all the business owners, box owners, or managers that are hesitant about installing a patch or service pack because they are afraid something might break in their applications after the upgrade and create downtime for their business units. To put my two cents in, I believe all security teams should have Database Security Engineers assigned to them.
The primary job of this Database Security Engineer is the protection of all the companies’ databases, and this protection should extend from the smallest Access database to the largest mainframe DB2 database. These Database Security Engineers should have the authority to review all new security vulnerabilities, audit existing database installations, advise database and application architects on security issues and override business owners’ concerns about the installations of critical security patches. When you get right down to it, most of these concerns could be addressed when a database DBA has the time to thoroughly review a new service pack or critical security patch, test that patch, and understand how that patch would interact with current application code and processes.
Database Security Engineers should be the defining resource used to create database security policies for each type of database platform used in the company and for each type of programming code used for custom applications accessing that database within the company. Having answered the question of who should control your database security policy, let’s get back to the question of why you should have one in the first place. If you have spent any time moving around during your career in I.T. you have probably run across more than one place that doesn’t have anything written down.
Standards do not exist and administrators and developers just seem to do what they want too. Even when these companies have a lead in place that keeps things under control, as soon as that lead moves on any standards usually undergo radical changes as the next person takes over and wants to do things their way. It is important that companies slow down and understand the importance of developing company-wide sets of standards and policies, and these policies development must make their way down to the database level. Not only should you be able to audit databases across your company and know the usage of tables, columns, and stored procedures based on their names based on database standards documentation, you must be able to determine if the latest security vulnerability affects your databases by knowing that each database is secured to a certain level.
You cannot easily do this unless you have a security policy in place. Database security policies are, amazingly enough, usually not very complex in nature. If fact, most companies already have a large portion of the typical database security policy already in place. Nothing radical is needed to protect most of the database platforms in existence today, just a few changes in the way your developers think and maybe a little education on how to change common methods to more secure ways of doing things. One of the main points of your security policy should be the act of moving from database server logins to Windows authentication or any other operating system authentication. This task is often one of the things that developers complain about the most because often those developers have never taken the time to investigate Windows authentication and are only complaining because they just do not know a different way.
Once they understand the security concerns with using Oracle and SQL Server logins and find one or two methods to use operating system authentication in their development, those complaints go away, and the company takes a giant step towards better database security. As described above, it may be easy to spend time and come up with the perfect database security policy. It is often something else altogether to get that policy fully implemented. All existing companies will have databases, custom applications, or third-party applications that have been in development before the standards were created and therefore may not meet the new standards. Unless you can get your managers to approve the hundreds or thousands of development time needed to retrofit all existing new applications to the new standards, which is usually not very likely, you will have to create a phase-in segment for your policy.
Allow the current applications and in-progress projects to remain with a few non-standard pieces, but mandate that those pieces are changed as new revisions are created. I have been at companies that have created or changed standards and wanted everything changed right then and there, and at companies that allowed the new policies to be changed in existing projects over a period of time.
It was usually the second company that achieved their results, as the current developers had time to learn the new techniques. New developers only learned the new way of doing things, and project managers and project owners were not suddenly faced with hundreds of unaccounted-for hours added to their projects in order to meet the new standards. So create your policy and implement as much of it as you can right away, probably the vast majority of the policy, and allow the rest to be phased in overtime.
When you want to make a strong Oracle DBA career then you should be aware of database services and other database technology. Without having knowledge of Oracle internals, Oracle performance tuning, and skill of Oracle database troubleshooting you can’t be an Oracle DBA expert.
This expert DBA Team club blog always provides you latest technology news and database news to keep yourself up to date. You should need to be aware of Cloud database technology like DBaaS. All Oracle DBA tips are available in a single unique resource at our orageek. Meanwhile, we are also providing some sql tutorials for Oracle DBA. This is the part of Dbametrix Group and you would enjoy more advanced topics from our partner resource.
