Townsend Security Data Privacy Blog

As a company that provides NIST-certified encryption and FIPS 140-2 encryption key management, we need to secure data on a number of different platforms. Lately we have been coming into several cases where a customer needs encryption and key management on both Microsoft SQL Server and Oracle databases. Below is an email exchange with a customer who came to us “looking for a product to store, generate and manage keys that we use to encrypt/decrypt credit card information inside both SQL Server and Oracle Databases on Windows and UNIX.” We hope this discussion helps with your encryption project.

Customers Environment:

1. Encryption key is generated on the Windows platform through custom software, but if we can move away from that to an automated approach all the better. The key is moved to Oracle manually and we want to replace this with automation.

2. Credit card information is interfaced to our system then automatically encrypted using the key and stored in a SQL 2008 Enterprise Edition server table (only the one column is encrypted).

3. The SQL Server data is then sent to our Oracle database as encrypted data where it is stored in one column of a table.  It is then decrypted and sent to a payment services company who send us back a billing code, which replaces the encrypted credit card number.  So most of the encrypted credit cards are only stored for a short period of time, but some with problems are stored much longer.

Questions Addressed:

Our Alliance Key Manager (AKM) Hardware Security Module (HSM) provides full life-cycle management of encryption keys for PCI DSS and PII compliance. It works with applications and databases on a variety of platforms including Windows, Linux, UNIX, and IBM mainframes. We support the Microsoft EKM architecture for automatic encryption of SQL Server using TDE or Cell Level Encryption. Our customers also use AKM to manage keys for Oracle database applications, and support for Oracle TDE (requires Oracle Enterprise Edition and Advanced Security) is in our product roadmap.

SQL Server:

Because you are running SQL Server Enterprise edition, you have two options. The first is to deploy Extensible Key Management (EKM), which is supported by our Alliance Key Manager. EKM gives you the ability to automate encryption through Transparent Data Encryption (TDE) or Cell Level Encryption. TDE is usually the choice people make as it is the easiest to deploy and does not require any programming. Cell Level Encryption requires a bit of programming, but still fully automates the storage of keys on the key server.

The second approach is to use our Windows .NET key retrieval assembly to retrieve an encryption key from our key server and perform encryption in your application. Since you are already doing an encryption with a local key, this would probably be a pretty simple task. It appears that you might need this type of granular approach to support your current integration between SQL Server and Oracle. We have C# and VBNET sample code that shows how to retrieve a key from the key server.

Additionally, we support Windows 2003 for either approach and both of these approaches will meet PCI DSS standards for key management.

Oracle:

Our customers are currently using our key manager to encrypt data in Oracle databases. We provide sample code in Java, Perl, PHP, and other languages to support this. We also provide a shared library that does secure key retrieval from a variety of platforms, and also sample code that shows how use the shared library in PL/SQL.

Key Generation:

Encryption keys are generated on the encryption key manager using a secure administrator's console installed on a Windows PC. The interface to the key manager is a wire protocol and you can drive it from any application platform that supports SSL/TLS. All of your OS's do so. Our business users attempting to meet PCI DSS requirements for Dual Control and Separation of Duties typically stick to using our secure key management console.

Encryption on HSM:

Our Alliance Key Manager also supports encryption on the server. Rather than retrieving the key to your business application, you can send the data to the key manager with the name of the key you want to use, and it will return the encrypted or decrypted data back to your application on the secure connection. No key leaves the key server with this approach - just an alternative that is worth mentioning.

We hope that this case study can help you with your encryption project.  Listen to our podcast “Encryption Key Management with Microsoft SQL Server 2008 to learn how easy it is for your organization to start encrypting data on your SQL Server.

Many people we talk to are gambling with $7.2 million whether they realize it or not.  This week we are at HIMSS12 in Las Vegas meeting members of the IT medical community – an appropriate venue for such high-stakes gambling.  How are these people gambling with so much money?  The average cost of a data breach is $214 per record, or $7.2 million for an organization.  This figure is determined not only by direct costs of a data breach, such as notification and legal defense costs that impact the bottom line for companies, but also indirect costs like lost customer business due to abnormal churn.

Is there a way to make sure you aren’t putting your organization in such risk?  The HITECH Act, the compliance regulation that the medical community is concerned with, says that the only way to avoid a breach notification is through the use of industry standard encryption such as AES, and appropriate encryption key management technologies.  Other compliance regulations (such as PCI DSS) go as far as REQUIRING protecting Personally Identifiable Information (PII) with encryption and key management – not just to receive a breach notification exemption.

Becoming compliant with these regulations doesn’t have to be hard (though it can be).  Townsend Security has made it easy (saving your organization time and money) with NIST-certified AES encryption for all the major enterprise platforms, as well as a FIPS 140-2 certified encryption key management hardware security module (HSM).  For those organizations who are already encrypting but need key management, our encryption key manager can easily work with your existing database (SQL, Oracle, DB2, etc.) to help meet compliance requirements that call for separation of duties and dual control.

If you aren’t familiar with NIST and FIPS 140-2 certifications, the National Institute of Standards and Technology (NIST) provides them to encryption and key management solutions after they undergo a rigorous testing process.  The testing is carried out by independent testing labs who then report the results directly to NIST for validation.  Only the most dedicated security vendors are able to pass the tests and achieve NIST and FIPS 140-2 certifications.  Not only are these certifications essential for meeting compliance regulations, but they provide you an ease of mind that a third-party has verified the integrity of the product.

So are you gambling with $7.2 million?  If you aren’t protecting your PII with encryption and key management you might be.  Take the first step for help and call our gambling hotline (800-357-1019) or send us an email.  We’d be glad to help you step away from the table.

Learn more about proper encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Are you an ISV?  Visit our ISV Partner Program page for more information on becoming a partner or download our white paper titled Healthcare ISVs: Critical Issues in Meeting HITECH Data Protection Regulations.

Critical Issues for ISVs Download the white paper "Healthcare ISVs: Critical Issues in Meeting HITECH Data Protection Regulations." Click Here to Download Now

As we move closer to the finalized rules for HITECH data protection, some things are now becoming very clear.  The government wants ISVs and service providers to offer encryption of data at rest to their customers, and they want covered entities to use it!  While a careful read of the regulations reveals that they do not mandate encryption, the guidance makes clear that encryption is the ONLY safe harbor from breach notification.  Your customers will interpret this as a mandate, and will start demanding encryption in your products and service solutions.  We are already starting to see this happen.

Healthcare ISVs face some really big challenges as they start to move into the unfamiliar territory of encryption and key management.  Here are four critical issues you will face as you start down the path to securing your data at rest with strong encryption:

1)    The Big Challenge is Encryption Key Management

Encryption itself is not really the biggest technical challenge facing ISVs as they start to encrypt data in their application databases.  Most operating systems, databases, and programming languages offer encryption libraries that you can use right off the shelf.  For example, Microsoft provides encryption libraries in SQL server and the .NET language.  Oracle offers similar support for encryption in their database.  The really big challenge is encryption key management.  Encryption keys are the secrets that must be protected.  Key management systems create, store, and protect keys from loss, and this will be the hardest thing to get right.

2)    NIST & FIPS Certification

The HITECH guidance is full of references to the National Institute of standards and Technology (NIST) for encryption standards and best practices.  Advanced Encryption standard (AES) is the recommended technology for encryption.  And the NIST recommendations for key management are the gold standard for key management solutions.  Serious key management vendors submit their solutions to NIST for certification under the FIPS 140 protocol, and these vendors are easy to locate on the NIST web site.

3)    Getting Encryption and Key Management Right

You will be tempted to push the responsibility for encryption and key management to an outside vendor.  If it is really hard to do, why not let someone else do the job? You can refer your customers to the vendor for the solution, and the vendor can do the work of getting the database encrypted.  It seems easy.  Until you discover that your customers are not going to distinguish between your vendor and you when problems happen!  You will be ultimately responsible for any problems with data protection.

4)    The Right Partnership

Many ISVs discover that finding the right partner for encryption key management solutions is the biggest hidden challenge in their projects. Not only is the technology very specialized, there are a small number of vendors who offer FIPS 140 certified solutions.  You have to offer solutions to your customers that are easy to deploy and meet your product pricing objectives.  What if you need a customized key management solution?  Are there any vendors who are willing to help you with these requirements?  Finding the right partner is as important as finding the right technology.

Visit our ISV Partner Program page for more information on becoming a partner or download our white paper titled Healthcare ISVs: Critical Issues in Meeting HITECH Data Protection Regulations.

In our final installment on system logging on the IBM i series, Patrick Townsend, Founder & CTO, discusses what to look for when selecting and deploying a logging solution.  As we found out in part two of this series, it really isn’t a good idea to take the “do it yourself” approach.  System logs are in several different locations on the IBM i, and even if you get them all together, it is still a challenge to get them in a useable format.  Here is what Patrick has to say about selecting a logging solution:

So what do you need to look for when selecting and deploying a logging solution?

I think that there are four key points when looking at a logging solution especially on the IBM i Platform. One is, you want a real-time logging solution.  It won’t cut it to have a system collecting events once or twice a day and sending them off to a log server.  You need a real-time system that is collecting events as they happen so that your log collection server and your SIEM can actually correlate events across multiple servers and “see” what’s happening.

Secondly, on the IBM i, performance is always an issue. We have many customers running Alliance LogAgent with tens of millions of events a day.  Just this week we talked to a customer who was generating 120 million events a day.  That is a lot of events to be collecting and other solutions just can’t keep up with the sheer volume of events.  If your system can’t keep up with that, you will have a real compliance problem.  I’m really proud of the performance of our solution and that it allows us to do hundreds of millions of events every day, keeping up with the security events of the largest customers.

Third, logs should be protected while they are being transmitted to a log server.  Alliance LogAgent protects the transmission with a SSL/TCP connection.  Some of the information in your system logs can be very sensitive and it would be a bad idea to transmit this data in the clear.  When choosing a logging solution, it should have full support for a secure transfer mechanism.

Finally, industry standards are very important.  Standards are important on a very practical level.  When you buy a light bulb in the store, you want to be able to take it home and plug into a light socket.  You are able to do this because of standards.  The same is true for logging events on the IBM i.  There is a standard format for logging system events and the way you send your logs from an IBM i to a log collection server.  Query, reporting, and alerting tools depend on those standard formats.  The solution that you decide to deploy should be built on industry standards.  We support both the RFC Format and Common Event Format standards.

Those are the four most critical points for a standard logging solution and I am really proud that our product, LogAgent stands up really well on all four of those points. Overall, I think if you focus on those four items you’ll be in a good place.

Listen to our podcast “System Logging on the IBM i” for more information on logging, how it can help you meet compliance requirements, what to look for in a logging solution, and how Townsend Security can help you transmit the logs from your IBM i to any SIEM console.

In the first part of our series on system logging on the IBM i (AS/400) we discussed why system logging is so important and where security information lives on the IBM i.  We will now continue my conversation with Patrick Townsend, Founder & CTO, and talk about log collection and meeting compliance regulations with system logging.

So now that you have identified the sources of this important system information, how do we format it for log collection and SIEM Servers?

This is probably the biggest challenge for IBM i users - getting log information from the IBM i into a usable format.  IBM i logs are not recognizable by a typical log collection sever or a SIEM console that monitor log data.  With Alliance LogAgent, we have tackled this problem by reading all of these sources of event information and translating from the IBM i format to a standard log format.  IBM does provide a few utilities for printing log information, and I have seen people try to use those to get data into a text type format, but they are unsuccessful because the printed log information is not in a standard format.  Another reason why this method doesn’t work is that it is typically not in real-time, so you’re not picking up information in a timely fashion - meaning you are missing threats that are happening in your machine.

Formatting data is a major challenge and we decided that the right way to do this was to bite the bullet and read the internal format of the logs, while they are completely unrecognizable to any standard log collection server, and format them to industry standard formats - based on existing RFC’s in terms of SYSLOG formats or Common Event Format.  Alliance LogAgent puts them in the right format and transmits them.  The technology in our logging solution is really focused on making all that log information usable, doing it in real-time, and then getting it to where it needs to go – allowing it to be monitored by your SIEM in real time.

System logging is also important for meeting compliance regulations too, right? 

Absolutely, if you take a look at PCI data security standards from the beginning, section 10 is focused on collecting logs and analyzing them in a timely fashion.  If you drill down into the recommendations for HIPAA/HITECH Act, or if you’re looking at FFIEC in the financial sector, or even privacy notification laws, they are all very consistent about requiring proper monitoring of system logs.  And this is understandable, looking at how threats evolve and what the typical threat looks like.

Sometimes bad software gets installed on a system and sits there for months at a time, undetected because nobody is monitoring the logs. That software can be phoning home through an IP connection and checking in through remote servers.  Your logs should be showing that activity.  That is why you’ll find across the board, in almost every compliance regulation, a need or requirement to collect logs in a central location, on a log collection server, or in a SIEM.  Someone needs to be paying attention to those logs and “someone” could be automated software, including products from SIEM vendors.  It is really important from a compliance point of view that you are collecting logs, doing it in a fast, real-time fashion, and have something monitoring those logs looking for threats.

View our Webcast “Understanding Log Management on the IBM i” for more information on logging and how it can help you meet compliance requirements with real-time security event logging across your Enterprise.

As a company that works hard to protect your data, we get a lot of questions – from people wanting to know the ins and outs of our products to IT professionals who are new to the world of meeting compliance regulations.  Luckily, our company has several experts to answer these questions.  One topic that we often get questions regarding is system logging on the IBM i (AS/400).  Logging on the IBM i is different than logging on other platforms.  I recently sat down with Patrick Townsend, Founder & CEO, to pick his brain on what system logging is, and why it is so unique on the IBM i.

System logging has become one of the most essential compliance tasks in contemporary corporate IT. Can you give a brief explanation of what logging is and why it is so important?

Sure, all computer systems, including the IBM i (AS/400, iSeries, System i) collect lots of important information about the security state or the operational state of the system as a whole.  We call these System Logs and they often include a great deal of information about what is going on in the system.  In a lot of systems, including the IBM i, these logs are created in real-time.  To give an example, if someone tries to sign into an IBM i and for whatever reason the username or password is invalid, that event is logged in the system log.  This is an important thing to log because if you were to look at this system log in real-time and notice several invalid username and password events, you would say “Hey, our system is being attacked. We need to take action on this now.”  In summary, System Logs are just a central repository on the computer system that say what is going on within the system.  This is why they are so important from a security point of view.

Where does security information live on the IBM i?

Security information lives in a number of places, which is one of the challenges that IBM i administrators have.  On the IBM i, IBM creates a central repository (QAUDJRN in the IBM i world) for a large number of security events including password and other security events. Our Alliance LogAgent customers can decide what kind of events they want to collect.  QAUDJRN is not the only place to look for this security information. There is also a system event log file called QHST that has important log-on and log-off information for users.  The operators console (QSYSOPR) collects and tracks important events and messages for security monitoring.  Finally, the IBM i sports a lot of new, web-type services that have their own log collection facilities including WebSphere, Apache, and SSH.  In order to properly look at all of the security events that are happening on an IBM i, you have to look in several places, which can be a challenge.

Listen to our podcast “System Logging on the IBM i” for more information on logging, how it can help you meet compliance requirements, what to look for in a logging solution, and how Townsend Security can help you transmit the logs from your IBM i to any SIEM console.

Data Privacy Day (January 28, annually) is an annual international celebration designed to encourage awareness about privacy and education on best privacy practices.  Sponsored by companies such as Intel, eBay, and Google, the day is designed to promote awareness on the many ways personal information is collected, stored, used, and shared, as well as education about privacy practices that will enable individuals to protect their personal information.  

As a data privacy company, this day is almost like our birthday – a day for the IT world to focus on our slice of the pie (can we celebrate Data Privacy Day with pie too?).  It also is a time to reflect on some of the data breaches that made news headlines in the previous year – “is my organization making some of the same mistakes?”

In honor of Data Privacy Day, StaySafeOnline.org has published a document titled “Stop. Think. Connect” that gives tips and advice on keeping your personal information safe.  Here is some of their advice:

Protect Your Personal Information

• Secure your accounts: Ask for protection beyond passwords.  Many account providers now offer additional ways for you verify who you are before you conduct business on that site.
• Make passwords long and strong: Combine capital and lowercase letters with numbers and symbols to create a more secure password.

Connect with Care

• Get savvy about Wi-Fi hotspots: Limit the type of business you conduct and adjust the security settings on your device to limit who can access your machine.
• Protect your $$: When banking and shopping, check to be sure the sites is security enabled.  Look for web addresses with “https://” or “shttp://”, which means the site takes extra measures to help secure your information. “http://” is not secure.

Keep a Clean Machine

• Keep security software current: Having the latest security software, web browser, and operating system are the best defenses against viruses, malware, and other online threats.
• Automate software updates: Many software programs will automatically connect and update to defend against known risks.  Turn on automatic updates if that’s an available option. 

By following these few tips your personal information/data will be more secure than ever.  We also urge you to think about who you give your personal information.  Do you think twice about whether it is being properly protected?

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.

 

During our monthly webinars we receive some great questions that we like to share with our blog readers.  Our most recent webinar titled “Secure Managed File Transfers on the IBM i” discussed meeting compliance regulations, as well as how to automatically transfer files to trading partners using sFTP or SSL FTP.  While on the topic of secure transfers, one attendee asked the following question that Patrick Townsend, Founder & CTO, was able to answer:

A public/private key pair is needed for SSH/sFTP Transfers.  Does the Alliance FTP Manager exchange keys with the destination server?

Yes, SSH as a technology, implements a number of ways to secure and authenticate connections.  Public/Private Key or PKI implementation is a part of that.  Also password authentication is an option within the SSH world too.  Looking back over the last few years, public/private key based encryption has predominately been the rule with SSH and sFTP Transfers.

Recently, there has been an interesting migration with a trend of moving to a password-based authentication for sFTP sessions, and I understand why.  Many large institutions have a big task of managing all of their Public/Private key pairs.  If you are transferring just one file outside of the company, like to a bank, then there is not really much of a problem.  But some of our customers use thousands of keys within their IT environment, which becomes very difficult to manage. 

Alliance FTP Manager supports Public/Private key based authentication as well as “password based” authentication. Usually, your trading partner is choosing the authentication for you, but we do support both models.  

There is another aspect to this question and that is the key exchange, which can be a bit of an administrative nightmare.  We have really tried to help our customers by automatically pulling in a remote SSH severs Public Key into the proper files on the IBM i.  Additionally, we have developed utilities that make that a matter of selecting on option in a menu.  In some cases you still have to send a public key to your partner, but we have done a lot to help manage the PKI infrastructure exchange that needs to happen.  From an administrative perspective, you don’t want to be emailing keys around all over and we have done a lot to help make secure managed file transfers an easy process. 

View our webinar “Secure Managed File Transfers on the IBM i” for more information on automatically transferring files to business partners while meeting compliance regulations.

 

Meeting compliance regulations on your IBM i for securing data in motion doesn’t need to be difficult.  They all have the same overlying theme – encryption.  PCI DSS requires encryption when transferring files over the internet and WiFi networks.  HIPAA/HITECH says that encryption is the only Safe Harbor from a data breach.  While failing to comply with these regulations can financially impact your organization, the good news is that with just a few core encryption components, you can easily satisfy these requirements.

There are a handful of core components to look for when deciding on a managed file transfer solution for your organization.

• SSL FTP with 128-bit encryption
• sFTP with 128-bit encryption
• PGP file encryption with 2048-bit keys
• Audit trails

Our Alliance FTP Manager not only contains all of these components, but also enables users to automate their managed file transfers.  Alliance FTP Manager provides several automation functions to help you exchange files without human intervention.  Users can automatically transfer files using Secure Shell sFTP or secure SSL FTP to banks, insurance companies, benefits providers, payment networks, and any other internal or external server.  The transfers are encrypted to meet compliance regulations (such as PCI DSS, HIPAA/HITECH, and privacy notification laws).  Additionally, audit trails and system logs provide the permanent history needed for compliance regulations.

Finally, Pretty Good Privacy (PGP) is the de facto standard for file encryption before transmission to a trading partner.  Based on open standards and tested by time, PGP has won the trust of governments and private enterprises to protect their sensitive data.

Are you ready to get started?  Download a 30-day evaluation of Alliance FTP Manager, configure it, and send your first encrypted file transfer in about an hour. Sending and receiving encrypted data just doesn't get any easier.

As the social revolution moves into the business world, protecting your data is more important than ever.  This was a key takeaway for attendees of the recent “Dreamforce to You” event in Seattle, WA, hosted by Salesforce.

Similar, yet smaller in scale to the Dreamforce conference held annually in San Francisco, this event brought together sales and marketing professionals who use Salesforce.com (a cloud-based Customer Relationship Manager) to see what is new with the CRM, how it can help you do your job better, as well as allow attendees to network with peers.  Additionally, Peter Coffee, an IT visionary who acts as the VP and Head of Platform Research at Salesforce.com, delivered an inspirational keynote titled “Toward the Social Enterprise: Trust; Vision; Revolution”.

The focus of both Dreamforce and “Dreamforce to You” is that by and large  business is embracing the social revolution.  Whether you are Bank of America and helping your customers find the nearest ATM or are collaborating with co-workers internally using social tools, businesses are migrating to the social world.  During the keynote, Peter Coffee presented a slide titled “Social is a model, not an app.”  By being social, businesses are able to work more efficiently and reach more customers in ways that were never thought possible.  “Salesforce is not just using social tools but instead is driven and formed by the social network.”

As Peter Coffee continued to discuss cloud computing, the future of IT platforms, and how businesses are “going social”, he conveyed a key concept – companies need to protect their sensitive information.  

We couldn’t agree more.  As a security company, this is something we have been saying since the beginning.  We have offered NIST-validated AES encryption for all the major enterprise platforms for over ten years, been securing managed file transfers with PGP encryption, and recently stepped up our game with a FIPS 140-2 compliant encryption key management HSM.  Simply put, we are helping organizations protect their sensitive information and meet compliance regulations with certified encryption solutions.

Occasionally we hear “I don’t need encryption, nothing can get inside my network” (De-Perimeterization concept). The truth is, no matter how many of the latest and greatest network security devices you implement, there is still nothing as fail-safe as properly encrypting your data.  As keynote speaker Peter Coffee would say about investing in the wrong technology, “doing it better is still doing the wrong thing.”

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.