Two Sides of the Same Coin: The Convergence of Security and Compliance

Published
  • March 12 2008, 2:30pm EDT
More in

Security and compliance issues will continue to dominate IT initiatives as long as valuable data on customers, employees, patients and business financials is exchanged and stored. Historically, security teams focused on protecting sensitive data, and compliance teams focused on controlling its usage. These disciplines are actually two sides of the same coin. Regulations and mandates worldwide are validating this viewpoint, requiring security and compliance teams to work together. While this challenges many organizations, the advantages of an integrated approach include reduced costs, improved efficiencies, robust security and compliant controls.

 

Multiple Regulations and Mandates

 

A growing number of mandates complicate matters. The U.S. has have Sarbanes-Oxley (SOX), the Payment Card Industry Data Security Standard (PCI), California Senate Bill 1386 (CA SB 1386), the Health Insurance Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley Act (GLBA), and other. Mandates in Europe include PCI as well as the European Data Protection Directive (DPD) and the Basel Capital Accord (Basel II).

 

In certain mandates and in some parts of PCI, compliance requirements are vague. The process of interpreting requirements against a unique IT infrastructure presents a daunting project. In this article, I will use PCI as an example to provide guidance across a range of regulations and industry mandates.

 

Protection and Control of Sensitive Data

 

Organizations must protect sensitive data and ensure that all access to and usage of sensitive information is controlled. In PCI, sensitive data includes credit card information, while in others the list includes digital identity data, personal health records, employee records and business financials. PCI states that companies must “protect cardholder data” and that “logging mechanisms and the ability to track user activities are critical.” Section 10.3 describes required audit trail entries. Section 10.5 requires organizations to “secure audit trails so they cannot be altered.” This data is often accessed through enterprise resource planning (ERP), customer relationship management (CRM), e-commerce and applications. Thus, many regulations and mandates address multiple tiers of IT infrastructure, from the database through the application to the Web interface.

 

Application Data Security and Compliance Lifecycle

 

As regulations proliferate, a split approach to IT security and regulatory compliance won’t work. Organizations need a more rational and efficient mechanism to meet multiple requirements across both security and compliance. With a sound process, it is possible to meet multiple mandates. The following application data security and compliance lifecycle offers a simple four-step approach.

 

 

Step 1: Discover and assess. First, find systems that store sensitive data and conduct a thorough risk assessment of those systems. From a security perspective, organizations must find configuration problems that create or fail to close vectors for attack. From a compliance perspective, they must find configuration problems that undermine systems integrity, which is essential for policy creation and the setting of data usage controls. PCI requirement 2 warns against using “vendor-supplied defaults for system passwords and other security parameters” to ensure that systems have no back-door vulnerabilities that could be used to bypass security or auditing and logging functions and controls.

 

In conjunction with this exercise, organizations need to identify which users normally access sensitive data and how they need to do so. Requirement 7 of PCI requires businesses to “Limit access to computing resources and cardholder information only to those individuals whose job requires such access.” This information is necessary to understand the baseline of legitimate behavior in order to create policies and controls around that baseline.

 

Using tools to automate the discovery and assessment process will greatly reduce the effort involved. Look for the following capabilities:

  1. Built-in guidelines to identify best practice security and compliance violations.
  2. Automatic profiling of user activity to save time and allow for legitimate changes.
  3. Sufficient reporting so that you can group the data by user, database object or other factor.
  4. Multivendor, multiversion environment capabilities to ensure the tool works across database systems.

Step 2: Set controls and policies. The second step is to set security rules and audit controls that log user activity and enforce data usage policies. Again, our example of PCI has more specific guidance. PCI 10 addresses tracking and auditing requirements while PCI 7 sets access control requirements on a business need-to-know basis. Further, PCI 8 requires that all actions taken on critical data and systems be performed by, and be traced to, known and authorized users.

 

Policies must be sufficiently fine-grained to provide security, yet flexible enough to allow for changes in user responsibilities and infrastructure over time. Controls and policies should define and control the following:

  • The set of tables each user may access,
  • The tables that contain sensitive data and require stricter policies,
  • The users allowed to execute privileged / maintenance operations,
  • The business activities (sets of tables and operations) for each user,
  • The queries applications use to interact with the database, and
  • The time of day and applications used to access the database.

Step 3: Monitor and enforce. Once policies and controls are established, all database activity must be monitored and policies enforced. It is important to determine who followed and who violated the policies, determine when violations occurred and establish that alerting and enforcement mechanisms operated as intended. The information must be comprehensive and specific enough to make decisions as to the effectiveness of individual policies and determine the overall control of sensitive data.

 

Both compliance and security personnel want data rolled up into reports so that they can easily recognize deviations and drill down to inspect individual transactions. Compliance officers monitor on a periodic basis, while security personnel typically want data in real-time. With PCI, both compliance and security must be addressed. In requirement 10.6, logs must be reviewed “at least daily.” In requirements 7.1 and 7.2, the controls must occur in real time.

 

Step 4: Measure. Step Four represents the visible output of the activities in the first three steps and provides a feedback loop for step one. The reporting function must clearly present information in the formats expected by security personnel, audit personnel, management and third-party organizations that evaluate compliance and security standards.

 

For compliance, there should be built-in reports to address more than one mandate and an ability to generate custom reports. For IT security, the reports must enable them to identify and monitor suspicious activity or take remedial action as necessary.

 

Deficiencies in the Existing IT Toolkit

 

Built-in database audit tools are insufficient to address all of the requirements of compliance mandates. For example, the audit logs used by databases to support business-critical applications such as Oracle E-Business Suite, PeopleSoft and SAP do not always provide information on the person responsible for each database transaction. The key compliance requirements for audit and security include the following:

 

 

Independence. Independence is a fundamental concept of security and auditing. Anyone can be tempted to steal credit card information for a quick, high-profit sale on the black market. The actions of privileged users, including database administrators, system administrators and developers, must not impact the impartiality of the audit trail. PCI requires this in section 10, as does SOX and nearly every other mandate related to data integrity or data protection.

 

Accountability. Database logging technology was not designed to track usage originating from multitier and Web-based applications. Many applications use what is known as a “pooled login” to access databases. As a result, traditional database auditing products only know which application authenticated to the database but do not identify the actual user. This handicaps compliance initiatives and frustrates security and forensics efforts. PCI 8 specifically requires identification of the individual that accessed key systems and data.

 

Granularity and scope. PCI requires a detailed audit trail that not only identifies the individual user but also includes complete query details and the attributes of the response. Consider the following hypothetical audit records for John, a call center customer service agent.

  1. John requested data from the customer database and the database returned data.
  2. John requested first names, last names, email addresses, phone numbers, and credit card numbers for all customers from the customer database and the database returned 634,577 records.

Assuming that John is authorized to access individual customer records during the normal course of his work, the first audit record does not reveal unusual activity. The additional detail in the second audit record makes it clear that a suspicious event has taken place. Accessing the personal information of 634,577 customers is probably outside the scope of John’s position.

 

Detailed transaction logging is beneficial, but it can overwhelm processor, disk and I/O resources. Look for a tool that uses a distributed storage and processing architecture that allows it to scale. Also, make sure that your audit log tools track unsuccessful database queries, which can signal attempted break-ins.

 

Material exceptions. Audit logs generate lots of data, yet material exceptions are what auditors want to review. To locate material exceptions, a reviewer of traditional audit logs must possess a certain level of expertise and a lot of patience, as the review can take days or weeks to complete.

 

Look for technology that understands policies and normal activity to distinguish material exceptions. It should also provide drill-down views when needed. This technology should detect the structure and behavior of applications, examine activity and create baseline policies for each user’s legitimate data usage. Ideally, the policies are automatically updated such that the technology, not human resources, identifies and reports on material variances.

 

A New Class of Product for Your IT Toolkit

 

Data activity monitoring (DAM) products will provide an integrated framework that automates the four-step data security and compliance lifecycle and overcomes the deficiencies inherent in compliance-only and security-only tools. A number of vendors offer these products, and each uses a slightly different approach. Look for products that offer the following baseline capabilities.

  • Ability to identify unique application users and accurately track their activities.
  • Ability to enforce “separation of duties.” Look for a product that tracks and logs the database administrator’s (DBA’s) access and does not require the DBA in order to operate.
  • Ability to issue compliance reports across several mandates and regulations.
  • Ability to provide both audit logging and real-time alerting.
  • Ability to identify material exceptions and policy violations, and provide drill-down information.
  • Ability to provide a combination of out-of-the-box, manually customizable policies and automatically learned policies. This greatly eases rollout and ongoing management.
  • Ability to detect and adapt to legitimate changes within applications and databases. This removes the need for constant manual tuning.
  • Ability to operate transparently without IT infrastructure impact or special coding requirements when applications and databases change.

Watch Out for Web Applications

 

Database controls can be subverted through Web applications. A malicious person can access a database under cover of an application, in effect as the application. Given the application’s privileged access status, the activity would not be detected as suspicious and would not be flagged by traditional database audit logs.

 

This is why PCI 6.6 offers a choice: Either install an application layer firewall or have application code reviewed by an organization specializing in application security. While code reviews are a good idea and are consistent with development best practices, calling in consultants to review all application code entails significant cost and won’t provide the continuous protection an application firewall provides.

 

Convergence of Data Security and Compliance

 

To meet data security and compliance mandates, organizations must be able to answer the tough questions from management and auditors:

  • Who touched the data?
  • What data was touched? When? How?
  • Was it altered? Added? Deleted? What was the original value?
  • Did our protection mechanisms and policies work as planned?

Database activity monitors and Web application firewalls help answer these questions while providing security and compliance across multiple mandates.

 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access