How to implement solutions that are based on compliance standards and meet security best practices.

As more and more Enterprise businesses move into virtual and cloud environments, they face challenges and security issues in these multi-tenancy situations. VMware customers benefit from the many operational and cost efficiencies provided by VMware virtualization technologies both in traditional IT infrastructure and in cloud environments. As VMware customers deploy data encryption solutions as a part of their defense-in-depth strategy, the need for compliant encryption key management can present barriers to a good encryption implementation. It is possible to deploy a proper encryption key management solution within the VMware infrastructure without the need for traditional hardware security modules (HSMs) when this approach is appropriate to the security needs of the organization.

Here is some high level guidance on how to deploy and protect a solid encryption and key management solution for VMware within your virtual or cloud environment. While these recommendations are general in nature (actual VMware deployments will use different VMware applications and architectures to meet specific user, application, and security needs) they can provide a good roadmap.

Seven General VMware Recommendations

1. Identify and Document Trusted and Un-Trusted Applications

Properly identifying application groups based on the level of trust is critical for a secure implementation of virtualized applications and encryption key management services. Create and isolate a management cluster for your core VMware applications such as vSphere, vShield, etc. Identify application groups and their associated level of trust, and isolate applications into appropriate workgroups. Avoid mixing trusted and untrusted applications in a workgroup.

You should consider creating a security workgroup to contain your third party security applications such as encryption key management, authentication services, active directory, system logging, and other applications whose primary function is to assist in securing your applications in your VMware environment.

In preparation for properly securing these environments, create an inventory of all Virtual Machines managed in each workgroup. For each workgroup and virtual machine, identify the security controls that will be required for each one (network segmentation, storage segmentation, system logging, active monitoring, etc.). VMware flow tools can assist with this documentation.

2. Restrict Physical Access

Fundamental to all IT security implementations is proper security of the physical environment. This means proper physical security controls and physical monitoring of the data center as well as good auditing and procedural controls. These physical controls should also apply to access of VMware management and security applications. You can look to the PCI Data Security Standards and guidance for information on appropriate physical controls. You can also refer to standard security guidance in SOC 2 and SOC 3 assessments for information on physical controls. When deploying on a cloud platform it is always a good idea to ask the Cloud Security Provider (CSP) for a copy of the PCI letter of attestation, or an SOC 2 / SOC 3 report.

3. Isolate Security Functions

Because security applications are often a target of cyber-criminals, you should isolate them into their own security workgroup and implement the highest level of VMware security. Only trusted VMware administrators should have access rights to the encryption key management solution, system logs, and audit reports. Be sure to actively monitor access to and use of all encryption key management, key retrieval, and encryption services.

4. Change VMware Default Passwords

Review all VMware applications used to secure and manage your VMware environment and change the default passwords as recommended by VMware. The failure to change default passwords is one of the most common causes of security breaches.

5. Implement Network Segmentation

Network segmentation is easy to accomplish with VMware network management and security applications and you should implement network segmentation to isolate applications that process sensitive information from applications that do not require as high a level of trust. Additionally, you should provide network segmentation for all third party security applications such as your encryption and key management solution. Network segmentation should include all high availability and business recovery infrastructure. Do not rely on virtual network segmentation alone; use firewalls that are capable of properly securing virtual networks.

6. Implement Defense in Depth

The VMware management and security applications provide for a high level of security and monitoring. They also provide hooks and integration with third party security applications that provide system log collection, active monitoring, intrusion detection, etc. Encryption is a critical part of a defense-in-depth strategy, and protecting encryption keys is the most important part of an encryption strategy. Regardless of the operating systems in your application Virtual Machines, your solution should provide encryption key management, key retrieval, and encryption services for your business applications and databases running in your VMware infrastructure.

7. Monitor VMware Administrative Activity

Use an appropriate SIEM solution to collect VMware application and ESXi hypervisor system logs and perform active monitoring. The log collection and SIEM active monitoring solutions should be isolated into a security workgroup that contains other third party security applications such as Townsend Security’s Alliance Key Manager.

For additional information on securing Alliance Key Manager for VMware, our encryption key management solution, request the VMware Resource Kit containing the Guidance Document and other valuable resources:

As solutions and implementations vary a great deal, always consult with a security specialist and compliance auditor for specific guidelines for your industry and environment! Just contact us to get started!

An Introduction to Townsend Security's VMware Guidance Document

VMware customers benefit from the many operational, and cost efficiencies provided by VMware virtualization technologies both in traditional IT infrastructure and in cloud environments. As VMware customers deploy data encryption solutions as a part of their defense-in-depth strategy, the need for encryption key management can present barriers to a good encryption implementation. This article provides high-level guidance, general in nature, on how deploy and protect Alliance Key Manager for VMware within your VMware environment. Actual VMware deployments of Alliance Key Manager for VMware will use different VMware applications and architectures to meet specific user, application, and security needs.

General VMware Recommendations

Identify and Document Trusted and Un-Trusted Applications

Properly identifying application groups based on the level of trust is critical for a secure implementation of virtualized applications and encryption key management services. Create and isolate a management cluster for your core VMware applications such as vSphere, vShield, etc. Identify application groups and their associated level of trust, and isolate applications into appropriate application workgroups. Avoid mixing trusted and untrusted applications in a workgroup.

You should consider creating a security workgroup to contain your third party security applications such as encryption key management, authentication services, active directory, system logging, and other applications whose primary function is to assist in securing your VMware environment. Encryption key management services provide by Alliance Key Manager should be implemented in this separate security workgroup used for critical, non-VMware security applications.

In preparation for properly securing these environments, create an inventory of all Virtual Machines managed in each workgroup. For each workgroup and virtual machine, identify the security controls that will be required for each one (network segmentation, storage segmentation, system logging, active monitoring, etc.). VMware flow tools can assist with this documentation.

Restrict Physical Access

Fundamental to all IT security implementations is proper security of the physical environment. This means proper physical security controls and physical monitoring of the data center as well as good auditing and procedural controls. These physical controls should also apply to access to VMware management and security applications. You can look to the PCI Data Security Standards and guidance for information on appropriate physical controls. You can also refer to standard security guidance in SOC 2 and SOC 3 assessments for information on physical controls. When deploying on a cloud platform it is always a good idea to ask the Cloud Security Provider (CSP) for a copy of the PCI letter of attestation, or an SOC 2 / SOC 3 report.

Isolate Security Functions

Because security applications are often a target of cybercriminals, you should isolate them into their own security workgroup and implement the highest level of VMware security. Only trusted VMware administrators should have access rights to Alliance Key Manager, system logs, and audit reports. Be sure to actively monitor access to and use of all encryption key management, key retrieval, and encryption services.

Change VMware Default Passwords

Review all VMware applications used to secure and manage your VMware environment and change the default passwords as recommended by VMware. The failure to change default passwords is one of the most common causes of security breaches.

Implement Network Segmentation

Network segmentation is easy to accomplish with VMware network management and security applications and you should implement network segmentation to isolate applications that process sensitive information from applications that do not require as high a level of trust. Additionally, you should provide network segmentation for all third party security applications such as Alliance Key Manager. Network segmentation should include all high availability and business recovery infrastructure. Do not rely on virtual network segmentation alone; use firewalls that are capable of properly securing virtual networks.

Implement Defense in Depth

The VMware management and security applications provide for a high level of security and monitoring. They also provide hooks and integration with third party security applications that provide system log collection, active monitoring, intrusion detection,etc. Encryption is a critical part of a defense-in-depth strategy, and protecting encryption keys is the most important part of an encryption strategy. Regardless of the operating systems in your application Virtual Machines, Alliance Key Manager will provide encryption key management, key retrieval, and encryption services for your business applications and databases running in your VMware infrastructure.

Monitor VMware Administrative Activity

Use an appropriate SIEM solution to collect VMware application and ESXi hypervisor system logs and perform active monitoring. The log collection and SIEM active monitoring solutions should be isolated into a security workgroup that contains other third party security applications such as Alliance Key Manager.

For more detailed information, read the entire VMware Guidance Document and other materials available in this VMware Resource Kit: 

Organizations running SQL Server Enterprise edition gain the added benefit of SQL Server transparent data encryption (TDE) and extensible key management (EKM). The encryption capabilities of Enterprise edition enable users to easily encrypt data at the column level of a database, and EKM allows users to store encryption keys using a third-party encryption key management solution. These streamlined capabilities of SQL Server Enterprise Edition have made SQL Server one of the easiest databases to encrypt, and therefore it’s popularity hasn’t waned.

One of the biggest issues facing SQL Server users today is maintaining security as users move their SQL databases to the cloud. While Microsoft Azure remains a popular cloud service provider (CSP) for SQL users, Amazon Web Services (AWS) and VMware are also common amongst organizations moving to the cloud, especially those migrating a multi-platform environment. Each of these top-tier CSPs offer security solutions to help you protect your cloud environment; however, when considering security in the cloud there are two important things to remember: The security offered by your CSP won’t provide you with a complete security solution, and the security solutions you bring to protect your data in the cloud can fail if not implemented correctly.

Don’t rely on the cloud for complete security!

Your CSP should provide your business with some security, but their solutions are likely limited. Most CSPs will offer firewall protection, for example. Top-tier CSPs have also undergone some certifications such as Payment Card Industry (PCI) and FedRAMP compliance. It is important to remember, however, that relying on firewalls alone is not enough to prevent intruders, and cloud certifications never mean that your company will automatically meet these compliance regulations as well. A comprehensive data security plan is required for any business operating in the cloud, and this typically requires using third-party security solutions to ensure your business meets compliance and is adequately protecting data.

Remember these two things when protecting data in the cloud:

• The security solutions offered by your cloud vendor are rarely enough to prevent a data breach.
• Just because your cloud service provider is compliant, doesn’t mean you are.

Storing data in SQL Server in the cloud presents new security challenges. Hackers or malicious users can gain access to sensitive data easily through common hacks. Easy hacking of SQL Server is a result from:

• Incorrect configuration of cloud provider’s firewall
• Attacks through weaknesses that could have been addressed by updating and patching SQL Server
• Missing or weak passwords
• social engineering and account hacking
• Lax administrative access

When it comes to securing SQL Server in the cloud, you should also always consult your legal and auditing team (or consultants) before assuming that your data is safe and you are compliant with any industry security regulations. On a general level, it’s important to include these security measures in your holistic security plan:

• Intrusion prevention
• System logging and monitoring
• Encryption & key management
• SSH in place of passwords
• Limited access to sensitive data
• Separation of duties and split knowledge when accessing encryption keys and sensitive data.

It’s important to remember that your business continuity relies on your own security plan. Regardless of the environment, when your organization experience a data breach, ultimately the responsibility is yours. Your customers, as well as your employees, rely on you to protect their data, and if you fail to do so, the consequences may include loss of customer loyalty and a severely damaged brand. The ultimate way to prevent access to sensitive data is using encryption and encryption key management.

To learn more about how Microsoft SQL Server Enterprise Edition can easily be secured in the cloud, download:

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!  

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:

Do you know which of these 3 key regulations apply to you and your company?

Secure system logging on your IBM i (AS/400) can do more than help you meet compliance requirements, it can also help you stop a data breach before it happens!  We will take a quick look at three of the major regulations; PCI DSS, GLBA/FFIEC, HIPAA/HITECH, (keep in mind, there may be other compliance regulations that apply to system logging in your industry as well).

All regulations say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them. It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files, tamper resistant, and verifiable.

PCI DSS

Section 10 requires logging for anyone who collects credit card data

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.6.x v3 (Nov 2013) noted this clarification: Clarified the intent of log reviews is to identify anomalies or suspicious activity, and provided more guidance about scope of daily log reviews. Also allowed more flexibility for review of security events and critical system logs daily and other logs events periodically, as defined by the entity’s risk management strategy.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC

Recommends data security logs of actions that could affect financial reporting or fraud for financial institutions

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

FFIEC Action Summary

Financial institutions should gain assurance of the adequacy of their risk mitigation strategy and implementation by:

• Monitoring network and host activity to identify policy violations and anomalous behavior
• Monitoring host and network condition to identify unauthorized configuration and other conditions which increase the risk of intrusion or other security events
• Analyzing the results of monitoring to accurately and quickly identify, classify, escalate, report, and guide responses to security events
• Responding to intrusions and other security events and weaknesses to appropriately mitigate the risk to the institution and its customers, and to restore the institution's systems

HIPAA / HITECH ACT

Requires system logs of access to Protected Health Information (PHI) in the medical sector

• Security Management Process - §164.308(a)(1)(ii)(D):
  - Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)(.c) 
  …the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”
• Access Controls - § 164.312(b)
  (section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

System logging is important across all operating systems, however the IBM i is a major target for data theft because of the volume of information that can be managed in the system. Because the IBM i system can handle multiple applications, it doesn’t log information like others do. The IBM i collects logs simultaneously from multiple sources and may deal with large volumes: Up to 3,500 events per second…250 Million of events per day! These events need to be consolidated and correlated in a separate location, usually a Security Information and Event Management (SIEM) console, in order to see the whole picture and understand potential attacks on the system.

Because many unwanted intrusions start with a simple password hack that gives deeper access into your system, there is usually a long trail visible within system logs. What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management (forensics show 69% of breaches were detectable via log evidence). Everything, starting from the original breach, can be detected and identified with proper monitoring of the system logs.

To delve deeper into system logging, we are sharing a resource kit of materials by industry expert Patrick Townsend about logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between the IBM i and SIEM Console.

Alliance LogAgent from Townsend Security

• Creates real-time logs that ALL SIEM consoles can read
• Forwards important information to your SIEM console in a standard format
• Uses SSL/TLS encryption to secure delivery

Two Factor Authentication (2FA) and a look at the compliance regulations that require identity verification for remote access.

The use of two factor authentication provides an added layer of security beyond just a username and password. Because passwords can be guessed, stolen, hacked, or given away, they are a weak layer of security if used alone. Since frequent access happens from outside of the network, remote login is considered high-risk and requires additional steps to confirm user identity. Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in the retail, healthcare, and financial industries.

Payment Card Industry Data Security Standards (PCI DSS)

The PCI Security Standards Council has stated that they will continue to change and evolve compliance regulations over time as attacks change. In PCI DSS section 8.3 the requirement states that organizations must “incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.”  The objective of this requirement is to ensure that merchants implement strong access control measures so that authorized individuals with network and computer access can be identified, monitored, and traced.

Requirement 8: Assign a unique ID to each person with computer access. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data.

Requirement 8.3: Incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.

Note: Two factor authentication requires that two of the three authentication methods (something you know - something you have - something you are) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two factor authentication.

Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act

HIPAA was an act signed in 1996 by President Bill Clinton, meant to improve the efficiency of the healthcare system by encouraging the use of Electronic Data Interchange (EDI) when accessing Protected Health Information (PHI). Covered entities must develop and implement policies and procedures for authorizing PHI access in accordance with the HIPAA Security Rule Administrative Safeguards 164.308(a)(4) [Information Access Management: Access Authorization] and Technical Safeguards 164.312(d) [Person or Entity Authentication] and the HIPAA Privacy Rule at §164.508 [Uses and disclosures for which an authorization is required].

The HIPAA Security Rule requirements have most recently been expanded via the HITECH Act, which establishes mandatory federal security breach reporting requirements with expanded criminal and civil penalties for non-compliance. To remain HIPAA compliant and avoid fines for HITECH Act non-compliance, strict control over access to patient records must be demonstrated.

HIPAA/HITECH requirements regarding the transmission of health-related information include adequate encryption [164.312(e)(2)(ii) when appropriate, and 164.312(a)(2)(iv)], authentication [164.312(d)] or unique user identification [164.312(a)(2)(i)] of communication partners. By selecting Two Factor Authentication (2FA), users would be required to combine something they know, something they have, or something they are; thereby providing more secure access to PHI files. Protected Health Information can be account numbers, medical record numbers and geographic indicators among other private consumer information. It is important that only those health care workforce members who have been trained and have proper authorization are granted access to PHI.

Gramm-Leach-Bliley Act (GLBA) & Federal Financial Institutions Examination Council (FFIEC)

The Federal Financial Institutions Examination Council (FFIEC) is charged with providing specific guidelines for evaluating financial institutions for GLBA (Gramm-Leach-Bliley Act) regulations compliance. The FFIEC also provides guidance around the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against financial fraud with the document, “Authentication in an Internet Banking Environment” (v.3). For banks offering internet-based financial services, the guidance document describes enhanced authentication methods that regulators expect banks to use when authenticating the identity of customers using online products and services, as follows:

• Financial institutions offering internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. Furthermore, the FFIEC considers single-factor authentication (as the only control mechanism) to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
• The implementation of appropriate authentication methodologies should start with an assessment of the risk posed by the institutions’ Internet banking systems. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services.
• Account fraud and identity theft are frequently the result of single-factor (e.g. ID/password) authentication exploitation.
• Where risk assessments indicate that the use of single factor authentication is inadequate, financial institutions should implement multi-factor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

The FFIEC is a government agency which works with many other government agencies to unify how financial institutions should be supervised. The guideline documents recommend banks treat the FFIEC as baseline compliance for safe online authentication and transaction verification. Since all single factor authentication techniques can be easily compromised, financial institutions should not rely solely on any single control for authorizing high risk transactions, but rather institute a system of layered security with multi-factor authentication.

Although there are varying levels of enforcement, guidelines vs. laws vs. fines, it is clear that two factor authentication plays a critical security role in both compliance and following best practices. This trend will only grow within various industries and throughout the overall data security environment.

Townsend Security offers Easy to Deploy, Cost Effective Two Factor Authentication Solution for the IBM i Platform

Alliance Two Factor Authentication brings mobile SMS and voice verification to the IBM i platform. The solution was built to solve large scale problems in a cost-effective manner and appropriately addresses the concerns raised in the various guidelines and standards listed above. Remote access to networks containing critical payment, patient information, or financial records can be protected with the Alliance 2FA solution using your mobile phone to receive authentication codes.

For more information, request our 2FA Resource Kit!