Friday Feb 28, 2014

February Edition of Security Inside Out Newsletter, Now Available

Get the latest edition of our bi-monthly (that's every other month) Security Inside Out newsletter featuring both database security and identity management news. This month's articles:

SANS Study Explores Maturity of Security Strategies Among Healthcare Organizations

A new report from the SANS Institute, a leading security education and research organization, surveys real-world organizations to discover how the healthcare industry is adapting to this new security landscape. Find out how organizations like yours are responding to the new challenges of more-stringent regulations and new mobile and cloud technologies.

New Report Puts Oracle Audit Vault and Database Firewall to the Test

A new report from leading security organization SANS Institute finds that Oracle Audit Vault and Database Firewall successfully achieves three key security objectives: audit collection, SQL traffic monitoring, and security event reporting.

Key Cloud Security Paradigms and Oracle’s Identity Management Roadmap

Find out the most common approaches to achieving security in the cloud and whether using a third-party identity management solution is a good strategy. 

Read more here

Bitcoin Exchange Files Bankruptcy in Wake of Cyber Attack

There are a lot of interesting nuggets to pull from the downfall of Mt. Gox, but the Christian Science Monitor sums it up under "What it All Means":

Mt. Gox serves as a reminder that you're not just buying Bitcoins; you're also involved in the company performing the exchange. There are no watchmen to answer to, and things can go downhill quickly if a breach happens. It's not an isolated incident, either: In 2012, the exchange site Bitcoinica was hacked for over $460,000 worth of Bitcoins, according to The Verge.

If you're not familiar with the story, Mt Gox (Picture Source: The building that houses the Mt. Gox offices in Tokyo. Photo: Ariel Zambelich/WIRED) was targeted by hackers who stole around $350 million in Bitcoins over a two year period and they have stopped exchanging bitcoins as of Tuesday.

The building that houses the Mt. Gox offices in Tokyo. Photo: Ariel Zambelich/WIRED

Wired has a great write-up here on the exploit and alleged repercussions and predictions of the attack, some of which have already come true: bankruptcy. The hackers exploited a bug in Mt. Gox's website, but it's not clear exactly what they did at this point:

Now, according to the alleged leaked document, it looks like hackers had been exploiting that bug for two years, and even removing bitcoins from supposedly secure “cold” wallets that the company had stored offline. Typically, cold wallets are disconnected from the internet and cannot be emptied by online attackers. However, the “cold storage has been wiped out due to a leak in the hot wallet,” the document states.

Wired is referring to this leaked document.  Analysis at the end of the document says "Expertise to find: Analysts, top class developers (crypto), IT security expert..." I'll say they need an IT security expert. 

There's more to learn on this one. 

Thursday Feb 27, 2014

Part 3: Controlling Data Access and Restricting Privileged Data in Oracle Database

This is the third post on controlling data access and restricting privileged data in Oracle Database, pulled from the free ebook, Securing Oracle Database 12c: A Technical Primer. Here are the first and second posts. The book highlights new security features found in Oracle Database 12c; however, the majority of the solutions are applicable to earlier Oracle Database releases as well.

Users with Administrative Privileges

Certain users can connect with special administrative privileges, such as SYSDBA and SYSOPER, to allow maintenance operations even when the database is not open. These users can authenticate using a network-based authentication service such as Oracle Internet Directory or based on membership of the connecting user in a particular operating system group.

If a user must connect with administrative privilege using a password for authentication, the password is stored outside the database in a password file, which is administered using the orapwd command. User management functions such as locking an account after multiple failed login attempts are not available for users in the password file, although each failed attempt will cause an exponentially increasing delay to limit password guessing when the database is running.

Proxy Authentication and Authorization

Sometimes administrators need to connect to an application schema to perform maintenance. Sharing the application schema password among several administrators would provide no accountability. Instead, proxy authentication allows the administrators to authenticate with their own credentials first and then proxy to the application schema. In such cases, the audit records show the actual user who performed the maintenance activities. This form of proxy authentication is supported in Oracle Call Interface (OCI), JDBC, and on the SQL*PLUS command line. Here is an example where the user app_dba is allowed to connect to the database and act as hrapp.


Now the user app_dba can connect using his own password and assume the identity of the hrapp user by proxy as follows:

CONNECT app_dba[hrapp]
Enter password: <app_dba_password>

Stay tuned for more. Or, you can read ahead by downloading the complimentary ebook here. Also, let me know if you are enjoying these posts by adding comments below.  

Friday Feb 21, 2014

Part 2: Controlling Data Access and Restricting Privileged Data in Oracle Database

This is the second post on controlling data access and restricting privileged data in Oracle Database, pulled from the ebook, Securing Oracle Database 12c: A Technical Primer. The first post can be found here. The book highlights new features found in Oracle Database 12c; however, the majority of the solutions are applicable to earlier Oracle Database releases as well.

Storing Passwords

Users are expected to provide the password when they connect to the database, but applications, middle-tier systems, and batch jobs cannot depend on a human to type the password. Earlier, a common way to provide passwords was to embed user names and passwords in the code or in scripts. This increased the attack surface and people had to make sure that their scripts were not exposed to anyone else. Also, if passwords were ever changed, changes to the scripts were required. Now you can store password credentials by using a client-side Oracle wallet. This reduces risks because the passwords are no longer exposed on command-line history, and password management policies are more easily enforced without changing application code whenever user names or passwords change.

To configure password storage using an Oracle wallet, set the WALLET_LOCATION parameter in the sqlnet.ora file. The applications can then connect to the database without providing login credentials, as follows:


Stay tuned for more. Or, you can read ahead by downloading the complimentary ebook here.

Thursday Feb 20, 2014

New Blog Focused on Oracle Advanced Security

I wanted to let folks know that Todd Bottger, Oracle's product manager for ASO, has a new blog on Oracle Advanced Security. He'll be taking the conversation a lot more technical, so go subscribe to learn more.

Wednesday Feb 19, 2014

Controlling Data Access and Restricting Privileged Data in Oracle Database

In a series of blog posts I will be pulling excerpts directly from the ebook Securing Oracle Database 12c: A Technical Primer by Michelle Malcher, Paul Needham, and Scott Rotondo. Previously, I posted the introduction of the book and now I will continue with the first chapter: Controlling Data Access and Restricting Privileged Users. If you don't want to wait for each post, I encourage you to download your own free copy of the book.

Controlling Data Access and Restricting Privileged Users

The most fundamental step in securing a database system is determining who should be able to access which data. This chapter describes the management of user accounts and the mechanisms for determining the access that each user has. It continues with a discussion of the types of privileged access that a user may have and available tools for removing any additional access they do not need.

User Management

All access to the database is through users, whether these are administrative users, application accounts, or regular users. As the users have direct connection to the database, it is important that they are properly authenticated and have appropriate roles, and that their accounts cannot easily be compromised. It is also important to ensure that there are proper resource constraints on their usage, or else the rest of the database may be indirectly affected.

The CREATE USER statement is used to create a database user and its associated schema. In the following example, the user is identified by a password, and the account follows the policy specified by org_profile.


A profile specifies a named set of resource limits and password parameters that restricts excessive consumption of system resources and enforces constraints on the passwords. The password-specific parameters provide password management including account locking, password aging, password history, and password complexity verification. The password verification function is perhaps the most important control to ensure that users pick complex passwords, making it difficult for intruders to guess them. The FAILED_LOGIN_ATTEMPTS parameter limits brute-force password-guessing attacks by locking the account after a specified number of incorrect logins.

 FAILED_LOGIN_ATTEMPTS 6 -- attempts allowed before locking
 PASSWORD_LIFE_TIME 180 -- max life-time for the password 
 PASSWORD_VERIFY_FUNCTION ora12c_verify_function; -- Password complexity check

The dictionary views DBA_USERS and DBA_PROFILES describe the users and profiles, respectively. The privilege to create users must be limited to the DBA or the security administrator. Each user should have an assigned tablespace; otherwise, any objects they create would go into the SYSTEM tablespace, thus creating contention between the data dictionary objects and the user objects.

Oracle Multitenant Database Users

Oracle Multitenant, an Oracle Database 12c option, includes both common and local users. A common user is created in the container database and has the same user name and password in all of the pluggable databases that are part of the container database. The common user can have privileges that are granted at the container level, and other privileges that are granted in each pluggable database. The privileges can be different in each of the pluggable databases, but the user doesn’t need to be created in each pluggable database.

To create a common user for the container database and all of the pluggable databases, log in to the container database as SYSTEM and create a user with CONTAINER=ALL. Note that all common user names begin with the prefix C##.

Enter password: **********

A local user, on the other hand, is created in the pluggable database, and does not have access to the container. This is good for the administrator who manages a pluggable database but does not manage the overall system. To create a local user, connect to the pluggable database as SYSTEM, create the user, and grant the needed roles and privileges as before, but specify CONTAINER=CURRENT instead of CONTAINER=ALL.

Enter password: *********

 Stay tuned for more...

Tuesday Feb 11, 2014

Webcast with ISACA - Want Better Data Security?

Insecure database silos make protecting data challenging and costly. Increasingly, organizations find that database consolidation and private cloud initiatives reduce complexity, risk, and drive down the cost of protecting data and meeting regulatory compliance. 

In this webcast, you will learn how to:

  • Consolidate databases securely
  • Address database security at the infrastructure level
  • Adopt a defense in depth strategy 
Watch Now and learn the controls needed to safeguard your mission critical enterprise data.  

Sunday Feb 09, 2014

Oracle Data Redaction Article in Oracle Magazine

Another nice article on Oracle Data Redaction (part of Oracle Advanced Security). This one by Arup Nanda, Oracle ACE Director. Hide from Prying Eyes is found in the latest edition of Oracle Magazine. 

Wednesday Feb 05, 2014

Recent Breaches Prove Risks to Retail Industry Higher than Ever

Recent retail data breaches serve as a sobering reminder that the retail industry continues to be a key target of cybercriminals in 2014.

In fact, according to the recent Verizon Data Breach Investigations Report, nearly a quarter of all data breaches occurred in retail environments and restaurants.

What can retailers do to lower their risk?

Know Who Wants Your Data

The Verizon report demonstrates that there exists a relationship between industry, attack motive, and threat actor. Payment card data is often stolen from retailers by organized criminals from many different geographies. They are going for volume and so should you. Protect your biggest targeted assets first – your databases.

Know Where Your Data Resides and Who Has Access

Common attacks leverage legitimate user credentials to access sensitive databases and steal sensitive payment card data. Implement controls around what users have access to and enforce least privilege, especially in consolidated environments. Also, audit database activity to detect and stop unauthorized activity as well as collect critical forensic data that might be needed.

Develop a Security Inside Out Strategy

Despite following PCI DSS requirements, data breaches are a constant reminder that compliance is not enough to thwart a motivated attacker. Assess your existing controls to identify your company-specific vulnerabilities that put your organization's data at risk.

Oracle suggests retailers adopt a defense-in-depth approach to protect sensitive data from the inside out and future-proof against evolving regulatory requirements such as the new Payment Card Industry Data Security Standards.

To learn more about Oracle’s Security Inside Out approach and assess your data security posture for potentially disastrous vulnerabilities in your environment, please contact your Oracle Security account team to setup a complementary consultation. 

Nice Article on Oracle Data Redaction

Gavin Soorma provides a nice article on the new Data Redaction feature in Oracle Database 12c (and backported to 11g R2). Very nice blog-demo, complete with explanations and screenshots.

Who are we?

Follow us on

  • TwitterFacebookLinkedIn


« February 2014 »