Protect Your Most Valuable Asset: Your Data

Leonardo Da Vinci’s Mona Lisa—probably the best-known and the most-visited work of art in the world—is now on permanent display at the Musée du Louvre in Paris. The painting was stolen in 1911 and, at the time, was believed to be lost forever—but fortunately, it was recovered after two years and returned to the museum.

Since then, several more attacks have damaged the work slightly, and these attacks have put pressure on the Louvre to display one of its most priceless assets more securely. The museum’s solution: lock the painting down in a custom-made, climate-controlled bulletproof glass enclosure. The security layers that protect the Mona Lisa do not affect the user experience of the more than six million visitors who admire the masterpiece every year.

Security versus openness

Like the Louvre, your organization has to protect its most important possession—its data—without affecting its availability to millions of users worldwide. Unfortunately, while an impenetrable security shield works for the Mona Lisa, it might not work for your applications.

The challenge for organizations today is to achieve both security and openness. Now that the Internet and a large variety of systems, machines, and software platforms are replacing closed and proprietary systems, business data has to be widely accessible without risking greater exposure. At the same time, security-related regulations are increasing and best practices are being widely applied. Companies that understand the risks are investing in long-term security improvements and automated regulation processes.

The potential consequences of a security breach can be game-changing. The possible economic impacts can have enormous consequences for the financial health of an organization—and even worse, a loss of credibility can damage a company’s reputation irreparably. Unfortunately, security breaches are not uncommon for organizations of all sizes.

So what can your organization do to protect its Mona Lisa?

The integration of IBM® DB2® for z/OS® and IBM System z® provides the industry-proven foundation for what is probably your best option for balancing data security and openness. Many organizations have found that, from a security standpoint, DB2 and System z offer the most robust database management system, operating and hardware platform. Decades of development and operation have resulted in a state-of-the-art environment where stability and security are part of their design and architecture.

DB2 for z/OS will celebrate its thirtieth anniversary in 2013. Since its introduction, it has defined database-security industry trends by delivering advanced features. DB2 10 for z/OS is no exception; it delivers security, regulatory, and auditing improvements over previous versions. Its new and improved security features alone motivated some of the first migrations to DB2 10 for z/OS.

The ability to separate data access from the administration of security, system, and databases was one highly anticipated feature of DB2 10 for z/OS. Separating security and database administration duties is a critical best practice. The new SECADM authority can be assigned to security administration personnel without allowing them access to any user data. The new subsystem parameter SEPARATE_SECURITY can be set to YES to remove the security-related capabilities of the otherwise all-powerful SYSADM authority.

Similarly, you can use the ACCESSCTRL authority to allow object access management without requiring ownership of an object to also avoid overuse or misuse of overarching authorities like SYSADM.

Clean up user privileges

In organizations that have used DB2 for years, it’s not uncommon to have many overprivileged users or an undesirable proliferation of system administration privileges. Evaluating the effects of revoking privileges can be complicated, and companies might be reluctant to clean up their environments. Often, there is a cascading effect; in earlier versions of DB2, when an administrative privilege was revoked from a grantor, privileges granted to others by that person were usually revoked automatically, which could cause application outages. In DB2 10, you can control this problem by using the NOT INCLUDING DEPENDENT PRIVILEGES clause in the revoke statement, making it safer to clean up your security definitions.

Distributed applications connecting to DB2 for z/OS from heterogeneous platforms is an increasingly important trend in application development. The DB2 Roles and Trusted Contexts database entities are vital in such environments. Each role is granted a group of privileges that are required to perform a defined function, which provides more flexibility and stronger security administration. Roles, which are available only within a trusted connection, can be assigned to users as an extension of their set of privileges.

A trusted context addresses the problem of establishing a trusted connection between DB2 and a remote requester, such as an application server. A connection can be identified as trusted based on previously defined attributes. Trusted contexts and roles provide improved security for remote requests, helping to reduce exposures without requiring changes to applications. For distributed applications, DB2 for z/OS also supports encryption techniques including Secure Sockets Layer (SSL), IP Security (IPSec), and Advanced Encryption Standard (AES).

Use encryption to protect offline data

Data must be protected when it is offline as well. Data encryption on disk and tape is made possible thanks to z/OS cryptographic capabilities such as Data Encryption Standard (DES) and Triple DES Secure Hashing Algorithms (SHA). As an integration example, some storage controllers can encrypt sensitive data in place with encryption techniques that are designed to have no performance impact and to be transparent to applications.

Leverage monitoring and auditing features

Monitoring and auditing capabilities are fundamental to discovering unexpected data access behaviors. The auditing facilities available in DB2 for z/OS have been improved in Version 10. Audit policies let you define criteria for the events to be audited, which helps to improve user access monitoring. These policies can be made granular enough to monitor a specific authority identifier, and you can start or stop them for greater control over when data is collected.

Learn more

Locking down valuable assets can work for Le Louvre and the Mona Lisa, but it might not work for your business. Your mission is to design and implement systems that are both secure and open—and DB2 for z/OS provides the ideal foundation.

For an excellent, to-the-point source of more information, refer to the IBM Redbook® Security Functions of IBM DB2 10 for z/OS.