Well I’m off to Europe (specifically Poland) for a well deserved vacation

If anyone is in the Krakow region - drop me a line and perhaps we can share a conversation over a Lech or Tyskie in the town square ?

My very first experience with an Atalla was with an old PCI card version of the ATALLA 10000 that was used in an issuer system for CVV and CVV2 verification. Having access to an HSM for development and testing is really a good thing , and is also a requirement is you are building a PIN based debit system, and since not everyone has access to HSM’s in their labs

A friend has recently shared the following link: http://ziggurat29.com/ that includes "BogoAtalla"

This is an Atalla emulator (or simulator).  This software emulation (simulation) of the well-known Atalla Hardware Security Module (HSM) that is used by banks and processors for cryptographic operations, such as verifying/translating PIN blocks, authorizing transactions by verifying CVV/CSC numbers, and performing key exchange procedures, was produced for testing purposes.  This implementation is not of the complete HP Atalla command set, but rather the just portions that I myself needed.  That being said, it is complete enough if you are performing acquiring and/or issuing processing functions, and are using more modern schemes such as Visa PVV and DUKPT, and need to do generation, verification, and translation.

This runs as a listening socket server and handles the native Atalla command set.  I have taken some liberties with the error return values and have not striven for high-fidelity there (i.e., you may get a different error response from native hardware), but definitely should get identical positive responses.  Some features implemented here would normally require purchasing premium commands, but all commands here implemented are available.  Examples are generating PVV values and encrypting/decrypting plaintext PIN values.

I gave it a very quick shot in a test virtual machine:

<00#020035#0101##>

Let’s see — my first error message, invalid character/message

And if you are a real geek- you can use the WRTG version:  BogoAtalla for Linksys — makes a great portable HSM.

I’ll probably play a little more with this in the future.

I received a bill that had an option to pay with a credit card on the back, my favorite part of it is the line that asks for:

SECURITY CODE FROM BACK OF CARD__________________________________________

PCI 3.3.2 - clearly states:

"Do not store the card validation value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions"

Perhaps I’ll write "Call if Security code is required"  um… no — I think I’ll make an e-check — I’m now wondering what they do with these slips after they receive them per PCI 9.6

Don’t forget about receipts, remittences, or other paper items for PCI reviews. How many people would just go ahead and fill this out if they wanted to pay by credit card ?

If you looked at the news on the TV-tube or on a national news website such as www.msnbc.com today you will see that Cedar Rapids, IA is under water. This is a city not far from my home town, and I know there were a few companies that either had to "execute" their disaster recovery (DR) and business continuity (BCP) plans or are putting their businesses on hold.

When I did BCP and DR reviews as an IT Security Consultant mostly for FFIEC Bank Reviews/Assessments, as well when I led this effort at prior companies I was at - these were a few of the items of concern:

Generally the process to create a BCP plan is simple - it is the process of gathering the information, accessing the information, and keeping the information up to date and current (you do have a DR/BCP considerations in new projects and apart of your change management processes don’t you ?) is the painful bit. This shouldn’t be a once a year project that a company assigns an IT person to — it should consist of a committee that meets regularly with input from all departments.

Here are the general steps of the process:

• Perform a business impact analysis - what would happen to the business and its customers during an disruption of business ? - What systems and processes are needed by the business and its departments to function ?
• Perform a risk assessment / threat analysis  — Flood, Fire, Loss of Power, Pandemic Bird Flu, Earthquake, Tornado/Hurricane, Bribery, Computer Attack, Loss of Communication Lines ? — what is the likely hood of this event occurring and what is its impact.
• Develop recovery time objectives - how long can you be down or unavailable ?
• Develop procedures for each department - Safety, Evacuation procedures, command centers, calling lists, off-site inventories, vendor lists, customer contact information, recovery teams, team members and responsibilities.
• Test the plan - Tabletop testing based on mock scenarios, and technical recovery tests of systems are important here.
• wash, rinse and repeat …

With Payment Processing applications the following are topics that you need to think about:

• Batch processing, and transferring of data files. (do you have documented information and equipment and software and configurations to perform this ?)
• Real Time Authorizations considerations
• Communication Links to end-points and providers
• Availability of Backup Hardware
• Data replication strategy
• Backups of systems
• Ability to restore systems
• Data Integrity concerns and potential loss of data
• Security of Payment Card information during a disaster
• HSM, encryption keys and key custodians 
• Reconfiguration of client systems to connect to alternate site
• Are processes and install/setup/configurations documented so some one else other then the "go-to-guy" can perform these steps ? Because he or she is with their family because they lost or are displaced from their home.

I’m sure I can think of more considerations and you can too — but the point was to make you think — another recent event described here: at a hosting center where the hosting center was not allowed to bring up their backup generators and execute their BCP plan because of an order from the Fire Department and safety concerns.

Occasionally there is a need to demo a payment switch to internal parties, customers, business partners, etc.  Depending on the audience of the demo it is really hard to show a payment switch. How do you perform this ? I’ve seen a few methods but none that I particularly like- but this is most likely true with any data processing system- The issue is that it is hard to show something that accepts messages over the network, performs validation and business logic, send them to another endpoint and log the response, back to the caller, while handling exceptions and other considerations.

• You have the toaster, stack or circle diagram that shows the "engine", "components" and all of the modules that can be "plugged" in to support different endpoints, message formats, devices, protocols, etc. — This is actually a pretty good overview from a top-down perspective

• You draw a diagram that shows a device, merchant, acquiring bank, issuing bank, gateways, endpoints, systems in play, operational processes  on a whiteboard, and trace a transaction though its lifecycle typically in a different color of marker.

• You login to a demo system and typically show the "UI" or User Interface of the application and run test transactions using simulators - The thing is the UI really doesn’t do much in many systems in terms of the actual processing of transactions. It is an interface to view transactions, view and set configuration options, and typically view a dashboard or status screen for monitoring purposes — these are all great things, but are only about 10% of the meat of the payment engine.

I’ve found that a combination of these three work out the best, but I get irritated that a payment switch isn’t easily demonstratable. — To me this is similar to Data Center Walk-throughs, I care more about the operational processes and procedures then by being awed by generators, battery backups, security camera, cooling systems, etc.

Payment Systems Podcast - episode #1 -  by: David Bergert & Andy Orrock

In our first podcast we discuss a project that we have been working on to migrate a payment application from legacy hardware to “4 boxes that cost $28,000 worth of hardware.”

 

 Payment Systems Podcast episode #1 [22:38m]: Play Now | Play in Popup | Download

Use Cinch - [http://cinch.blogtalkradio.com]  to record an mp3 and email it or just send a text email to  podcast@paymentsystemsblog.com for any comments or questions.

Music by: Infrared by the Rantings of EVA

Linda Elliott from Glenbrook writes a great summary based on the Federal Reserve Bank of Chicago’s 2008 Payments Conference: read it here: www.glenbrook.com/2008/06/payment-systems.html