2014 11 data at rest protection for base24 - lessons learned in production

35
1 copyright (2014) comForte 21

Upload: thomas-burg

Post on 14-Jul-2015

265 views

Category:

Software


4 download

TRANSCRIPT

Page 1: 2014 11 data at rest protection for base24 - lessons learned in production

1copyright (2014) comForte 21

Page 2: 2014 11 data at rest protection for base24 - lessons learned in production

This part of the screen/slide are the so-called speaker notes

Viewing instructions: please see actual slide

copyright (2014) comForte 21 2

Page 3: 2014 11 data at rest protection for base24 - lessons learned in production

3copyright (2014) comForte 21

Page 4: 2014 11 data at rest protection for base24 - lessons learned in production

We start off with the summary and most important lesson of this presentation about data-at-rest protection for BASE24…

Copyright comForte 2014 4

Page 5: 2014 11 data at rest protection for base24 - lessons learned in production

It CAN be done and it HAS be done!

5copyright (2014) comForte 21

Page 6: 2014 11 data at rest protection for base24 - lessons learned in production

We now, briefly, look at potential reasons to protect data at rest in BASE24 environments.

Copyright comForte 2014 6

Page 7: 2014 11 data at rest protection for base24 - lessons learned in production

The PCI compliance situation for BASE24 is as follows:• Hundreds of customers running BASE24 classic on HP NonStop• Each of them is relying on so-called compensating controls to satisfy

PCI requirement 3.4 (which states that PAN data cannot be in the clear on disk)

• The HP VLE product is _not_ the answer (!)• Compensating controls are (1) costly (2) only an option if no other

solution is available• With SecurData (and competing products), now there IS another

solution available

7copyright (2014) comForte 21

Page 8: 2014 11 data at rest protection for base24 - lessons learned in production

Let's look at some basic principles of securing data-at-rest, from an attacker's perspective. To steal credit card data, the attacker would need to bypass your perimeter protection, get arround your anti-virus scanning, overcome access control mechanisms to get onto your internal network systems where credit card data is stored and avoid detection through monitoring happening at the various levels.

Recent data breaches have shown that this IS possible using so called Advanced Persistent Threats. These attacks are real. They are very sophisticated. They find the data. They get around the walls. They get through the „walls“. Insider attacks are another serious danger. A privileged user with legitimate access to sensitive data storage is already inside many of these walls. If a disgruntled employee or contractor goes rogue, damage can be significant.

Here PCI requirement 3.4 comes into play: Even when credit card information is stolen, misplaced, lost or misused, it's protected as long as the PAN is rendered unreadable. Rendering the PAN unreadable is your last line of defense. That's why it is a core requirement of the PCI standard.

It is also obvious, that encryption of the data can only be effective against insider attacks and advanced persistent theats if decryption keys are managed independently from the operating system and are not tied to user accounts. That's why this is expilicitly required for encryption solutions in the PCI standard – and this is why the HP VLE product alonedoes NOT suffice to be PCI 3.4 compliant.

8copyright (2014) comForte 21

Page 9: 2014 11 data at rest protection for base24 - lessons learned in production

In this section, we look at some features a complete solution should have in comForte’s opinion.

9copyright (2014) comForte 21

Page 10: 2014 11 data at rest protection for base24 - lessons learned in production

We are looking at this simplified picture of a Payment Processing system. This architecture fits BASE24 classic well, as it does BASE24-eps or home-grown payment processing engines.

The system typically writes transaction data including the PAN to log files. It may also store PANs in card holder files – all in clear text.

Finally, it may create export files for transmission to other systems in regular intervals and it may update card holder data from import files stored on the system.

A typical NonStop Payment System processes and stores a MASSIVE amount of PANs, potentially millions on a single day. Any malicious access to these files would be absolutely disastrous; it would be very expensive in post-incident handling, it will probably get you on the front-page of newspapers and massively damage your brand.

10copyright (2014) comForte 21

Page 11: 2014 11 data at rest protection for base24 - lessons learned in production

Now let's come back to BASE24 systems: Why do such a critical systems rely on compensating controls instead of fully implementing PCI-DSS for the best protection of the data? Unfortunately, BASE24 does not provide any data level encryption. Changing the BASE24 code and database to implement that protection would be a huge effort and is simply not feasible for most customers in practice. Thus, BASE24 users world-wide were forced to fall back on compensating controls as the second best choice.

This is where the comForte SecurData/24 solution comes in: For the first time ever, BASE24 can be made fully PCI 3.4 compliant. SecurData/24 works completely transparent at the I/O level. It does not require any code changes and can be integrated easily into existing processing environments. And unlike disk volume level encryption, SecurData/24 manages logical access to decryption keys independently of native operating system mechanisms and does not tie it to user accounts. [SecurData/24 is a variant of the general SecurData product, pre-configured specifically for BASE24 classic users].

Even better, it cannot only help you to achieve full 3.4 complaince for the BASE24 servers, but also for other enterprise systems exchanging PAN data with them.

11copyright (2014) comForte 21

Page 12: 2014 11 data at rest protection for base24 - lessons learned in production

12copyright (2014) comForte 21

Page 13: 2014 11 data at rest protection for base24 - lessons learned in production

The extra time spent by SecurData for a single transaction is typicallyless than 150 microseconds – both in real time and CPU time. The reason is that there is no file I/O at all and that only a few mathematicaloperations are required.

150 microseconds per transaction explains is why the performanceoverhead is so low.

The product scales very well and has so far always matched SLA timesduring Extracts.

13copyright (2014) comForte 21

Page 14: 2014 11 data at rest protection for base24 - lessons learned in production

14copyright (2014) comForte 21

Page 15: 2014 11 data at rest protection for base24 - lessons learned in production

Detailed auditing in computer-readable format is a standard feature of the solution. This screen shows the audit in its default format which is name/value pairs. This is easily to be read by computers and should be fed into a central SIEM system.

15copyright (2014) comForte 21

Page 16: 2014 11 data at rest protection for base24 - lessons learned in production

Here we have converted the output from the prior slide into an Excel sheet, showing the detailed information available in the audit log. The audit log can be configured to write a new set of data in regular intervals (hourly, daily, …) or via request from the command-line interface.

16copyright (2014) comForte 21

Page 17: 2014 11 data at rest protection for base24 - lessons learned in production

The requirement here is to convert from a file transfer of a temporary Extract file to a “direct upload” to the remote system without having to store an intermediate file.

This is one of the advanced features of the product.

17copyright (2014) comForte 21

Page 18: 2014 11 data at rest protection for base24 - lessons learned in production

This slide shows how the requirement from the previous file is met: TheSecurData intercept library is bound into the (extract) application and does an on-the-fly file transfer without even requiring an intermediate file. This works both for FTP transfers as for SFTP transfers.

Under the hood, the powerful concept of “pipes” under Unix is used to construct a chain of processes through which the data is fed without an intermediate file.

In the given example, the command “cat > remote_file” is executed directly on the remote system. The input into this “process pipe chain” is coming from the SDATA file relocation server.

18copyright (2014) comForte 21

Page 19: 2014 11 data at rest protection for base24 - lessons learned in production

"Just intercept" is not enough – there IS devil in detail when protecting a BASE24 system properly.

Here are some features which SecurData has built in and which arealready used in production. (Note: as of November 2014, SQL/MX is not implemented yet).

19copyright (2014) comForte 21

Page 20: 2014 11 data at rest protection for base24 - lessons learned in production

There are three core components in SecurData:

• The SecurData Intercept library is bound into the application and

intercepting all data base I/Os

• For each application data base I/O the SecurData Manager is now

tokenizing respectively de-tokenizing the PAN before the data base is

really accessed.

• By design, SecurData is open towards which “Tokenization engine” is

being used.

28-Nov-14

20copyright (2014) comForte 21

Page 21: 2014 11 data at rest protection for base24 - lessons learned in production

During the design stages of the product comForte made sure that there will be no ‘engine lock-in’ with SecurData. After all, there are many large players offering tokenization and/or encryption solutions and we wanted to make sure each customer can use his preferred vendor. We also designed our own, patent-pending, tokenization algorithm.

Comparing SecurData with enterprise data protection solutionsThe aforementioned enterprise data protection solutions do not offer any solution for instrumenting HP NonStop applications without code changes. While they may be offering an API for HP NonStop servers, they leave it to the application programmers to integrate it into their application. SecurData is therefore not competing with these solutions, but rather complementing them with its unique capabilities for application-transparent data protection.

Powerful built-in tokenization engineTo address the requirements of customers who are looking for a self-contained and cost-effective solution for their NonStop application, SecurData includes a very powerful data-at-rest protection engine itself. The SecurData tokenization engine runs directly on the NonStop Server, with minimal performance impact for the application. It uses a patent-pending stateless tokenization scheme (tokens and sensitive data elements are NOT stored in a database) which has been analyzed by renowned independent cryptologists.

Easy integration with enterprise data protection solutionscomForte SecurData can be easily integrated with any cross-platform enterprise data protection solution, such as Protegrity’s Data Security Platform, RSA’s Data Protection Manager or Voltage’s Secure Data product. comForte SecurData provides the glue between the application and the enterprise data protection solution, to avoid rewriting any application code.

Under the strategic partnership with Protegrity (see https://www.comforte.com/resources/news/strategic-partnership/), comForte SecurData is fully integrated with Protegrity’s Enterprise Security Administrator (ESA), which has been proven to meet performance requirements of high volume online transaction and batch processing. Before using another enterprise data protection solution it should be ensured that it meets the specific data format and performance requirements of the target application.

28-Nov-14

21copyright (2014) comForte 21

Page 22: 2014 11 data at rest protection for base24 - lessons learned in production

22copyright (2014) comForte 21 and Protegrity

Page 23: 2014 11 data at rest protection for base24 - lessons learned in production

We will now look at a typical project which starts with an evaluation of the product and ends with the product being in production.

23copyright (2014) comForte 21

Page 24: 2014 11 data at rest protection for base24 - lessons learned in production

Some fun with the letter “P” – 6 stePs to take the product in production. We’ll look at them in some more detail next.

24copyright (2014) comForte 21

Page 25: 2014 11 data at rest protection for base24 - lessons learned in production

25copyright (2014) comForte 21

Page 26: 2014 11 data at rest protection for base24 - lessons learned in production

comForte strongly believes to have a very powerful, stable and flexible offering in SecurData.

26copyright (2014) comForte 21

Page 27: 2014 11 data at rest protection for base24 - lessons learned in production

27copyright (2014) comForte 21

Page 28: 2014 11 data at rest protection for base24 - lessons learned in production

The PANfinder product is a complementary product to SecurData. In a nutshell, it is a scanning engine for PANs (and other confidential) on HP NonStop. It will scan the whole file system as well as databases and come back with a (sanitized) list of all files containing PANs.

A scan prior to the usage of SecurData will return all locations of critical files (prepare for some surprises).

A scan after installing SecurData should return zero critical files –otherwise you probably missed some during the design stages.

28copyright (2014) comForte 21

Page 29: 2014 11 data at rest protection for base24 - lessons learned in production

comForte provides 24/7 support to help you when the unexpected happen.

We also support you in setting up plans how to deal with some scenarios such as CPU outages or unexpected problems with SecurData.

29copyright (2014) comForte 21

Page 30: 2014 11 data at rest protection for base24 - lessons learned in production

30copyright (2014) comForte 21

Page 31: 2014 11 data at rest protection for base24 - lessons learned in production

We finally look at some customers who have put SecurData in production.

31copyright (2014) comForte 21

Page 32: 2014 11 data at rest protection for base24 - lessons learned in production

We have blanked out the customer names here.

32copyright (2014) comForte 21

Page 33: 2014 11 data at rest protection for base24 - lessons learned in production

Again, the customer names have been blanked out.

33copyright (2014) comForte 21

Page 34: 2014 11 data at rest protection for base24 - lessons learned in production

We will now summarize the key points of this presentation

34copyright (2014) comForte 21

Page 35: 2014 11 data at rest protection for base24 - lessons learned in production

For any further questions or for more information please talk to your account executive or contact the author at [email protected] .

You can also find more information any at www.comforte.com/securdata

This is the last slide of this presentation .

35copyright (2014) comForte 21