Spotlight on Oracle security

Keeping your company's data and systems secure is a must for any Oracle DBA. Beyond patching known security flaws, there is a great deal you can do to protect your Oracle DBMS and applications from security breaches, both from inside and outside your organization. All this month, SearchOracle.com examined security issues and how they impact Oracle products and users. This special report compiles news, analysis, white papers and expert advice on this topic, including breaking articles and content from our archives, to help you conquer your daily security challenges. We've also updated our popular learning guide on Oracle security -- browse through it for even more tips and advice on passwords, encryption and more.

• NEW! Mr. Know-IT-All's Oracle Security Challenge: Mr. Know-IT-All is back. This time he wants to find out how much you really know about Oracle database security. So, if you're up to it, take Know-IT-All's new Oracle Security Challenge today!
  
• NEW! Oracle expert warns of weakness in PL/SQL: A well-known Oracle bug hunter says the wrapping mechanism used for PL/SQL -- the flagship language used in Oracle databases -- can be unraveled, exposing sensitive data.
  
• NEW! Oracle's summer update fixes 65 flaws: The database giant released 250 patches covering myriad platforms such as Application Server, PeopleSoft and JD Edwards. But roughly 10 patches are on hold.
  
• NEW! Oracle owns up to patching problems: Oracle says many platforms and mountains of source code have forced some patching missteps, but the database giant argues that its program is not as bad as critics suggest.
  
• Oracle beefs up database security at Collaborate '06: Oracle's new Database Vault and Secure Backup offerings promise to make it easier to avoid internal threats and automate and encrypt disk-to-tape backups.
  
• Oracle fixes 36 more vulnerabilities: Reducing its load from the previous quarter, Oracle has released 36 patches for vulnerabilities in its various products.
  
• Collaborate '06 Preview: IOUG's Kaplan on RAC, security, mobility and more: IOUG president Ari Kaplan explains what's on tap for the Collaborate '06 Oracle users' conference in Nashville.
  
• Database 10g Release 2 preview: Oracle's Mark Townsend talks about the new XML and security features found in Database 10g Release 2.
  

• NEW! Survey: DBAs not planning for downtime: Companies need to do more to reduce the amount of database downtime resulting from both planned and unplanned events, a new IOUG survey finds.
  
• NEW! Five best practices for Oracle applications developers: A refresher on some best practices designed to make sure that apps developers don't go messing up production boxes.
  
• Locking down your sensitive Oracle data: Kenny Smith makes a living trying to break into database systems and is successful most of the time. He offers some advice so that yours won't be one of them.
  
• Basic database security guidelines: Can you briefly outline some simple guidelines to ensure that security requirements are made a part of any Oracle upgrade plan?
  
• Introduction to Oracle database security: This white paper explores some basic but important Oracle database security issues. It describes who might hack your system and what kinds of data are most sensitive to attack.
  
• Fundamental precautions for Oracle DBMSs: While many companies think they're being proactive with security, too many are addressing security at the application level rather than the database level, according to Oracle security expert Arup Nanda.
  
• Setting up security for the listener: Can I set a policy for a listener on the server side, so that only users from specified IP address can connect to my database, and all other IP addresses will be denied?
  
• Restricting a user's access: I'm trying to restrict access to a database via a trigger after logon to the database. I've got a sly end user and when he connects, the name of the program is not shown in the v$session view, so he can log in skipping over the validation.
  
• Preventing connections to the database: Is there a way with Oracle 8.0, 8i and/or 9i to prevent connections to the database from certain applications?
  
• Manage your security openly: Open security. Sounds like an oxymoron, doesn't it? Security is truly a secret business, so how can it be managed openly?
  
• DBAs should beware the hacker they know: Aaron Newman, co-author of the Oracle Security Handbook, talks about ways Oracle DBAs can defend themselves against trouble, and warns that the biggest threats are often closer than you think.
  
• Hack-proofing Oracle databases: This white paper on Oracle database security focuses on thwarting intruders by seeing an attack through the eyes of a hacker.
  
• Best practices for secure user creation: Should we design a table containing multiple usernames and corresponding encrypted passwords in the database, or should multiple database-level users be created?
  
• Closed vs. open security policies and permissions in an RBAC role hierarchy: Can you please explain to me why closed security policies provide better protection than open security policies?
  

• Cryptography in the database: The last line of defense: This book excerpt presents a start-to-finish blueprint and execution plan for designing and building -- or selecting and integrating -- a complete database cryptosystem.
  
• Defense tactics for SQL injection attacks: The rate of application intrusions continues to rise, and many result from SQL injection attacks. However, while SQL injection holes can be easy to exploit, they can also be simple to defend against.
  
• Setting up password values: What are the best practices for setting up the password values and other parameters within the dba_profile table?
  
• Proof of installed security patches: We are being audited by our internal security group and I have to prove that I have installed Oracle security patches from Alert #68. How do I prove that these patches were installed on Unix and Windows servers?
  
• Method for securing data when using SQL*Plus: Our management is concerned with the fact that developers using SQL*Plus have sensitive data moving in the open between the client and the database. Any advice on methods of dealing with this problem without buying the very expensive Oracle Advance Security option?
  
• Disallowing obvious passwords: We are currently using Oracle's password function verify_function as part of security in a 9i database. I would like to go further and disallow several hundred obvious passwords (e.g., password#1) that could still meet verification standards.
  
• Accessing applications from the Internet: If you have applications installed on an application server running on an internal network and you want to access them from the Internet, there are a number of methods to do this, but the underlying concern is of course security.
  
• Checking table changes: How can I check which table is updated/inserted by which machine/user at what time, using LogMiner or auditing?
  
• Security guidelines for different user groups on Unix: I am currently researching how best to secure our database environment. There will be a number of different databases on the database server, each with its own DBA and developers. What are your recommendations with regards to Unix users, groups and security?
  
• Relying on the system to grant system objects: Our 9i databases now have the "07_dictionary_compatibility" set to false for security (Sarbanes-Oxley) purposes. However, we need to rely on system to grant us these system objects as we encounter them. Are we missing some role/privilege as a DBA?
  
• How to scramble salary data?: Are you aware of a way to scramble salary data? Our production instance has all the appropriate security that we need, as we limit developer and user access. However, with our development and test instance clones we would like to be able to give our support staff wide access.
  
• Renaming accounts for security: Can default database accounts still active in the system be renamed to increase security?
  
• Using roles/grants vs. public synonym: What is the difference between these two approaches? Is there any question of efficiency or security?
  
• "Grant failed" error with password file: I created a password file for my database by using oradim -new -sid db7 -intpwd db7. I have four users. When I grant sysdba to one of them, I'm getting the error "ORA-1994: grant failed: cannot add user to public password file." Why is this error given?