Cache Security- Adding Security to Non-Secure Applications

Caché Security III:

Adding Security to Non-secure Applications

Daryl Flaming & David Lutz22 March 2011

Welcome/FAQ

• What is the purpose of this academy?

– We will take an existing unsecured Web application that processes online purchases and make it secure. You will learn how to apply Caché’s security components to secure this application, how to add credit card data and make it secure, how to encrypt credit card information, and how to re-encrypt the credit card information without any downtime.

• What is the technical level?

– Advanced.

• What are the prerequisites?

– Caché Security I & Caché Security II

• Please feel free to ask questions at any time.

Administrative Notes

• Short-cuts to the TRU Web Portal, Caché Management Portal, Ensemble Management Portal and ODBC Driver Manager are located on your desktop for your use.

• The Username/Password for Caché and Ensemble is student/student

• We will be here for ~2 hours, so there will not be a break

Administrative Notes (Cont)

• If you get stuck on an exercise, please raise your hand, and one of us will help get you back on track

• REMEMBER: There is SIGNIFICANTLY more to Caché, Ensemble, Integration and our Advanced Security model than we will be able to cover in 2 hours, so if you have more specific questions, please feel free to talk to any of us afterwards.

Academy Agenda

Academy Scenario and Overview

Securing the Application

Securing the Connectivity and Information Flow

Securing Data Elements with Data Element Encryption

Questions?

Let’s Get Started…

Daryl Flaming & Dave Lutz

Our Scenario…

Things-R-Us (TRU) LLC, Web Shopping Portal…

• Currently have separate systems that are integrated to “connect customers with product and services”

• Uses over-arching Business Process to manage this “connecting”

• Presents a web portal to expose this new, unified process to customers and management information to employees (Composite Application)

• We want to secure this Integration across the many “touch points” involved

• We want to add Credit Card Data to support “product purchase”

• We want to add data element encryption for the Credit Card Data using the standard for “encrypting PCI-DSS”

Things “R” Us Overview - Initial

Things “R” Us Overview - Final

TRU’s Components

• Identify the major components of our integration:

– (3) External Systems:

① CRM

② Inventory

③ Shipping

– One Web Portal for:

• Customer use for making a purchase

• Employee use for Management Reports and Information

– One Ensemble Production (to tie them all together)

– Totally “Non-secured”, with no distinction between Customer and Employee, and no credit card usage

Let’s Examine the Inventory System

• API(s) and Technologies Available:

– Stored Procedures:

• FindByCode()

• GetLevel()

• RecordSale()

• AdjustInventory()

– SQL Views

– Linked tables/SQL Gateway

Let’s Examine the Inventory System

• Business Operation Concepts:

– Request current On-Hand Stock level

– Request current Re-Order Level

– Request Inventory System to record a Sale and adjust Inventory accordingly

– Request a Re-Order for a Product if On-Hand Stock levels cannot support a requested Sale

Let’s Examine the CRM System


– Web Service


– Request if a Customer is an existing Customer

– Add new Customer to CRM Database

Let’s Examine the Shipping System


– Web Service


– Request shipping service from the external Shipping System

– Receive shipping information details (Tracking Number and Carrier to be used)

Let’s look at the TRU Business Process…

• TRU Business Process Concepts:

– Receive product order from customer

– Verify if customer is already an existing customer with the CRM system

– Assign appropriate discount

– Place order with Inventory System (or request restock)

– Acquire shipping information from Shipping System

– Provide order confirmation to customer

Let’s look at the Web Portal

• Three main functions:

– Order products

– List current orders

– Create a report of orders

• Security Concerns:

• Users should only see the functions and/or the data to which their role(s) entitle them

• They should NOT see menu options or pieces of data to which they do not have access or usage rights.

Exercise #1: Review Current State

Refer to Exercise Handout

• Objective:

– Learn the functionality of the non-secured application

• Outcome:

– Familiarity with the functionality of the non-secured application.

Securing Things-R-Us


Overall Methodology…

• Implement stronger Authentication mechanism:

– Web Portal (adjust Authentication mechanism in Web Application Definition, and implement Custom Login Page)

– External Systems (via Credentials in the Production)

• Implement Authentication/Role-Based Access Control (RBAC) in Web Portal (Users/Roles, Application Roles, Zen Resources, etc.)

• Secure connectivity to External Systems (SSL)

• Implement Data Element Encryption to protect Credit Card Data per the PCI-DSS Standards

Authentication and Authorization approach for

Things-R-Us…

• Things-R-Us is currently running in Minimal security mode (e.g. the UnknownUser account holds %All role, Web Application is set to Unauthenticated access, etc.)

• Add new User accounts (e.g. Bob “the Customer” and Dan “the Employee”)*

• Add Roles that define the level of access we want to provide (e.g. Customer and Employee)*

* Already created for the sake of time available


Things-R-Us… (Cont)

• Add Ensemble Credentials to contain an Identity (Username/Password) for the Business Operation to “use”when communicating with its associated External Systems *

• Configure the ODBC DSN used by our Inventory Business Operation so it does not contain a hard coded Username/Password (which previously left it wide-open for access by other applications and users)

* Credentials are already in use by our Web Service based Business Operations (CRM and Shipping)


Things-R-Us… (Cont)

• Modify the default Web Application Definition for the Things-R-Us (TRU) namespace:

– To use Password authentication (instead of Unauthenticated)

– To use a custom login page (TRU.web.LoginPage.csl)that has the same look and feel of our Web Portal

– To use Application Roles* to provide a level of access to authorized users ONLY in the context of our Application

* Already created for the sake of time available

Exercise #2: Authentication and Authorization


• Objective:

– Apply a number of security measures to various portions of the non-secured application.

• Outcome:

– A partially secured application.

Securing Connectivity and Information

Flow


Securing Things-R-Us Connectivity

• Currently, usernames and passwords for our external connections are being sent “in the clear”

• How do we securely transmit and receive sensitive data with the Inventory, CRM & Shipping systems?

• Secure Sockets Layer (SSL) can provide that secure channel to communicate

• SSL prevents data sniffing, session hijacking, and modifications to data in transit

SSL Overview

• Provides secure point-to-point communication over network

• Allows for:

– Mutual Authentication

– Encrypted Data Transmission

– Message Authentication Checking

Certificates and Keys

• Certificate contains identifying information for entity:

– Name

– Issuer

– Public Key

• Primary purpose of Certificate is to bind public key to identity of private key holder

• Public/private key pair used to encrypt and decrypt data

• Both play vital roles in establishment of secure

connection:

– Data integrity protection

– Exchange of secrets

SSL Support in Caché & Ensemble

• Device Level:

– Caché ObjectScript standard ‘Open’ and ‘Use’ commands can specify a defined SSL configuration to use to secure a TCP connection

open dev:(“localhost”:1000:/SSL=“SSLClientConfig”)

• Application Protocol Classes:

– Parameters to specify the use of SSL and specific SSL configurations

– Available in HttpRequest, FtpSession, SOAP.WebClient

• Client-Server &Superserver Connections:

– 3rd Party Telnet, Shadowing, Java Bindings & JDBC

– CSP Gateway, ODBC, Caché Direct

• Web Services

What About SOAP w/ SSL?

• Acting as a Web Services client:

– Support provided via class properties and methods

– %SOAP.WebClient,EnsLib.SOAP.OutboundAdapter

• Acting as a Web Services provider:

– Support handled via Web Server

– IIS and Apache

EnsLib.SOAP.OutboundAdapter

• Processes Web Service requests on behalf of a BusinessOperation

• Specifies:

– Web Services Client Class

– SSL configuration to secure Web Server connection

– SOAP Credentials object to authenticate to external system

SOAP w/ SSL Overview

Securing Data Elements with Data Element

Encryption


Data Element Encryption

• New in Caché 2011.1

• Data Element Encryption protects data at rest

• This new encryption facility extends the key management technology developed for Cache block-level encryption to application-level encryption of arbitrary data elements.

• Enables application developers to use the same strong keys, and key management capabilities on more granular basis for data elements.

• Managed Encryption keys are loaded into memory and applications refer to these keys via a unique key identifier, therefore protecting access to the key itself.

Data Element Encryption

• The system is designed to load four keys into protected memory.

• Caché now provides a new encryption function that will embed the key identifier in the resulting cipher text. This enables the system to automatically identify the corresponding key, and allows application developers to design re-encryption methods, which are completely transparent to the application, without causing any down time.

• This new mechanism is designed to encrypt special data elements (e.g. Credit card numbers), and may or may not be used in conjunction with database encryption.

Advantages

• No additional key management required

• Encryption keys are never exposed

• Multiple keys (up to four) can be simultaneously activated, allowing for easy re-keying of sensitive data with no downtime (a PCI-DSS requirement)

• Strong three-factor data protection, flexible configuration of multiple keyfiles for different purposes, and encryption key recovery can be accomplished using the same operational policies recommended for database encryption.

Features

• It is no longer necessary to have a database or managed encryption key activated in order to manage a key file.

• It is now necessary to know a valid existing encryption key file administrator username and password in order to add new administrators to a key file or to configure unattended database key activation at startup.

• This is yet another reason why it is critical to have a backup key file containing an administrator entry stored along with a copy of that administrator's password in a physically secure location.

Comparison

• Database Encryption

– Very efficient and fast (done at 8K data blocks)

– Entire database encrypted

– Must dismount database to encrypt / decrypt

• Data Element Encryption

– Very flexible and granular

– Can encrypt single data element

– No downtime to encrypt, decrypt, or re-encrypt

Real World Example

• Payment Card Industry (PCI)

• Data Security Standard (DSS)

• Version 1.2.1 (July 2009)

• The PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally.

The PCI Data Security Standard

Types of Data on a Payment Card

CID

(American Express)

CAV2/CID/CVC2/CVV2

(Discover, JCB, MasterCard, Visa)

Magnetic Stripe

(data on tracks 1 & 2)

Expiration Date

PA

N

Chip

Exercise 3: Add Credit Card data to CRM


• Objective:

– Modify Customer class in CRM System to provide for storage of Credit Card Numbers.

• Outcome:

– Ability to store Credit Card data as part of the Customer data.

Exercise 4: Add Credit Card data to TRU


• Objective:

– Modify Things-R-Us Web Application to provide for input of Credit Card Numbers.

– Modify Things-R-Us Production to send Credit Card data to external CRM System.

• Outcome:

– Ability to input Credit Card data and store in the external CRM System.

PCI-DSS Storage Needs

Data ElementStorage

Permitted

Render

Unreadable

When Stored

Cardholder

Data

Primary Account Number

(PAN) Yes Yes

Cardholder Name Yes No

Service Code Yes No

Expiration Data Yes No

Sensitive

Authentication

Data

Full Magnetic Stripe Data No N/A

CAV2/CVC2/CVV2/CID No N/A

Chip Data No N/A

PIN/PIN Block No N/A

PCI-DSS Support

• Caché’s and Ensemble’s strong security model already supports the implementation of this standard

– Data-at-rest Encryption

– Authentication and Authorization

– Removing what is not needed

– Auditing

PCI-DSS Requirements

• PAN (Primary Account Number)

- One-way hashes based on strong cryptography for encrypted storage

- Index Tokens and Pads

- Strong cryptographic with associated key-management process and procedures for secure transmission across networks

- Mask PAN when displayed; the first six and last four digits are the maximum number of digits you may display.

PAN Encryption Concerns

• Database Encryption might be not feasible

– one key for all database

– system downtime during encryption (if not encrypted at database creation time)

• Re-encryption challenge

– the PAN must periodically get re-encrypted (with a different key)

PAN Encryption Solution

• Data Element Encryption to the rescue!

– i.e., Managed Encryption Keys

• Data Element Encryption can be done today as part of the application code (only decrypt if needed)

• The PAN can be re-encrypted while the system is running with no system downtime

Key Features of Solution

• System API functions for Data Element Encryption

• Data Element Encryption Keys are same as Database Encryption Keys and managed in the same way (stored in memory)

• Stores a GUID of the key together with the ciphertextto better support re-encryption

• Access to key only indirect by referring to the key via the GUID

System API

• $SYSTEM.Encryption.AESCBCManagedKeyEncrypt(Plaintext As %String, KeyID As %String) As %String

• $SYSTEM.Encryption.AESCBCManagedKeyDecrypt(Ciphertext As %String) As %String

• $SYSTEM.Encryption.AESCBCManagedKeyEncryptStream(Plaintext As %Stream.Object, Ciphertext As %Stream.Object, KeyID As %String) As %Status

• $SYSTEM.Encryption.AESCBCManagedKeyDecryptStream(Ciphertext As %Stream.Object, Plaintext As %Stream.Object) As %Status

System Management Portal

• Under System Administration, Encryption option has links to

– Create New Encryption Key

– Manage Encryption Key File (add Administrators)

– Database Encryption

– Data Element Encryption (Activate, Deactivate)

Exercise 5: Initial Encryption


• Objective:

– Modify CRM System to use Data Element Encryption.

– Perform initial encryption of existing data.

• Outcome:

– Customer data stored with encrypted Credit Card data.

Exercise 6: Reencryption


• Objective:

– Modify CRM System to use Data Element Encryption for reencryption of already encrypted data

– Perform reencryption of existing data.

• Outcome:

– Customer data stored with newly reencrypted Credit Card data.

Caché Security III:

Adding Security to Non-secure Applications

Daryl Flaming & David Lutz22 March 2011

Summary

• Reviewed a Non-secured Application

• Secured a Web based Portal Application using Authentication and Authorization

• Secured information flow between External Systems, Ensemble and the Consumer using SSL/TLS

• Added Credit Card Data to a Web based Portal Application

• Encrypted and secured Credit Card Data conforming to the PCI-DSS Standard

Questions?

• We hope this has been both informative and thoughtprovoking…

• Thank-you for your time, patience and attention over the past 2 hours

• We hope you enjoy Global Summit 2011

Cache Security- Adding Security to Non-Secure Applications

Technology