Townsend Security Data Privacy Blog

The time required to crack an encryption algorithm is directly related to the length of the key used to secure the data.

Every now and then, our development team comes across someone still using antiquated DES for encryption.  If you haven’t made the switch to the Advanced Encryption Standard (AES), let’s take a look at the two standards and see why you should!

Data Encryption Standard (DES):

DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005 [although NIST has approved Triple DES (3DES) through 2030 for sensitive government information].

The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.

To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).

• The DES I contest (1997) took 84 days to use a brute force attack to break the encrypted message.
• In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was "The unknown message is: Many hands make light work". The second challenge took less than three days, with the plaintext message "It's time for those 128-, 192-, and 256-bit keys".
• The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation's Deep Crack computer (built for less than $250,000) and distributed.net's computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read "See you in Rome (Second AES Candidate Conference, March 22-23, 1999)", and was found after checking about 30 percent of the key space...Finally proving that DES belonged to the past.

Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

Advanced Encryption Standard (AES):

Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES. In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.

One of the original requirements by the National Institute of Standards and Technology (NIST) for the replacement algorithm was that it had to be efficient both in software and hardware implementations (DES was originally practical only in hardware implementations). Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous. Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).

Comparing DES and AES

So the question remains for anyone still using DES encryption…
How can we help you make the switch to AES?

Because passwords can easily be compromised, they are considered to be a weak layer of security if used alone.

The use of two factor authentication (2FA) provides an added layer of security beyond just standard username and password credentials. Almost all connections to the IBM i platform are over a network (LAN or WAN), and they are rarely hardwired connections. Because networks are so susceptible to snooping attacks, even LAN connections should be treated like remote access. Remote access to networks containing critical payment, patient information, or financial records can be protected with two factor authentication using your mobile phone to receive SMS and voice verification authentication codes with an easy to deploy, cost effective 2FA solution for the IBM i platform!

Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in industries covered by PCI DSS, HIPAA/HITECH, and GLBA/FFIEC compliance regulations.

• PCI DSS section 8.3 requires two factor authentication for remote access to systems containing credit card information.

• HIPAA/HITECH act recommends two factor authentication to mitigate the risk of lost or stolen personal health information.

• FFIEC guidance also calls for the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against a financial fraud.

Although there are varying levels of enforcement, it is clear that two factor authentication plays a growing and critical security role in both compliance and following best practices.

Since launching Alliance Two Factor Authentication in January, we have had a number of questions about the product and thought we would share them here (along with the answers!)

Q: Does Two Factor Authentication integrate into my already existing Single Sign On (SSO) environment?
A: Yes!  Because the authentication process takes place after the login is complete, it will help strengthen the security around SSO.

Q: In which countries is 2FA available?
A: Two Factor Authentication is a global product. We are partnered with Telesign, which has a network of over 120 countries and the ability to work with 90+ languages to support generation of SMS messages.

Q: What profile security is required to run 2FA?
A: As a native IBM i solution, you assign normal security controls during installation.  End-users have to have use-authority to the library to use the services.

Q: Does your 2FA solution require a mobile app (like Google does) to generate the authentication codes?
A: Since our solution is fully self-contained and installed on the IBM i platform, it does not require a mobile application. The 2FA solution talks over a secure connection to the Telesign service, resulting in a pincode delivered to your mobile device as a SMS text message, or to your standard phone as a voice message.

Q: What if I don’t have access to a phone?
A: In case you don't have a mobile phone, or are in a location where you can't get cell service, your IBM i system administrator can record up to four additional voice phone numbers per user. This gives you a lot of flexibility for putting in phone numbers for home, work, cell with either the text or voice option. In the rare chance you may be someplace without access to any type of phone, Alliance 2FA provides up to 5 one-time codes for use when the phone services are not available. These are randomly generated numeric PIN codes a user has access to, that gives them the ability to authenticate even if they don't have a phone with them at the time.

Developers are also able to improve the security posture of IBM i platforms at the application level as well as during the log-in process with Application Program Interfaces (API). Alliance Two Factor Authentication does full logging of authentication and configuration changes into the IBM security audit journal QAUDJRN. For anyone running our Alliance LogAgent solution to capture information from QAUDJRN into your SIEM solution or your log collection server, this will automatically integrate 2FA in that environment. Developers can use two factor authentication for certain critical functions in the application environment such as sensitive operations about patient information, specific financial transactions, critical system functions (like powering down the system or doing a restore) that you might want to protect with 2FA. We provide a complete API set to our IBM i customers so that they can use a simple structure to initiate a two factor authentication sequence within the application. IBM i web applications can use Java, RPG, or other web languages to call the APIs and fully implement web-based 2FA within the context of the IBM i system where our two factor authentication application is running. The APIs then return to the program the result of the two factor authentication request as either succeeded or failed, and you can take actions at the level of the application to record the event or to deny or allow a particular operation.  

For more information, request our 2FA Resource Kit!

If you have additional questions about 2FA, add a comment below… we would like to hear from you!  

Public and private organizations want to take advantage of cloud-based solutions to reduce costs and improve business performance. Organizations understand that the ultimate responsibility for the security of their data remains with them. Justifiable concerns about the security of cloud-based applications continue to worry security professionals and business executives.

The following list of nine guidelines is intended to serve as a baseline indicator of the maturity and adequacy of the security of a cloud platform and cloud application offering. They are not intended to be exhaustive, but only serve as a set of key indicators. Additional security review of any cloud provider and cloud application should be performed before deployment or migration.

Security professionals (CIOs, CISOs, compliance officers, auditors, etc.) and business executives can use the following set of key indicators as a way to quickly assess the security posture of a prospective cloud provider and cloud-based application or service. Significant failures or gaps in these nine areas should be a cause for concern and suggest the need for a more extensive security review.

The sources for these guidelines include the Cloud Security Alliance, Payment Card Industry Data Security Standards (PCI DSS), the National Institute of Standards and Technology (NIST), the SANS Institute, and others.

The nine key indicators:

1) Inventory of Sensitive Data

All sensitive data processed and stored by the cloud application and service should be properly inventoried and published to stakeholders. Data retention policies should be published for all sensitive data.

2) Data Protection

The use of industry standard encryption for data at rest should be implemented for all sensitive information such social security numbers, credit card numbers, email addresses, and all other personally identifiable information. Encryption keys used to encrypt sensitive data should be protected by appropriately strong key encryption keys, and encryption keys should be stored away from the sensitive data and managed according to industry best practices (separation of duties, dual control, split knowledge, key rotation, etc.). Minimally, encryption key management systems should be validated to the FIPS 140-2 standard.

3) Business Continuity Plan

The cloud and application providers should have a published business continuity plan (BCP) that meets the minimum baseline needs of your organization. The business continuity plan should address backup and recovery, geographic redundancy, network resilience, storage redundancy and resilience, and other common components of a BCP.

4) Incident Response Plan

Both the cloud provider and the application provider should have a current incident response plan available to stakeholders. The plan should cover how incidents are discovered, the response plan for breaches, staff training, and management. All stakeholders should understand that security events are a matter of “when”, not “if”.

5) Active Monitoring

Actively monitoring of all aspects of the cloud and application environment is a core security principal. Real time log collection and monitoring is a minimum component of active monitoring. Additionally application and operating system configuration changes and access to decrypted sensitive data should be monitored (File Integrity Monitoring). Cloud provider infrastructure monitoring should be in place as well as stakeholder access to critical event information.

6) Multi-tenancy Data Isolation

Cloud-based applications and services inherently share computing resources across multiple customers. Proper segregation of your data from other customers using the application is crucial for your security posture. The cloud and application provider should provide credible assurance that there is adequate logical or physical separation of your data from all others sharing computing resources.

7) Vulnerability Assessment and Penetration Testing

Periodic vulnerability and penetration testing should be performed on the cloud provider infrastructure as well as the application environment. Any identified weaknesses should be addressed in a timely manner and disclosed to you and other stakeholders.

8) Independent Security Assessment

The cloud provider’s infrastructure used to host the application should be independently assessed for security compliance and best practices on a periodic basis, and no less than annually. The results should be available to you and other stakeholders. Examples would include SOC 2, SOC 3, SSAE 16, PCI assessment and letter of attestation, etc.

9) Contractual and Legal

Cloud and application providers should provide you with proper legal agreements including a Service Level Agreement (SLA) that defines mutual obligations. Be sure that you understand where you data will be stored and processed and that you understand geographic boundary controls. Additionally, be sure that the agreement between you and your cloud and application provider apply to any third parties who may have access to your data, or who may take possession of your data. Lastly, be sure that you receive prior notification before your data is released to law enforcement or any other governmental agency.

Compliance regulations and security best practices require the encryption of sensitive financial data and the protection of encryption keys with proper key management.  

The financial industry includes banks, credit unions, and other financial organizations, including venture capital firms, private equity firms, investment banks, global investment firms, bank holding companies, mutual funds, exchanges, brokerages, and bank technology service providers, among others. In order to meet compliance regulations, information security programs must be in place to ensure customer information is kept confidential and secure, protected against potential threats or hazards to personal information (cyber-attack, identity theft) and protected against unauthorized access to or use of a customer's personal information. For business owners, database administrators, or developers who need to protect their customers’ sensitive data with encryption; storing the encryption keys within the same database puts that information at risk for a breach.

If you fall within the financial sector, the following will apply:

The Gramm-Leach-Bliley Act (GLBA) - 15 USC 6801 - of 1999 first established a requirement to protect consumer financial information.

TITLE 15 , CHAPTER 94 , SUBCHAPTER I , Sec. 6801. US CODE COLLECTION
Sec. 6801. - Protection of nonpublic personal information

(a) Privacy obligation policy
It is the policy of the Congress that each financial institution has an affirmative and continuing obligation to respect the privacy of its customers and to protect the security and confidentiality of those customers' nonpublic personal information.

(b) Financial institutions safeguards
In furtherance of the policy in subsection (a) of this section, each agency or authority described in section 6805(a) of this title shall establish appropriate standards for the financial institutions subject to their jurisdiction relating to administrative, technical, and physical safeguards.

The Federal Financial Institutions Examination Council (FFIEC) supports the GLBA mission by providing extensive, evolving guidelines for compliance and evaluating financial institutions. Financial services regulations on information security, initiated by the GLBA, require financial institutions in the United States to create an information security program to:

• Ensure the security and confidentiality of customer information
• Protect against any anticipated threats or hazards to the security or integrity of such information
• Protect against unauthorized access to or use of customer information that could result in substantial harm or inconvenience to any customer

Federal Reserve Board Regulations - 12 CFR - CHAPTER II - PART 208 - Appendix D-2
-- Interagency Guidelines Establishing Standards For Safeguarding Customer Information--

… III. Development and Implementation of Information Security Program

… C. Manage and Control Risk

Each bank shall:

… c. Encryption of electronic customer information, including while in transit or in storage on networks or systems to which unauthorized individuals may have access.

Enforcement of these financial industry compliance guidelines fall to five agencies: the Federal Reserve System (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC), and the Office of Thrift Supervision (OTS). In collaboration, these agencies have developed a series of handbooks that provide guidance, address significant technology changes and incorporate a risk-based approach for IT practices in the financial industry. The "Information Security Booklet" is one of several that comprise the FFIEC Information Technology Examination Handbooks, and references encryption in detail.

Summary: Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include:

• Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk
• Effective key management practices
• Robust reliability
• Appropriate protection of the encrypted communications endpoints

To meet the growing need for NIST validated and FIPS 140-2 compliant encryption and key management, the data security experts at Townsend Security provide a certified key management system (Alliance Key Manager) which provides secure key storage and retrieval options for a variety of Enterprise and open source platforms.  Now when nonpublic personal and financial information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed.

To learn more, download the ebook: Encryption Key Management Simplified

Additional Resources:

Federal Financial Institutions Examination Council (FFIEC)

FFIEC Information Technology Examination Handbooks

Gramm-Leach-Bliley Act (GLBA)

Federal Reserve System (FRB)

Federal Deposit Insurance Corporation (FDIC)

National Credit Union Administration (NCUA)

Office of the Comptroller of the Currency (OCC)

Office of Thrift Supervision (OTS)

Encryption and Key Management Can Provide Data Security in the Cloud

Data security is frequently brought up as one of the biggest concerns of moving to the cloud. According to a recent American Institute of CPA’s survey, weighing in at over 63%, the top barrier to adopting or expanding cloud solutions are security concerns. Whether you are looking for a cloud database solution, or moving other sensitive business data to the cloud, choosing your cloud provider will be a critical decision. After all, not all cloud security providers or cloud security solutions are created equal.

If you’re thinking of moving some or all of your sensitive data to the cloud, we’ve compiled a handy list of questions to help you select the right security solutions for your business. Remember every provider is different, so what might be right for one company might not be the best solution for another. It can seem like a daunting process, but as long as you do your research then you’ll be on the right track!

1. If I have my sensitive data stored in the cloud, am I responsible if my cloud provider has a data breach?
   The short answer is yes you are.
   When you have sensitive data and are moving it into a cloud environment you are still ultimately responsible for protecting that data. This can be confusing because cloud vendors make a lot of statements about encryption and compliance, however you are responsible for your overall data protection strategy. Data security is a shared responsibility in the sense that it is the cloud providers network, datacenter, and hardware and you bring the applications, operating system, and data. You are fully responsible for that data. You are also responsible for making sure the cloud provider can back up their security claims by requiring to see specific written compliance reports such as a SOC 3 audit statement, annual security assessment, and a letter of attestation by a QSA auditor.
   

2. Which compliance regulations apply to my business?
   In addition to the 4 listed below, there are also many state laws and regulations that govern security best practices. It is your responsibility to know which ones apply to your company (and which ones apply to your cloud provider location).
   PCI Data Security Standard (PCI DSS) applies to anyone, public or private, who take credit cards for payment. Primary account numbers (PAN) are specifically addressed.
   HIPAA/HITECH Act requires the medical segment (and any business associate) provide data protection for protected health information (PHI) of patients.
   GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency) for protecting all sensitive consumer information.
   Sarbanes-Oxley (SOX) applies to public traded companies for sensitive data of personally identifiable information (PII).
   In addition to these compliance regulations, the Cloud Security Alliance (CSA) has created the Cloud Controls Matrix (CCM) specifically designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider.
   

3. What type of data will be stored in the cloud, and does it need to be encrypted?
   If you are storing any sensitive data (PAN, PII, or PHI) that information must be protected and will need to be encrypted both at-rest and in-transit. Sometimes your whole database must be encrypted, other times you can select to encrypt at the column level. Make sure options are available to cover all your critical information.
   

4. Who will have access to the encrypted data? Will my cloud service provider or other cloud tenants be able to access to my information?
   Only you should have access to your encrypted data and the encryption keys that protect it. In a multi-tenant environment like the cloud, it is even more important to control access. Depending on the value of the data that you store, and your risk tolerance, you may opt to use a virtual private cloud vs. a multi-tenancy cloud environment to store your most sensitive information.
   

5. Where should I store and manage my encryption keys?
   Always use an external Key Manager solution to create, store, manage, and properly rotate your encryption keys. Storing encryption keys in the same database as the encrypted data has always been something to avoid!  Moving your data to the cloud still allows you to choose where you store your encryption keys. Hardware Security Module (HSM), Cloud HSM, virtual appliance (VMware), private cloud instance… just as long as they are stored and managed away from the data they protect!
   

6. How much control do I retain over my encryption keys?
   With using an external encryption key management solution, you should retain complete control over your encryption keys.
   
   

   These next few questions are encryption & key management solution specific. So if you are comparing solutions be sure to ask each vendor!
   

7. Do Townsend Security solutions protect data at-rest or in-transit? What type of encryption is used?
   Yes.  We use industry standard AES Encryption to protect data-at-rest.  We also use 128-bit SSL encryption to protect data-in-transit.
   

8. Can Townsend Security solutions grow to meet my business needs? How scalable are the solutions, is there a limit to how many applications I can (connect)?
   Yes. We believe you should get a flexible solution that will be able to scale up as your business grows, and not have a limit on how many application connect to it!
   

9. Are Townsend Security solutions validated by the National Institute of Standards and Technology (NIST)?
   Yes. Our solutions are NIST validated and also FIPS 140-2 compliant.
   

10. Does Townsend Security Have a “Test Drive” Offering?
    Yes. We always offer a complimentary 30 day evaluation of all of our solutions. Providing a free trial allows you to fully test the concept first, which can help allay fears and and answer any questions before making a commitment. With cloud deployments, you may still need to pay for their implementation services associated with the evaluation period, but in the new world of cloud computing, it is important to look for proof points and results before you make your investment.

Data stored in the cloud can be as secure or accessible as you make it. It is up to each and every cloud user to assess their business risk and uphold an expected standard of security.

It is ultimately your responsibility to make sure your data security plan meets compliance regulations. Make sure you have a strong defense in depth strategy in place and are using industry standard encryption and proper key management to protect your data wherever it resides. Learn more by downloading our Resource Kit on Key Management in the Cloud:

Turn Your Nightmares into a Peaceful Night’s Sleep... Even When Your Sensitive Data is Stored in the Cloud

Compliance regulations and security best practices can be enough to make most developers lose some sleep at night, but when the subjects of encryption & key management in the cloud are brought up… it seems like many of those restless heads start to twitch with other worries as well. It goes beyond what types of data need to be encrypted… to concerns about choosing the right encryption algorithm and properly managing the encryption keys. One of the most reported concerns about encryption is the fear of losing the encryption keys.  If keys are lost, the data remains forever shrouded from view… not only for hackers, but for the you too! Here are three important encryption & key management topics, and three excellent resources that will help you rest easy!

#1 Understand the Importance of Encryption and Key Management

Encrypting your sensitive data is critical to meeting compliance regulations and protecting your organization (and your customers) in the event of a data breach. If you are looking for a non-technical overview, then I highly recommend our most recent eBook, “The Encryption Guide” which covers the importance of encryption as well as critical implementation information such as:

• When to use encryption
• What data you should encrypt
• Where you should encrypt that data
• Encryption best practices
  (and an excellent summary of compliance regulations)
• The importance of encryption key management

In order to have a successful encryption solution you must deploy industry standard encryption methodologies, proper encryption key management (NIST validated solutions), and follow administrative and technological best practices such as dual control and separation of duties.

#2 Learn How to Never Lose an Encryption Key

Industry expert, Patrick Townsend addresses the following four topics in greater depth in his blog article “Never Lose an Encryption Key in Windows Azure” and I hope you will check out what he has to say regarding how Alliance Key Manager running in Windows Azure protects you from this potential problem.

• Backup / Restore
  The first line of defense is always to have a backup of your encryption keys and key access policies. Alliance Key Manager provides you with an option to securely back up your encryption keys, security policies, and server settings and to move this backup out of Windows Azure to your own secure storage...
• Key and Policy Mirroring
  Alliance Key Manager supports Active-Active (real-time key and security policy) mirroring so that you will always have a full set of your encryption keys available to you even after a failover...
• Windows Azure Availability Sets
  This is a feature that helps you avoid unplanned outages due to failures of the cloud infrastructure or planned maintenance activities, providing one more way to get the best reliability for your key management infrastructure in the Windows Azure cloud...
• Mirroring Outside the Windows Azure Cloud
  Lastly, if you are still worried about losing your encryption keys, you can always mirror the keys to a key manager located outside the Windows Azure cloud. We have hardware, hosted, and cloud options for you to choose from!

#3 Know Your Compliance Regulations

Our website is a wealth of information on how encryption and key management meet compliance regulations, and it is frequently a topic in our blog articles!  Storing sensitive data in a multi-tenant environment comes with an additional set of concerns, so we suggest this Cloud Security Alliance (CSA) white paper Security Guidance for Critical Areas of Focus in Cloud Computing, v3 that focuses on the CSA guidance - Domain 11 - recommendations for encryption key management. Hardware and software redundancy insure that you will never lose encryption services or encryption keys. Reliability and redundancy is provided through:

• Dual RAID controlled disk drives and dual power supplies
• Real time, bi-directional key mirroring
• On demand and scheduled backups
• High availability hot failover
• Load balancing support

In the ever-changing, ever-evolving technical world that we live in, knowledge is power! Our goal is to constantly provide updated, educational content and the best solutions for protecting sensitive data with solid encryption & key management. So while you might be losing sleep over your plans for the summer, but you shouldn’t lose sleep over your encryption strategy!

Start sleeping better by downloading the Encryption Guide:

In a business world that is moving more towards virtualization and cloud environments, the need for strong encryption and proper key management is critical. Due to all the recent and well-publicized data breaches, we all know about the ways your brand can be damaged if you don’t encrypt your data. Let’s look at the benefits of encryption, and three of the ways it can have a positive effect on your business.

Customer Confidence = Loyalty: When it all boils down, building trust in your business is what will make or break relationships with your customers, business partners, and potential investors.  After major retail breaches in 2013, a study conducted on 700 consumers showed that the three occurrences that have the greatest impact on brand reputation are data breaches, poor customer service, and environmental disasters. These three incidents were selected ahead of publicized lawsuits, government fines, and labor or union disputes. By being transparent about the ways that you will store and protect their sensitive data (required to operate your business) you will build a level of confidence and trust with your current and potential clients and customers. Using encryption to protect your customers sensitive information is the best way to keep any unauthorized user from successfully using the data if it is accessed. Properly deploying encryption, means you will be sure to use an encryption key manager that separates and securely stores the encryption keys away from the encrypted data. Let your clients know you take data security seriously, and let the would-be thieves know “move along, there is nothing to see here”!

Cloud = Cost Savings: Encryption can help your business move successfully to cloud and virtual environments. Because of the multi-tenant nature, cloud solutions can offer a significant cost savings to most organizations… but what about those other “tenants”, are they able to gain access to your information? What about the treasure trove of information that is attracting more and more hackers? Encryption can make it possible to leverage the benefits and cost savings of the cloud while ensuring the privacy of your sensitive data.

• By using encryption, you can make sure your information is secure when it is “at rest” or “in motion”.
• By properly handling encryption keys with an encryption key manager, you make sure you are the only one able to access your encryption keys.
• By keeping your encrypted data and your encryption keys in separate locations, you remain in control even when your data has left the building.

Customer Compliance = Competitive Advantage: Keeping data secure is the law for many commercial and private organizations. If any sensitive information is stolen or lost, your company may suffer some serious consequences, especially if that information is not encrypted. Using industry standard encryption also helps you meet various compliance regulations and data security standards. Depending on what industry your business is in, different regulations will come into play. As an example, all companies that take credit card payments fall under the Payment Card Industry Data Security Standard (PCI DSS). We all use credit cards and we want assurance that our information is safe. Would you shop online with a company that didn’t take measures to protect your account information?

If a data breach occurs and personally identifiable information is lost, the breached company must notify all their customers who are impacted. Did you know that there are data breach notification laws in 46 of the 50 states? Some regulations have a safe harbor clause, protecting companies from public notification if the stolen data is encrypted and if the encryption keys are not compromised. Along with the frequency, the cost of these breaches continues to escalate: The average cost to an organization for a data breach is up 15% with an average cost of 3.5 million dollars (2014 Ponemon Report). So using encryption to protect data and properly handling key management could save you millions of dollars in the event of a breach. Given the high cost of breach notification doesn't encryption just make sense?

Whether you choose a designated hardware security module (HSM), something designed specifically for virtualized environments (VMware), or data storage in the cloud, encryption and key management solutions can help you:

• Gain competitive advantage and build loyalty by protecting your customers data against access by unauthorized users
• Reduce hardware costs by leveraging virtual environments in the cloud
• Significantly improve your data security strategy while satisfying data compliance and privacy requirements

Overall, data encryption offers many benefits and provides solid protection against potential threats or theft. In addition to the many benefits, encryption is also efficient, easy to use, and affordable! Want to learn more about encryption? Download our eBook “The Encryption Guide”:

Your company may survive a data breach. Your job may not.

Just a few days ago Target announced that CEO Gregg Steinhafel would be stepping down in the wake of the massive data breach that exposed millions of customer credit and debit card numbers. This announcement came following the resignation of Target CIO, Beth Jacob, in March. While the consequences of a data breach are far reaching, few business leaders consider themselves in harm’s way. From this data breach, and many others, executives are beginning to realize that they have far more at risk than fines or a slap on the wrist.

At the end of the day, the responsibility for Governance, Risk Management, and Compliance as well as the protection of customers falls directly on the shoulders of the CEO and other accountable executives. Target is not the only organization to push out leadership in the wake of a breach. In 2012, a massive data breach of Utah Medicaid servers exposed personal information of 780,000 individuals, resulting in the resignation of the state Chief Information Officer (CIO) Steve Fletcher. Also in 2012, the South Carolina Department of Revenue (DOR) was hacked, resulting in the loss of 1.9 million social security numbers, and the South Carolina DOR director, Jim Etter, resigned as well. The Target breach resulted in the first resignation of a senior executive in a major corporation.

While risk management is directly incorporated into other daily activities such as financial transactions, as a whole, businesses have yet to fully adopt risk management practices in data security. The Target breach stands as an example of what can happen to business leaders when data security falls to the wayside, and these leaders should consider this breach a wake up call. Not only are lost jobs a major consequence of a data breach, extensive litigation also follows suit.

Business leaders now may be asking themselves how they can prevent a data breach. To avoid the costs of a data breach, a business leader can ask his or her IT security team these questions:

Are we using encryption everywhere our sensitive data is?

Sensitive data such as credit card numbers, financial data, email addresses, and passwords should be encrypted from the moment you received that data from your customer until the deletion of it from your database. An intelligent hacker will detect any holes in your encryption strategy and exploit them. If Target had been using proper encryption and encrypting customer cardholder data from the moment it entered the Point of Sale (POS) system, they never would have become a poster child for bad security, there never would have even been a story, and Gregg Steinhafel would likely still have his job.

Are we protecting our encryption keys?

While encryption is a major player in a strong data security solution, the success of your encryption relies heavily on how well you protect your encryption keys. What many business executives don’t know is that without an encryption key management solution, their IT administrators may be storing the encryption keys locally in a database alongside the encrypted data. This is a common practice for organizations who are encrypting, but don’t have a comprehensive security plan. Executives should understand that if a hacker gains control of the encryption keys, then they can “unlock” the encrypted data, and the encryption itself is rendered useless.

Are we using two factor authentication to prevent unwanted intruders from gaining access to our data?

Two factor authentication is becoming a widely popular method of ensuring that the person viewing your company’s sensitive data is authorized to do so. Usernames and passwords can be easy to steal, so two factor authentication requires the user to present a piece of information they have (such as a one-use code texted to their cell phone) along with the information they know (i.e. username and password).

Are we monitoring our IT technology with system logging software in order to catch malicious activity in real time?

Detecting suspicious activity on your servers is a critical step to preventing a breach, or preventing one from becoming much worse. With good system event monitoring tools, your IT administrators should be able to catch malicious activity in real time, and be notified if anything out of the ordinary occurs.

According to the 2014 Online Trust Alliance Data Protection & Breach Readiness Guide, of 500 breaches studied in 2013, 89% of them were preventable if proper controls and security best practices were used. Business leaders can play an active role in mitigating data breach risk by asking informed questions and becoming acquainted with basic security practices.

To learn more about the disconnect between executives and their IT teams, download the eBook: Turning a Blind Eye to Data Security (Mending the Breakdown of Communication Between CEOs and CIOs.

A few days ago I noted here that the IBM i (AS/400) did not have a Heartbleed vulnerability, and I shared a link to an IBM statement about this. It looks like IBM got a little ahead of themselves. You need to be aware of the new IBM Heartbleed security advisory for Power Systems.

The advisory only applies to selected IBM i platforms, so be sure to read the entire advisory to understand if you are affected.

This advisory includes the Hardware Management Console (HMC) which is widely used by IBM i customers with multiple logical partitions (LPARs). Even if you use the HMC to manage a single LPAR, you are probably affected by this advisory. Almost everyone enables HMC terminal access services in such a way that they would be exposed to the Heartbleed vulnerability.

If you do have a vulnerable IBM i system, you should follow IBM’s advice and force your IBM i users to change their passwords. If you’ve already done this before applying the recommended updates, you should do it again (after you put on your teflon suit, of course).

Don’t forget to ask your third party vendors about any Heartbleed vulnerabilities in their software.

Townsend Security does not use the affected version of OpenSSL for TLS session security in any of its products, and is not affected by the Heartbleed vulnerability.

Patrick

The OpenSSL Heartbleed security vulnerability is arguably the biggest security exposure in the history of the Internet. While IBM i (AS/400, iSeries) customers may be somewhat isolated from the larger impacts of this vulnerability, there are good reasons not to take this event lightly.

First, a disclaimer: Only IBM can comment in a definitive way on any Heartbleed vulnerabilities in the IBM i. The following are my opinions based on several years of work on the platform.

[UPDATE: IBM has issued a Security Bulletin stating that the IBM i is not effected by CVE-2014-0160 (Heartbleed)]

The first important fact to know is that OpenSSL is not commonly used in traditional IBM i network applications. IBM has an SSL/TLS library named GSKit and a certificate management application named Digital Certificate Manager. The underlying secure TLS implementation is not based on OpenSSL for these IBM-supplied applications. They probably do not pose a security issue for IBM i customers.

IBM does use OpenSSL in some of their IBM i open source applications. For example, the SSH implementation on the IBM uses OpenSSL. On a V7R1 system I started an SSH session and looked at the output:

OpenSSH_4.7p1, OpenSSL 0.9.8m 25 Feb 2010OpenSSH_4.7p1, OpenSSL 0.9.8m 25 Feb 2010

As you can see in the first log message, OpenSSL version 0.9.8m is used in SSH. Fortunately this version of OpenSSL is not vulnerable to Heartbleed. You should check your implementations of SSH, Apache, Websphere, Perl, PHP, and other open source applications to verify that they do not use a version of OpenSSL with the Heartbleed vulnerability.

Most third party vendors use the IBM i SSL/TLS library for secure communications. These applications will not be vulnerable to this new Heartbleed issue. All of the Townsend Security applications are based on the IBM library and not on OpenSSL. However, there are third party IBM i applications that embed OpenSSL or which use the OpenSSL application in the PASE environment. You should immediately contact your application vendors to determine if there are any exposures in their applications.

It is important to understand that while the IBM i platform may not be directly vulnerable to the Heartbleed problem, you may have lost IBM i User IDs and passwords over VPN or other connections which are vulnerable. An exploit of Heartbleed can expose any information that you thought was being protected with session encryption.

Once you know that your IBM i and all of your network services are patched or are not vulnerable to Heartbleed, you should immediately force a password change for all of your users. Don’t take a chance on missing this vulnerability at some point in your network infrastructure and exposing your IBM i data to loss.

Patrick