Cache Security- Adding Security to Non-Secure Applications
Caché Security III:Adding Security to Non-secure ApplicationsDaryl 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 AgendaAcademy Scenario and OverviewSecuring the ApplicationSecuring the Connectivity and Information FlowSecuring Data Elements with Data Element EncryptionQuestions?
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”
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 • API(s) and Technologies Available: – Web Service • Business Operation Concepts: – Request if a Customer is an existing Customer – Add new Customer to CRM Database
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)
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 StateRefer to Exercise Handout• Objective: – Learn the functionality of the non-secured application• Outcome: – Familiarity with the functionality of the non-secured application.
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 forThings-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
Authentication and Authorization approach forThings-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 basedBusiness Operations (CRM and Shipping)
Authentication and Authorization approach forThings-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 AuthorizationRefer to Exercise Handout• Objective: – Apply a number of security measures to various portions of the non-secured application.• Outcome: – A partially secured application.
Securing Connectivity and InformationFlowDaryl Flaming & Dave Lutz
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 Business Operation • Specifies: – Web Services Client Class – SSL configuration to secure Web Server connection – SOAP Credentials object to authenticate to external system
Securing Data Elements with Data ElementEncryptionDaryl Flaming & Dave Lutz
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 administrators 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.
Types of Data on a Payment Card CID CAV2/CID/CVC2/CVV2 (American Express) (Discover, JCB, MasterCard, Visa)ChipPAN Expiration Date Magnetic Stripe (data on tracks 1 & 2)
Exercise 3: Add Credit Card data to CRMRefer 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.
Exercise 4: Add Credit Card data to TRURefer 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.
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/AAuthentication Data 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 ciphertext to 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(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
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 EncryptionRefer 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.
Exercise 6: ReencryptionRefer 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.
Caché Security III:Adding Security to Non-secure ApplicationsDaryl 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 thought provoking… • Thank-you for your time, patience and attention over the past 2 hours • We hope you enjoy Global Summit 2011