This document provides an overview of an academy that will teach attendees how to secure an existing unsecured web application that processes online purchases. The academy will cover applying authentication, authorization, securing connectivity, and encrypting credit card data. The scenario involves securing an e-commerce application called Things-R-Us that is currently non-secure and integrates various systems. The agenda includes securing the application, connectivity, and encrypting specific data elements.

1. Caché Security III:
Adding Security to Non-secure Applications
Daryl Flaming & David Lutz
22 March 2011

2. 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.

3. 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

4. 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.

5. Academy Agenda
Academy Scenario and Overview
Securing the Application
Securing the Connectivity and Information Flow
Securing Data Elements with Data Element Encryption
Questions?

6. Let’s Get Started…
Daryl Flaming & Dave Lutz

7. 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”

8. Things “R” Us Overview - Initial

9. Things “R” Us Overview - Final

10. 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

11. Let’s Examine the Inventory System
• API(s) and Technologies Available:
– Stored Procedures:
• FindByCode()
• GetLevel()
• RecordSale()
• AdjustInventory()
– SQL Views
– Linked tables/SQL Gateway

12. 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

13. Let’s Examine the CRM System
• API(s) and Technologies Available:
– Web Service
• Business Operation Concepts:
– Request if a Customer is an existing
Customer
– Add new Customer to CRM Database

14. Let’s Examine the Shipping System
• API(s) and Technologies Available:
– Web Service
• Business Operation Concepts:
– Request shipping service from the external
Shipping System
– Receive shipping information details (Tracking Number and
Carrier to be used)

15. 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

16. 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.

17. 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.

18. Securing Things-R-Us
Daryl Flaming & Dave Lutz

19. 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

20. 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

21. Authentication and Authorization approach for
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)

22. Authentication and Authorization approach for
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

23. Exercise #2: Authentication and Authorization
Refer to Exercise Handout
• Objective:
– Apply a number of security measures to various portions of the
non-secured application.
• Outcome:
– A partially secured application.

24. Securing Connectivity and Information
Flow
Daryl Flaming & Dave Lutz

25. 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

26. SSL Overview
• Provides secure point-to-point
communication over network
• Allows for:
– Mutual Authentication
– Encrypted Data Transmission
– Message Authentication Checking

27. 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

28. 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

29. 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

30. EnsLib.SOAP.OutboundAdapter
• Processes Web Service requests on behalf of a Business
Operation
• Specifies:
– Web Services Client Class
– SSL configuration to secure Web Server connection
– SOAP Credentials object to authenticate to external
system

31. SOAP w/ SSL Overview

32. Securing Data Elements with Data Element
Encryption
Daryl Flaming & Dave Lutz

33. 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.

34. 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.

35. 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.

36. 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.

37. 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

38. 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.

39. The PCI Data Security Standard

40. Types of Data on a Payment Card
CID CAV2/CID/CVC2/CVV2
(American Express) (Discover, JCB, MasterCard, Visa)
Chip
PA
N
Expiration Date Magnetic Stripe
(data on tracks 1 & 2)

41. Exercise 3: Add Credit Card data to CRM
Refer to Exercise Handout
• 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.

42. Exercise 4: Add Credit Card data to TRU
Refer to Exercise Handout
• 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.

43. PCI-DSS Storage Needs
Render
Storage
Data Element Unreadable
Permitted
When Stored
Primary Account Number
(PAN) Yes Yes
Cardholder Cardholder Name Yes No
Data Service Code Yes No
Expiration Data Yes No
Full Magnetic Stripe Data No N/A
Sensitive CAV2/CVC2/CVV2/CID No N/A
Authentication
Data Chip Data No N/A
PIN/PIN Block No N/A

44. 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

45. 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.

46. 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)

47. 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

48. 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 ciphertext
to better support re-encryption
• Access to key only indirect by referring to the key via
the GUID

49. System API
• $SYSTEM.Encryption.AESCBCManagedKeyEncrypt
(Plaintext As %String, KeyID As %String) As %String
• $SYSTEM.Encryption.AESCBCManagedKeyDecrypt
(Ciphertext As %String) As %String
• $SYSTEM.Encryption.AESCBCManagedKeyEncryptStream(Pla
intext As %Stream.Object, Ciphertext As %Stream.Object,
KeyID As %String) As %Status
• $SYSTEM.Encryption.AESCBCManagedKeyDecryptStream(Ci
phertext As %Stream.Object, Plaintext As %Stream.Object) As
%Status

50. 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)

51. Exercise 5: Initial Encryption
Refer to Exercise Handout
• Objective:
– Modify CRM System to use Data Element Encryption.
– Perform initial encryption of existing data.
• Outcome:
– Customer data stored with encrypted Credit Card data.

52. Exercise 6: Reencryption
Refer to Exercise Handout
• 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.

53. Caché Security III:
Adding Security to Non-secure Applications
Daryl Flaming & David Lutz
22 March 2011

54. 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

55. Questions?
• We hope this has been both informative and thought
provoking…
• Thank-you for your time, patience and attention over the
past 2 hours
• We hope you enjoy Global Summit 2011