Security can be hard, expensive, complicated, aggravating, confusing, and did I mention expensive?
As a security company, we hear this perception from new customers all the time. But there is one thing you can do for your IBM i that breaks all of these stereotypes. You can get an immediate boost in system security without much expense and without a big headache. And your users are already using this security technique on their favorite web sites.
Increase Security with Two Factor Authentication (2FA)
Almost every day a phishing email gets through our spam filters and lands in my inbox. Some of these emails are very nicely crafted and look like the real thing. The graphics are professional, the English is excellent and matches my expectations. The terminology is appropriate. Really nice work. And the links in the email are pure poison. Just waiting for that unsuspecting click to start installing malware on my PC to capture my IBM i user profile and password information.
Yup, that’s how it started at Target.
The great thing about Two Factor Authentication is that it gives businesses a lot of additional security for very little upfront cost. The aggravation factor has almost gone away. You no longer need large, expensive servers and tokens that always seem to get lost at just the wrong time. Your IBM i can do exactly what Google, Yahoo, Facebook, your bank, and many other Internet companies are doing to make security better. And your users already have the device they need - their mobile phone!
Alliance Two Factor Authentication uses the same network services and infrastructure that the big boys use for 2FA. This security solution leverages the Telesign global network to deliver PIN codes right to your mobile phone. No servers to rack up and maintain. No lost tokens.
I know, you have some reservations:
I don’t always have signal to my cell phone.
That’s OK, just send the PIN code to your voice phone. A nice lady will read you the code.
I’m in a hurry, I can’t wait for a PIN code.
PIN codes are often delivered in under a second. If you’ve got a mobile provider with a slow network, just have the PIN code delivered to your mobile phone as a voice call.
I left my cell phone home!
Right, just use one of your One Time Codes. No phone of any kind needed!
My IBM i is in Restricted State, it won’t work for me.
Alliance Two Factor Authentication does work in restricted state with a couple of steps.
I don’t want to have to enter a PIN code every time I log on, that’s just way too much work.
Don’t worry, your security administrator can configure Alliance Two Factor Authentication to only ask you once a day to authenticate, or at a user-defined interval. And if an attacker tries to access the IBM i from another device or IP address, they will have to authenticate. And that’s going to be hard to do when you have your mobile phone in your possession.
We’ve made Alliance Two Factor Authentication easy to evaluate and deploy on your IBM i. You can request a free 30-day evaluation from our web site and be up and running within an hour. You can start slowly with a few users, and then roll it out to everyone in your organization. They’ll get it right away.
You don’t have to be the next Target. Get cracking (so to speak).
Encryption and key management continue to be perceived as challenges for .NET developers as more compliance regulations and state laws require the physical separation of encryption keys from the data they protect.
In the past, .NET developers might have used the Windows DPAPI to store encryption keys, or might have stored them in a SQL Server database. That approach does not meet the requirements for dual control, separation of duties, and split knowledge required by security best practices and compliance regulations such as PCI DSS, HIPAA/HITECH, GLBA/FFIEC, and others.
Historically, Microsoft .NET developers expected to experience some heartburn with an encryption key manager because:
- Key management vendors were historically not responsive to the needs of a .NET developer and failed to provide interfaces that work naturally in this environment
- Complex DLL implementations required special .NET wrapper code
- Poor integration with the existing .NET encryption APIs
- The absence of quality sample code which made life difficult for the Microsoft .NET developer or slowed down application development
There have been a lot of changes that now make it easier on Microsoft .NET developers to approach encryption and key management. A key manager solution should:
- Provide a .NET assembly key retrieval library that integrates naturally in all of the Microsoft development languages.
- Provide for key retrieval directly into .NET applications so that developers can use the native .NET encryption libraries.
- By not forcing server-based encryption or the use of special encryption libraries, you decide the best approach to encryption once an encryption key is retrieved to the application (this approach also supports Microsoft’s Managed Code architecture)
- Offer vetted sample code to help speed development! You can install a working .NET GUI application that retrieves encryption keys from the server, and the install includes the Visual Studio project and source code
- Integration of encryption key retrieval routines with the Windows certificate store and native Windows communications facility.
- When a Windows application authenticates, the certificates used for the secure TLS connection are under Windows security and control. The TLS communications is done with native Windows communications APIs. This reduces the chance of loss of certificates and private keys, supports the MMC management of certificates, and integrates with Microsoft’s patch update strategy.
As a developer, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data. These technical hurdles should not stop you from using an encryption key manager to meet compliance requirements for protecting encryption keys.
- Look for a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# or VB.NET code and you are retrieving the encryption key from the HSM.
- Make sure sample code is provided on the product CD to get you up and running quickly. There should be C# and VB.NET sample applications with source code that you can use as a starting point in your projects.
- The .NET Assembly should work with any .NET language including C#, VB.NET, J#, C, and C++. It should also work with the Common Language Runtime (CLR) environment, and with Stored Procedures. Make sure you can mix and match your .NET languages, databases, and OS platforms.
The combination of NIST validated encryption and an affordable FIPS 140-2 compliant key management solution with solid support for the Microsoft .NET developer makes our Alliance Key Manager a great option for users who need to meet security best practices and compliance regulations for key management. It is time to change your encryption strategy to incorporate solid encryption and an external key manager, whether that is an HSM, Cloud HSM, or virtual environment.
Download our white paper, Key Management in the Multi-Platform Environment, for more information on securing your encryption keys.
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!
"I am collecting data in Drupal. What data do I need to encrypt?"
Organizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.
Federal/State Laws and Personally Identifiable Information (PII)
Federal and State laws vary in terms of what they consider Personally Identifiable Information (PII), but there is a lot of commonality between them. PII is any information which either alone or when combined with other information, which can identify an individual person. Examples include email addresses, first name, last name and birth date.
[Download white paper for complete list]
Educational Information Covered by FERPA
Educational institutions who fall under the FERPA regulation must protect PII as well as information like student names, student ID numbers, and family member names.
[Download white paper for complete list]
Federal Agencies and FISMA
Federal Agencies must evaluate their systems for the presence of sensitive data and provide mechanisms to insure the confidentiality, integrity, and availability of the information. Sensitive information is broadly defined, and includes PII, as well as other information classified as sensitive by the Federal agency. Sensitive information might be defined in the following categories: medical, financial, proprietary, contractor sensitive, or security management.[Download white paper for complete list]
Medical Information for Covered Entities and HIPAA/HITECH
The HIPAA/HITECH Act defines Protected Health Information (PHI) to include PII in addition to the following PHI: Patient diagnostic information, payment information, health plan beneficiary numbers, full facial photographs, etc.
[Download white paper for complete list]
Payment Card Data Security Standard (PCI DSS)
The Payment Card Industry Data Security Standards (PCI DSS) require that merchants protect sensitive cardholder information from loss and use good security practices to detect and protect against security breaches. If you accept or process credit card or other payment cards, you must encrypt the Primary Account Number (PAN).
Financial Data for FFIEC
Banks, credit unions, and other financial institutions must protect Non-public Personal Information (NPI) which includes personally identifying financial information. In addition, you should protect income, credit score, etc.
[Download white paper for complete list]
Encrypting Data in Drupal
Townsend Security is helping the Drupal community encrypt sensitive data and properly manage encryption keys. Developers who need to protect sensitive data know that storing their encryption keys within the content management system (CMS) puts their data at risk for a breach. With Key Connection for Drupal and Alliance Key Manager, administrators are now able to keep their encryption keys secure by storing them remotely and only accessing them when the encryption/decryption happens.
The Key Connection for Drupal module is a plugin for the Encrypt project that allows you to easily encrypt sensitive data with NIST-validated AES encryption and securely retrieve and manage encryption keys from Townsend Security’s FIPS 140-2 compliant Alliance Key Manager. With an easy to use interface and certifications to meet compliance requirements, you can rest assured knowing your data is secure.
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
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)
Many compliance regulations and security best practices require the encryption of sensitive data and the protection of encryption keys with proper key management.
Security best practices and PCI DSS compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Anyone who needs to protect sensitive data in their database, needs to know that storing the encryption keys within the same location puts data at risk for a breach. Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.
For any company that accepts credit card payments, the Payment Card Industry Data Security Standards (PCI DSS) issues 12 requirements that must be met in order to be compliant. It can seem overwhelming at first, but the PCI council that issues PCI DSS also provides detailed reference guides and instructions on each requirement.
Let’s take a brief look at all twelve items:
Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
Requirement 3: Protect stored cardholder data*
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 6: Develop and maintain secure systems and applications
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Identify and authenticate access to system components
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes
Maintain an Information Security Policy
Requirement 12: Maintain a policy that address information security for all personnel
Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43. The PCI Security Standards Council (PCI SSC) website (http://www.pcisecuritystandards.org) contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations.
* Requirement 3 addresses the need for encryption and key management, stating:
“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”
The PCI Security Standards Council also issues their Cloud Computing Guidelines (https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Cloud_Guidelines.pdf) and additional information around virtualization of data protection solutions so you can be PCI compliant with a cloud-based solution for encryption and key management.
Other compliance requirements for protecting information go beyond cardholder data (PCI focuses on PAN or the Primary Account Number specifically) and also require that personally identifiable information (PII) such as names, birthdates, email address, zip codes, usernames, or passwords be protected properly with encryption and key management. To meet the growing need for NIST validated and FIPS 140-2 compliant solutions, 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 sensitive information can easily be encrypted and the encryption keys properly managed.
For more information on encryption, download the latest eBook, The Encryption Guide:
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!
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.
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.
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.
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.
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!
- 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!
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.
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!
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.
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:
IBM i users who need to meet compliance regulations for actively monitoring their systems are faced with the challenge of collecting system and security events from a variety of log sources. Collecting events from the security audit journal QAUDJRN is a fundamental requirement, but is it the only place that contains significant security events? The answer is no, there are also significant security events in the system history message file QHST.
The most significant security events contained in QHST are the user log on and log off messages. These are stored in the QHST message files with message IDs CPF1164 (log on) and CPF???? (log off). User log on and log off events are, of course, critical for active monitoring of system access, especially for highly privileged users such as QSECOFR and any user with All Object (*ALLOBJ) and security special authorities of Audit (*AUDIT) and ????. The log on and log off activities recorded in the QHST message files are not available in the security audit journal QAUDJRN, so you must be able to retrieve these messages from QHST to meet compliance regulation requirements for log collection and active monitoring.
Alliance LogAgent supports this requirement by enabling the collection of these events from QHST message files. You can filter QHST message to collect only events for:
- Log on and Log off messages for all users
- Log on and Log off messages for only highly privileged users
- Log on and Log off messages for only QSECOFR
- All QHST messages
User log on and log off messages are not the only events that have security information. Most IBM i customers will select the Alliance LogAgent option to process all messages in QHST. This gives you a complete record of all events in the QHST message file in your log collection central repository.
There are many challenges in processing messages in the QHST file. These include:
- The QHST information is in an IBM proprietary format that is impossible for log collection servers and SIEM solutions to process. The messages must be converted to a usable format.
- QHST message files have a special naming convention and the system automatically generates new QHST message files on a regular basis. You must detect new message files and keep track of which files and messages have been processed.
- There are no event-driven APIs that allow you to collect new QHST messages in real time. Your QHST collector application must detect new events and process them quickly.
- The QHST files are not updatable, so your QHST event collector must keep track of the messages that have been processed, and must resume after a system IPL or a system failure without lost information.
- QHST messages are not automatically transferred to a log collection server or SIEM solution. Communications programs must be able to transfer the messages in real time.
Alliance LogAgent meets all of these challenges. QHST message files are automatically processed in near real time, and handles the generation of new QHST message files by the system. Messages are converted from the proprietary IBM format to the industry standard syslog format (RFC 3164) and converted from EBCDIC to ASCII. Messages are then transmitted to the log collection server or SIEM solution securely and in real time.
The Alliance LogAgent QHST message collector is a part of the base product. If you are currently using LogAgent to process QAUDJRN events, you can just enable the QHST option and you will start processing messages the next time the Alliance LogAgent subsystem starts. If you are implementing Alliance LogAgent for the first time, just enable the Logagent QHST collector before you start the subsystem.
View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.
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: