"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

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)

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!

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:

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.

Patrick

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:

Townsend Security recently traveled down south to Austin, TX for the Drupal developer annual conference, DrupalCon 2014! In partnership with Cellar Door Media, Townsend Security recently released Key Connection for Drupal, the first encryption key management solution for Drupal. Key Connection for Drupal enables developers to use world NIST-validated AES encryption FIPS 140-2 compliant key management for data stored in Drupal.

At DrupalCon 2014 Townsend Security introduced our new Drupal Developer Program. The Drupal Developer Program puts encryption and key management in the hands of developers, free of charge, to implement and test.

Key Connection for Drupal
Key Connection for Drupal allows Drupal users to encrypt sensitive data and do it right. Historically, the Drupal encrypt module only allowed users to store encryption keys natively, or in other less secure ways. Key Connection for Drupal enables encryption keys to be stored off-site in a FIPS 140-2 compliant encryption key manager. Townsend Security’s Alliance Key Manager is available as an AWS, Microsoft Azure, or VMware instance; as a hosted appliance in the cloud; or as a physical HSM. Alliance Key Manager can also perform onboard encryption, meaning that developers can send sensitive data to the key manager to be encrypted with NIST validated AES encryption so that they can provably meet compliance regulations and their encryption keys never leave the key manager.

Developer Program
At Townsend Security, we know that encryption and encryption key management are critical to strong digital security and meeting several compliance regulations such as FISMA, PCI DSS, HIPAA, etc.  With Key Connection for Drupal we’ve made encrypting data and managing encryption keys easier than ever. We also know that for strong security to become ubiquitous, it must be easy to obtain and implement. That’s why we’ve begun a developer program that puts technology in the hands of the people who use it most. Drupal developers can now join our developer program, for no fee, and receive up to two free Alliance Key Manager licenses to test internally for non-production use. We hope that through the developer program we can help improve data security in Drupal and the community.

Community
Townsend Security firmly believes in giving back to the Drupal community. Through the Developer Program and our participation in the Drupal Association we hope to continue to bring strong security to the Drupal community as we move forward. To sign up for the Drupal Developer Program, contact us here. To learn more about Key Connection for Drupal, visit the Drupal.org project site here.

Active monitoring is one of the core security recommendations to help prevent unauthorized access to sensitive systems and information. It is a requirement of a wide variety of compliance regulations such as PCI-DSS, HIPAA/HITECH Act, GLBA/FFIEC, FISMA, and many others. From a security perspective, active monitoring makes it into the SANS Top 20 list of things you should do, and is a key recommendation from the US Cyber Security teams.

What are the core requirements for active monitoring and what are the special challenges for the IBM i platform? Some core requirements include:

• Centralize security events from all servers and PCs
• Perform real-time collection to one central repository
• Real-time monitoring of events
• Conduct real-time event correlation for pattern recognition
• Store events in historical archives for forensics
• Pro-actively alert the security team for possible breaches
• Provide event query and reporting services

To meet these requirements for active monitoring, the IBM i can’t be an island of event information. IBM i security events must be consolidated with event information for all of your PCs, servers, and network devices to get a complete picture. Because the volume of events is typically quite large, most organizations will deploy a centralized log collection server combined with a SIEM solution that provides event correlation, real-time monitoring, alerting, and log collection archival.

One of the biggest challenges for IBM i customers is the large number of sources for log information. These include:

• IBM Security Audit Journal QAUDJRN
• System operator message queue (QSYSOPR, QSYSMSG)
• System history message file QHST
• IBM exit points (SQL, Telnet, FTP, and many more)
• Linux/Unix style logs (Apache, OpenSSH, Perl, PHP, etc.)
• DB2 column access
• User and ISV applications

A good security event collection strategy will have to address all of these sources. Added to the large number or sources are some additional challenges:

• Security event collection applications are not provided by IBM. They must be written by in-house developers or acquired from third parties.
• Security information is in non-standard, proprietary IBM formats.
• There are no native communications applications to securely transmit event information to a log collection or SIEM server.
• There is no application management structure (start, stop, re-start, audit, etc) for log collection activities.

Alliance LogAgent helps IBM i customers meet all of these challenges. It collects security event information from all significant log sources, converts information to industry standard formats including the syslog format (RFC 3164) and Common Event format (CEF), provides filtering options for messages, and securely transmits them to the log collection server or SIEM solution. Alliance LogAgent keeps track of event sources and won’t skip messages due to an IPL or network outages.

Alliance LogAgent is compatible with all major log collection servers and SIEM solutions, and is an affordable solution for small organizations. View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

 
Patrick

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