Townsend Security Data Privacy Blog

(That’s the Way) You Need it…

Now that you have the tune from Journey running through your head, let’s talk about how you are going to protect your data with encryption and key management.  

So you have all this sensitive data that you need to secure… how are you going to protect it? What kind of key management choices do you have? How do you decide what encryption to use? Just how do you decide what you need, and where you will put your key management device, and will it be hardware or virtual? In many cases, regulations require you to protect sensitive information. Beyond being a compliance requirement, it is also a responsibility to your business and your customers. We understand all those questions can be a bit daunting at first, but there are a variety of encryption key management options to choose from.

The main consideration that will be determined within each of the following factors is your Risk Tolerance. What kind of sensitive data are you storing? What will happen to that information if there is a data breach? What will the impact be to your company, to your customers, if that information gets accessed by the wrong people? What are your liabilities? No matter whether it lives in a single PC hard drive or a vast data center, or even in a shared cloud environment, the type of information you need to protect will have a large impact on what level of risk tolerance you have.  

Here are four factors you need to consider as you devise or revise your data security plan:

Infrastructure: Where your data lives (client side application) determines what kind of options you have. Is your data all in one location (on a PC, or in a data center)? or is it in the cloud? or a combination? Are there requirements that would limit where your key server could be located? How will data need to be transmitted from one location to another? Once you have a clear picture of the sensitive information you are responsible for then you can move on to the next set of questions.  

Compliance Regulations: If you are dealing with Personal Identifiable Information (PII) or Protected Health Information (PHI) or Payment Card Industry (PCI), you have a great responsibility to protect that information and meet different compliance regulations. Depending on what industry you are in and where you live, different regulations may come into play. If you take credit card payments, you will certainly fall under PCI-DSS and be required to encrypt that data. If you are a part of or even partner with the medical sector then you also need to comply with HIPAA/HITECH Act requirements for security of Protected Health Information (PHI). GLBA/FFIEC sets regulations for banks, credit unions, credit reporting agencies, and anyone in the financial industry. FISMA is for Federal US Government Agencies and businesses that partner with them. The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement. On top of those regulations, more than 45 states also have their own privacy rules that strongly recommend encryption of any personally identifiable information (PII).

Availability:  Beyond just the availability of your encryption key management options, think about how many people need access to your data. What kind of security procedures do you need in order to keep the wrong people out and yet allow the right people to do their jobs? Will you have a key management system that supports separation of duties and dual control of your encryption keys?  

Cost: Your budget will also determine what kind of key management system you use. While cloud options may present a cost savings, you would potentially need a higher risk tolerance in a shared environment.  

Once you have identified your level of risk tolerance and the other factors listed, you will need to consider what kind of encryption and key management options are available to you:

Data Center - Hardware Security Module (HSM) - This is probably the most common option for companies that have their own data centers. The HSM is “under your roof” and you provide the security and IT support for the device.  

Cloud HSM -  If your data lives in the cloud and in a variety of client side applications, perhaps hosting your key server in a cloud HSM makes more sense for you. In a cloud HSM, look for two dedicated redundant HSMs in geographically diverse locations that are managed for you. Options and access will vary depending on which cloud HSM solution you deploy. With Alliance Key Manager Cloud HSM, you maintain exclusive access to your key servers.

In the Cloud -  If your data lives primarily in the cloud, you may want to go with a key server deployed directly in the cloud. Ways to make that option more secure would be to locate your key server in a different cloud environment from your data or even in a virtual private cloud (VPC). Cloud options are certainly cost-effective and easy to deploy, just make sure that you have a high enough risk tolerance for a shared environment!

I know there are a lot of questions that each company needs to consider and answer for themselves during this security planning process. The good news is that we have solutions that can encrypt your data and protect your encryption keys in all of those locations. We offer affordable and easy to deploy solutions with what we feel is the best customer support in the industry.  

Check out this complimentary eBook on Key Management, then give us a call and let’s see how we can partner together to protect your data!
 

Great Q&A session from the latest webinar from Townsend Security!

As we discussed in the blog on Secure Managed File Transfer and PGP Encryption, using the core components of a total encryption strategy can help you meet compliance requirements, and improve your data security posture!

Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE). After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.  Here is a recap of that Q&A session:

Q: Is there any reason why I can’t just transfer my file from my IBM i platform to Windows and then PGP encrypt it there.

Patrick: That is a great compliance question.  Transferring unencrypted data from your IBM i to a Windows platform and then encrypting it and moving it from there will put you out of compliance for PCI DSS.  You should not transfer unprotected data to any system or across any network that’s not fully protected.  If you move it from the IBM i platform to Windows platform, it’s going to land in an unencrypted format and that will put you out of compliance.  That kind of unprotected transfer will also put you out of best practices alignment in terms of just pure security.  The security principle here that comes into play is always encrypt at the source, decrypt at the target or the destination, and don’t let the data be unprotected in-between.  Remember, data should never be moved “in the clear”.

Q: Can manage file transfer software be used on just one side, or do all sides of the transfer have to have the same software?

Patrick:  Partners/customers would certainly want a managed file transfer solution to be based on open standards.  You would not want to install proprietary software to process file transfers and then expect your partners to have to install it as well.  We base all of our secure transfer encryption components on open standards like a SSL FTP and Secure Shell sFTP and PGP encryption.  This means is that right out-of-the-box you will interoperate with all the major financial institutions and insurance agencies.  

Q: Does the Alliance FTP Manager solution run on the IBM i or Windows server?

Patrick:  Alliance FTP Manager is a fully native IBM i application.  It runs strictly on the IBM i platform and uses industry standard protocols. So there is no proprietary component on Alliance FTP Manager where you would have to distribute special software to someone who is receiving the files in order to process them.  We use industry standard pipeline encryption SSL FTP and Secure Shell sFTP.  No matter who you’re transferring data to, whether its Windows, Linux, UNIX ,or IBM Mainframe, there are multiple readily available solutions that support those secure file transfer protocols.  The commercial PGP that we provide is fully compatible with industry standards, it interoperates seamlessly, and we test it against multiple other PGP solutions as well as open PGP solutions.  Your customers and vendors (the people you’re transferring the data to) will appreciate that they do not need special software to process PGP encrypted files or your Alliance FTP Manager transfers.

Q: We occasionally need to create encrypted zip files to transfer files to our customers, can FTP manager do this?

Patrick:  We certainly do provide a command based zip file encryption and zip file decryption (compression and decompression) that implements 256-bit AES encryption.  It will process with wildcards and so if you have multiple files in an IFS directory you can compress all those into one zip archive.  Our directory scan automation component will automatically process data right into your application. So yes, there is an implementation of secure encrypted zip in FTP Manager.  

Q: A public/private key pair is needed for SSH and sFTP transfers. Does FTP Manager exchange keys with the destination server?

Patrick:  Secure Shell sFTP supports a number of authentication and privacy mechanisms, the most common is using a public and private key pair.  You do have to execute a key exchange with your training partner/bank before exchanging encrypted data. We have developed utilities and interactive options to help you load your trading partners public key on the IBM i platform.  For example, a menu option will allow you to put in the DNS name for that particular server, then it will find, retrieve, and install that key in your system.  Normally these steps are time and labor intensive, but we have automated the exchange to simplify that particular administrative setup function.
Very important: Typically sFTP transfers use public and private keys, just be sure that the solution you choose can also handle password authentication. Alliance FTP Manager CAN do that!

To learn more, view the complete webinar - Secure Managed File Transfer on the IBM I -which examines the security principles, compliance requirements, and technical challenges for secure FTP transfers on the IBM i platform with the following objectives:

• Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
• Protect data using strong PGP encryption
• Review your total encryption strategy

If you have further questions, please list them here in the comment section and we will be sure to get you an answer!

Core Components of a Total Encryption Strategy

One of the easiest things to do to improve your data security posture is make sure that all of the transfers moving in and out of your organization are encrypted. The core components of any secure managed file transfer solution are the ability to protect and secure transfers as they move off of your system or as transfers move into your system using strong encryption.

The two main transfer mechanisms are:

• SSL FTP, File Transfer Protocol that has been updated to support encrypted sessions

Implemented based on industry standards and integrated with the IBM i Digital Certificate Manager (DCM), new IBM i platforms have DCM installed by default. Our own solution, Alliance FTP Manager adds things like intelligent firewall negotiation and proxy server support which make those connections easier to deploy, as well as integrated logging to make sure that the sessions are properly logged for compliance regulations and compliance audits.

• Secure Shell sFTP, which is a Linux and UNIX facility also exists in the IBM i platform and secure FTP gives you the ability to implement encrypted transfers to and from your IBM i platform

Secure Shell sFTP, based on how it encrypts, establishes, and maintains sessions is easier to manage from a firewall point of view than SSL FTP. We fully support password-based Secure Shell sFTP in batch mode and are the only vendor who fully implements that according to the standard.

Pretty Good Privacy (PGP) file encryption is the third critical component of a total encryption strategy.  PGP encryption protects data at rest, so when you move data securely across the internal network or across the Internet, you need to be sure that it's properly encrypted at it’s destination.  SSL FTP and sFTP encrypted sessions are great at protecting data when in transit however, when that data lands on an FTP server, it may not be inside a firewall and could be exposed. PGP is the most commonly used and widely deployed encryption in retail, banking, medical, insurance, and other industries to protect data and a fundamental part of a managed file transfer solution.

The commercial version of PGP, created by the original developers and now supported by Symantec, is fully implemented in our Alliance FTP Manager solution. Commercial PGP also offers features important to enterprise clients:

• Additional decryption keys support (ADK) - allows you to encrypt a file and send it to multiple people without using the same key. You can actually encrypt the file and add your own decryption key which would allow you to recover that data as part of a discovery process to prove what data was actually sent to a recipient.
• PGP implements key server support in addition to local PGP encrypted key stores on the IBM i platform and for z/OS Mainframe.
• Support for Self-Decrypting Archives (SDA) for multiple platforms.
• Commercial PGP product has been through multiple rounds of FIPS 140-2 certification over the years. Both the source code and the application has been fully vetted by independent security professionals multiple times and that code has been open for public review.

Beyond those three core components, you also need some other things to confirm that the encryption being used is defensible and has been reviewed by security professionals:

• Good audit trails
• Real time system logging integrated with the IBM security audit journal (QAUDJRN)
• Certifications through NIST and  FIPS 140-2

For an indepth look at a total encryption strategy, security expert Patrick Townsend presents a 30-minute webinar discussing how compliance regulations such as PCI, HIPAA, Sarbanes-Oxley, and new state/federal laws affect your company.  He also covers real-life examples of how others are meeting these challenges with Alliance FTP Manager and the new PGP solutions.

After our latest webinar “Encryption & Key Management with Microsoft SQL Server” there were a number of great questions asked by attendees and answered by security expert Patrick Townsend.

Here is an informative recap of that Q&A session:

Q: Are there any special considerations when deploying an encryption key manager in the cloud?

A: The cloud always presents some additional security challenges related to encryption and security in general and has the impression of being less secure and having some new challenges around security. In the cloud, the encryption key manager itself is only one component to consider, and you need a good FIPS 140-2 compliant solution like our Alliance Key Manager for SQL Server. You also need client side applications and libraries, so when you're thinking about moving to the cloud, paying attention to that particular issue is very important. Also know that not all libraries can easily migrate to cloud. We develop ours from the ground up with the cloud in mind, so all of our components that talk back to our key manager for encryption keys or encryption services are cloud-enabled and can be deployed there.

From a compliance point of view, it is very important to take a look at the Cloud Security Alliance (CSA.org) document on cloud security - version 3.

We also provide a compliance brief about domain 11 which talks about encryption key management and issues around the security in the cloud.  

Q: Can you go a little more in-depth about what gets installed on SQL Server?

A: For the SQL Server platform (the client side software) Microsoft allows for Extensible Key Management (EKM) which allows vendors like Townsend Security to plug into their environment. Our Key Connection for SQL Server is an EKM provider and it is a GUI (Graphical User Interface)  install, so you load it on your own SQL Server platform and it walks you through some questions:

• It will ask what SQL Server instances you want to protect
• It will ask for your authentication credentials in order to execute the necessary commands  
• It will allow you to install certificates into the Windows certificate store that are used to communicate with the key manager HSM
• It allows you to define the location of your production and multiple high-availability failover key servers (most companies deploy one production and one HA key server. However, you can actually identify a more complex environment if needed)  
• Then it allows you to actually test, right there in the install dialog, your connection to your key manager to confirm it is working the way it is supposed to

Side Note: We do not charge based on the number of endpoints that talk to our Alliance Key Manager. This is something that is unique to us as a vendor. We believe the encryption should be easy to do and affordable, so no additional license fees are required to actually use it. We want our customers to deploy encryption and use it to protect data.

Q: What are the minimum requirements for the key server?  

A: The Alliance Key Manager product is available as either a hardware security module (HSM) device or virtual appliance. As an HSM it has a 1U server footprint, so it looks like any normal 1U server in your data center. However if you use our Alliance Key Manager Cloud HSM implementation, the encryption key manager is installed for you in a secure data center. It is also our philosophy that these are customer install processes, so we don't have consulting fees because it is a user deployed device. The server administration is done through a secure web browser session with our Townsend Security technical experts. The encryption key management security functions are done through a specific Windows application that talks to one or more key servers to actually create and deploy encryption keys whether they’re for Oracle or SQL Server EKM.  

Also, we do provide our encryption key manager as a VMware virtual appliance, which allows you to deploy a key manager within your VMware infrastructure and we give you guidance on that process. With this option you don't have to purchase a hardware appliance, you can run it in your VM infrastructure or within a vCloud architecture. We strongly recommend that a review of the PCI Security Council's - Cloud Computing Guidelines as well as their guidance around virtualization when deploying a virtual encryption key manager.

Q:  Does your key manager handle encryption and decryption or just key management?

A: Our encryption key management appliance itself does support on-board encryption and decryption.

Q: Can the same EKM module be used to encrypt servers in both data centers and cloud environments?

A: Yes. You can mix and match these anyway you want. You can use the same encryption key management solution for applications running in either environment, and they can talk to each other. You should be aware of a good security practice guidance around using different encryption keys for different kinds of applications, or different user communities, even in a high-availability data center or disaster recovery centers.  

Q: What are the performance impacts on encryption?

A: Encryption always has performance impacts. Generally it can impose a penalty somewhere between 2% and 4% in terms of computing resources. Guidance from Microsoft regarding very large SQL Server databases show that performance can become an issue with certain operations. For example, encrypted indexes may require the entire index to be decrypted in order to be processed. Very large SQL Server databases can impose a bigger performance penalty than 4%. Sometimes, cell level encryption has been a better performing implementation than transparent data encryption. We support both TDE and cell level encryption, allowing our customers to use our product as needed.

We strongly recommend to our customers, especially those with larger more complex SQL Server applications, that they contact us and ask for a complimentary evaluation of our encryption key manager. The complimentary product trial is fully functional and allows an opportunity to do analysis of the performance impacts. We want you to give it a try and make sure you understand the impacts personally.

Q: Is there any limit to the number of servers that you can hook up to the key manager?

A: No. There's no license limit. If you're considering putting up multiple servers we recommend you engage our pre-sales support team and get some guidance on your project. You will never come to us for additional licensing fees around adding a new platform, new SQL Server, or any other application that talks to the encryption key management server. We are unique in the industry that way and is part of our philosophy; we believe encryption needs to go everywhere, data needs protection wherever it lives, and we should lower the barriers -not raise them- when it comes to getting data protection in place. You can connect as many client-side applications to the key server as you wish.

Q: How do you keep system administrators from getting at the data and the keys at the same time.

A: Tasks such as the management of the server, putting it on the network, establishing system logging options, setting the timeservers - all network administration processes - are segmented from the actual management of the encryption keys. Good security practice says that those should be different people engaging in those activities. We provide completely different interfaces to simplify separation of duties.

If you are using our Cloud HSM environment, it is not administered, managed, or accessed by the cloud provider nor by Townsend Security. You have exclusive access and control over your encryption key managers. We even provide a path if you wish to take the encryption key manager out of the cloud environment and install it in your own data center. We believe strongly that a security device should be exclusively under your control, not under the control or management of the cloud provider.

I encourage you to download the recording of the entire webinar and Q&A session:

What to look for in a Cloud HSM solution

With the latest advances in encryption technology, organizations are now able to protect sensitive data with encryption key management in the cloud. The lower costs for maintenance and software (on the operational side) makes the cloud an attractive place for companies to move their data centers and for technology companies to deploy their applications. However, these multi-tenant cloud environments provide some real challenges in terms of protecting data from exposure and meeting special requirements in terms of security. In traditional IT data center environments you would normally place a hardware security module (HSM) key management device directly into your rack. However, traditional encryption key management systems don’t function well in cloud environments, and often companies moving to the cloud don’t have a traditional IT infrastructure. This creates new issues and challenges for administrators to provide the level of security for encryption keys needed to protect data and meet compliance regulations. When considering the move of your data to the cloud, think about whether or not you will have:

Access:

When it comes to encryption key management, only you should have access to encryption keys that protect your data. When you consider a Cloud HSM, be sure to ask if the cloud provider will have access to the HSM and your keys. The answer may surprise you! Because the encryption keys are the “secret” that protects your sensitive information, no one else should have access to your data encryption keys or to the systems that protect those keys. This is the same rule that applies in a traditional IT infrastructure and needs to be followed when you deploy data protection in a cloud environment. Not only is it a compliance requirement to protect encryption keys, but using a secure HSM is a security best practice.

Control:

HSMs are a vital part of any data protection strategy. Encryption key managers that serve for protecting data in the cloud need to be fully under your control. To make sure that you have proper controls, your key management solution should be:

• Segmented from your cloud data
• Independent of your cloud vendor
• Able to meet the highest level of security requirements
• Designed to follow encryption key management system best practices

Mobility:

With an encryption key management and HSM solution that's protecting data in the cloud it matters where your key managers are located. If you're deploying a solution that is proprietary to your cloud vendor, your keys are locked into that cloud vendor and if you move your data, you can’t access or move your encryption keys. You also want to make sure your cloud vendor has no administrative access to that key manager. Fundamental things to think about when you deploy a key management solution:

• Are you a locked into that cloud platform?
• Do you have full and exclusive control of your keys?

Compliance regulations are very explicit about protecting sensitive data with proper encryption key management, and recommend good key management practices as a core principle. When you move to the cloud, you don’t automatically have that level of security for your data.  To meet PCI-DSS requirements for protecting credit card information you should really look at the PCI-Data Security Council - Cloud Computing Guidelines as well as their guidance around virtualization since cloud environments are virtualized environments.

Excerpt from PCI-DSS Cloud Computing Guidelines - Executive Summary:

“Cloud computing is a form of distributed computing that is yet to be standardized. There are a number of factors to be considered when migrating to cloud services, and organizations need to clearly understand their needs before they can determine if and how they will be met by a particular solution or provider. As cloud computing is still an evolving technology, evaluations of risks and benefits may change as the technology becomes more established and its implications become better understood.
...
It’s important to note that all cloud services are not created equal. Clear policies and procedures should be agreed between client and cloud provider for all security requirements, and responsibilities for operation, management and reporting should be clearly defined and understood for each requirement.”

It is also important to look at the Cloud Security Alliance recommendations for cloud security - version 3. Whether you are a cloud vendor or a cloud user, the CSA provides very practical and straightforward guidance on security in the cloud environment. In order to properly secure and protect vital information, you need to understand the security posture of your cloud provider. Don't be satisfied with general statements about security, look for external audits and regular expressions of compliance reviews so you know for sure that you're truly covered. Be sure your encryption keys are in geographically dispersed data centers under an ITIL-based control environment independently validated for compliance against PCI DSS and SOC frameworks to properly manage risk.

Please download our latest Podcast “Encryption Key Management in the Cloud” which covers these topics in greater depth and also talks about how organizations deal with High Accessibility (HA) and Disaster Recovery when their HSM is in the cloud. The podcast will also cover our new Alliance Key Manager Cloud HSM solution that lets you protect data in Amazon Web Services, in Microsoft Azure, Rack-Space, or any cloud environment where you deploy data.

Have questions or concerns about data security in the cloud?  Please leave a comment here and we will get right back to you!

Make sure you don't turn a blind eye to data security!

The basic concept of converting sensitive data into a form that could not be easily understood if it was to be seen by the wrong audience goes back as far as 500 BC (Atbash Cipher), some would even argue that in 1900 BC a simple hieroglyphic substitution was the first form of cryptography. While technology has made great advancements in recent years, it has also created an even greater need for privacy of sensitive information. Whether you are the Chief Security Officer, IT personnel, or database administrator; you should know how your company is handling sensitive data. In fact, security is the responsibility of every business owner and employee. Not using secure passwords can lead to a data breach just as not following key management best practices can provide access to people with malicious intent. When awareness around data security reaches every department and individual, then the company can not only meet compliance regulations, but can benefit from effective data security. Compliance regulations require (or strongly recommend) all industries following best practices for encryption and key management . Do you know which of these apply to you and your company? For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:

• HIPAA/HITECH ACT requires security of Protected Health Information (PHI) in the medical sector.
• GLBA/FFIEC sets regulations for banks, credit unions, credit reporting agencies, and anyone in the financial industry.
• FISMA is for Federal US Government Agencies.
• The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.
• More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).

So, beyond compliance with regulations, why should you care about encryption… First of all, your customers, clients, and suppliers all expect you to protect their sensitive data. Effective encryption and key management can provide your company with a number of other benefits as well. Here are just a few basic benefits of effective encryption key management:

• Peace of Mind - While hackers and identity thieves are getting smarter and regulations are getting more complex, data protection technology is also improving at a rapid rate. Encryption and key management options are now available in virtual machines and cloud environments as well as hardware security modules(HSMs). How well would you sleep at night if you kept your house key under your welcome mat?
• Reputation - Whether information is lost due to a hacker or a hurricane, if a company loses all of it’s important data, the whole business could be ruined. However if sensitive data is lost because mechanisms for protecting it are not in place, then an organization has even bigger problems. The most effective way to secure data and ensure the integrity of a company is to deploy encryption and properly manage the encryption keys.
• Credibility - Beyond audit requirements, organizations need to consider the security of their customers Personally Identifiable Information (PII). Being able to protect your clients with strong key management practices can add a level of trust and confidence that will help grow your business.

Mobility is also great benefit! As more people move their data to the cloud or virtualized environments the need for encryption increases, and the importance of key management becomes even more evident. In order to maintain control over your data, and the privacy of your customers, information must not only be encrypted but kept secure while in motion, in use, or at rest. By properly managing your encryption keys, you are still in control of your data no matter who is sharing your infrastructure.

In this complimentary eBook, "Turning a Blind Eye to Data Security”, authors Kevin Beaver, CISSP; Patrick Townsend, and Todd Ostrander will teach you about:

• Tools and resources to begin the discussion about data security in your company
• 5 Common misconceptions about data security
• 6 Questions to ask your CIO

Data protection is only as secure as you make it!

As more companies begin to move data to the cloud, protection of encryption keys become an even more important part of an overall data protection strategy. Three core information security components, becoming better known as the “CIA Triad”, are important elements in a solid data security policy. These core components in the triad are:

Confidentiality:

• Confidentiality has to do with encrypting data in applications and databases, protecting it from people who should not be seeing that data or accessing it, whether that's in your IT data center or in a cloud environment or in virtualized applications.

Integrity:

• You have integrity of the encryption key management process itself with connections to the key management HSM to authenticate and retrieve keys or perform on-device encryption operations. Integrity is accomplished through public ­key infrastructure (PKI) mechanisms.

Availability:

• Availability is a crucial component especially with encryption key management systems which are mission ­critical applications. You need redundancy both at the hardware and software level with proper application mirroring and database mirroring in place. You should ensure back­ups take place at an appropriate interval and that recovery operations are also tested on a regular basis.

These components are achieved with a solid key management solution and the proper managing of the actual encryption keys.  The Key Management administrator is responsible for performing a number of functions that must be done, and done properly to meet compliance regulations. The administrator must also follow industry best practices in order to accomplish true encryption key management for their organization and the data they need to protect.  

The Encryption Key Life Cycle

One of the first functions the Key Management administrator performs is the actual creation and management of the encryption keys through a key lifecycle. The keys are generated and stored in a secure fashion and then go through the full cycle depicted here to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase).  This lifecycle is defined by the National Institute of Standards and Technology (NIST) and also requires that a crypto period be defined for each key.  A crypto period is the length of time that a key should be used and is determined by a number of factors based on how much data is being protected and how sensitive that data is. While NIST has defined and provided some parameters on how to establish crypto periods (see special publications 800-57 - there are 3 parts) and provided guidance on best practices. Each Key Management administrator needs to determine how long a particular encryption key should be actively used before it is rotated or retired.  

Auditing and Access Controls

Auditing and active monitoring of critical key management systems is a fundamental security concept for protecting critical assets like data in a key management solution.  The Key Management administrator also needs to implement access controls to be sure that only the users and applications who should be accessing encryption keys are actually doing so.  A general practice of separating encrypting keys across different departments or applications should be in place. For example, you may need to protect employee data in your HR system using an encryption key, but you wouldn’t want to use that same encryption key to protect sales data or where you might have credit cards. You need to segment the usage of encryption keys to particular data so that employees in HR are accessing HR data using one key and salespeople can access sales data using a different key.

For more information, security expert Patrick Townsend goes into greater depth in his latest podcast: Guidelines for Effective Encryption Key Management.  He covers how implementing procedural mechanisms like dual control and separation of duties will help ensure your organization is implementing best security practices. Patrick also outlines fundamental components of a strong defense-in-depth approach to data security and how encryption and key management can protect your enterprise. I encourage you to download the 20 minute podcast!

As we discovered in the blog Signs Your IBM i May Have Been Hacked, the combination of secure system logging on the IBM i and log monitoring with a SIEM will help you secure sensitive data and minimize the impact of security breaches.  Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by industry experts from Townsend Security and Integrity.  Here is a recap of that Q&A session:

Q: Do compliance regulations require system logging?

A: Most regulatory compliance standards such as PCI-DSS, FISMA, GLBA, and HIPAA/HITECH require organizations to monitor their network in real-time and provide audit reports. For the Payment Card Industry Data Security Standard (PCI-DSS), there are numerous logging requirements to be PCI compliant. Auditors want to look at how the logs are generated, whether it’s systematic or whether an operator can access/edit them, go in and pull them off and move them somewhere else. They want to look at if there’s mirrored events, where they go off the system through an automated process without any potential human intervention. It also details if people have the right privileges. Logs will show user events as well as what individuals are accessing libraries, files, or other areas outside of their designations. Logging is not only an industry best practice, it is a critical control to understanding access to a system.

Q: We have some custom applications that run our core business. Can a SIEM solution analyze the log files that come from these applications?

A: Dave Nelson from Integrity answers “Some SIEM applications are able to analyze log files from custom applications, others are not. Integrity’s SIEM can create a custom parser that can take just about any log that you can provide. Integrity can analyze that, we’ll work with your internal application development staff to identify what different error codes or security event log codes or whatever it is that you’re creating to identify a specific event. We can map that then into the parser then we can map those to either standard alerts or we can create new custom alerts, we can customize thresholds and a lot of different things. That’s one of the reasons that our customers choose us most frequently is because they have those internal applications that are custom that a lot of the other SIEM tools can’t handle, but we can handle and we can give them a lot of information about something that’s very unique to their business.”

Q: You mentioned File Integrity Monitoring (FIM), can you further explain how an organization would use it?

A:  It’s not every field that you’re going to want to alert and log and monitor on, but there might be ones with credit card numbers or store order authorization codes that you want to monitor and make sure the data hasn’t been altered or accessed without consent. The point to stress with logging and file integrity monitoring is ultimately it helps the individual system operator. You can have mirror alerts go to multiple people in the company, security officers as well as system operators. With FIM you take responsibility off of any one person having to follow up and do it all and you can create more of a collective team that analyzes this data to help the business.

Q: How can we distinguish a false alarm from a successful attack?

A: Sometimes it can be very difficult to determine a false alarm from a successful attack until you have done an entire investigation.  People that do this day in and day out and can begin to identify the patterns and trends of what makes an attack successful or not.  In our experience, the easiest way to do it is to look for key data points or key events that should have happened. One of the things you can do is jump right to the end if you know that a specific attack is successful, and work your way back through the system to determine the file name and creation date.  This really only comes with experience and practice of identifying the missing pieces.

Please post any additional questions you may have here on the blog!

For a much deeper and more detailed discussion on secure system logging and monitoring as essential controls to detect and mitigate the risk of a data breach, please request a download of the entire webinar:

Just because data is encrypted, doesn’t necessarily mean it is safe...

(Based on a recent webinar with Townsend Security and Dave Nelson, President of Integrity)

Your IBM i may have been hacked and you don’t even know it yet!

Industry experts from Townsend Security and Integrity discuss how the combination of secure system logging on the IBM i and log monitoring with a SIEM will help you secure sensitive data and minimize the impact of security breaches. Topics cover (and go beyond) how log files and log data are the digital evidence (artifacts) that actually take us to a point of action within a system. They look at what the false alarms are within the plethora of data and how to screen those out. Then they also talk about the next steps: What are the red flags to watch for, and what to do with those red flags.

“As we look at the millions of data points that are created each day, every login or logout, every time a user is created, every time a user accesses a resource or adds a new resource or saves a file…. amidst all that data, hacking events happen. What we have to try and do is understand the ways that we can sift through that data and reduce the background noise and address the successful attacks.” (Dave Nelson)

Things to look for in log files as we’re trying to identify what’s real data, false alarms, or red flags:

New users and user accounts - Look for things like random names (like BSX or BS4XOR) and be able to identify new users. Always be able to trace these new user accounts back to a user account request and be able to identify which of those accounts have an approved resource and which ones have not.

New files and directories - Identify new directories, look for batches of files that show up between things that are normally next to each other. One of the things hackers love to do is hide files on any sort of Windows mountable or UNIX mountable directories within your i Series because a lot of times the IBM i doesn’t have an antivirus check or an antivirus application on it.

Date and time stamps - There are some (system) files that you know shouldn’t change. If you start to notice that those file modification dates or the save dates on those files and libraries have changed, that should start to be a red flag.

Significant increase or decrease in the size of a file or a library - Hackers will inject data into the back end of an existing file so that the file itself doesn’t change and it can still be executed. So watch for files that used to be a few kilobytes and are now a few megabytes or even gigabytes.

New processes or services that are running - Anytime you have a batch job that’s running and you’re not familiar with it, that should be something that you look at right away. Look for unusual interactive jobs working between LPAR’s or between systems. Do you normally have data leaving your IBM i and going to another platform? or a direct connection from a Windows server directly into your IBM i?

Cryptic or unusual file names - Create some sort of naming convention within your organization so that you know if something is outside of that standard.

It is suggested that we think of log files as the forensic evidence for the IBM i system and think about monitoring almost as a crime scene investigation. The relationship between the logging agent and the collector of those logs is very important because unexplained system value configuration changes, application changes, changes to privileges and privileged user profiles are indicators of potential malicious activity that you can record. These logging tools are strengths for an organization to really get to know what the system is doing as part of daily business activity, and then how to alert and monitor for data protection.

With all the different types of data that you can look for, the sheer volume of information that’s out there, there’s absolutely no way that an individual system administrator and application developer, even a full time security professional is going to be able to sift through that amount of information. Partnerships between the SIEM (Security Information and Event Management) collector and the logging agent are now industry standard defense and depth controls. Automation and email notifications about potential malicious activity can immediately give you the chain of custody to provide the digital evidence you require to go investigate further. You want to be able to drill down to specific threats, events, and user specific events as part of any good governance risk & compliance program and risk management approach. Essential for a total enterprise solution is the partnership (and strong encryption) between LogAgent and a SIEM.  

As a SIEM solution that partners with Townsend Security’s logging solution*, what Integrity’s done differently is provide a managed SIEM service. Dave tells us “We’ve got clients running this on the i Series platform using Alliance LogAgent to monitor, interfacing with our SIEM, and  they have said ‘Wow, we didn’t have any idea that we could get this much information and that it could be this easy to access and that we can share it’.  Clients want to be able to share that with their network administrators and say ‘See, this is what we’re seeing, we’re seeing this traffic and we don’t know why it’s coming in, can you please stop it and block it’.  One of the best things about Integrity’s SIEM solution from a cost perspective is that there’s no capital investment. You don’t have to spend $100,000 for the software, $50,000 for hardware and then go out and hire a full time person to review these logs and to set up the system and manage another system and application within the environment. It’s all provided for you for a low monthly cost. You get this in a matter of days and weeks instead of a matter of months. So you’re getting immediate return on your investment. In these economic times we all know how important that is to be able to show ‘Hey, we’re getting some real value for this expenditure that we’re making, we’re seeing a lot of things happening’. One of the other benefits is that you’re not going to see just security information from this. The amount of information that you’re going to get, you’re going to see operational things that you hadn’t seen in the past. You’re going to see things that you look at and say ‘Wow, we had no idea the system was operating that way, or those processes were running, or those jobs were running or taking so long to run’. The feedback that we get from our clients is that the value they get from the operational side of the SIEM is almost, if not as much, as what they get from the security side of the SIEM. So just being able to see deeper into the environment and seeing what’s happening, what’s going on has been great for a lot of our clients as well.”

*Townsend Security’s Alliance LogAgent is a comprehensive platform specific solution for IBM i which helps cut through the noise and deliver granular valuable data, providing file integrity monitoring right down to field level changes. Key steps you want and need for compliance purposes as well as data security.  

For a much deeper and more detailed discussion on secure system logging and monitoring as essential controls to detect and mitigate the risk of a data breach, please request a download of the entire webinar:

If these technologies are not in place, do you really know you haven't been hacked?