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