Townsend Security Data Privacy Blog

Last week, Townsend Security CEO Patrick Townsend and I made the trip to Anaheim, CA for the IBM COMMON User Group Annual Meeting and Exposition, a meeting that brought about one thousand IBM users from around the world together to learn and network. Both Patrick and I gave classes on IBM i security. This was a great opportunity for us to learn what the top security concerns of IBM i users are today, and what strategies are most common for implementing defense-in-depth security on the IBM i.

First, it was great to learn that most IBM i users with sensitive data are encrypting. FIELDPROC, the field procedure exit point available on V7R1/V7R2 has made column-level encryption easier than ever, and many users are moving towards FIELDPROC-based encryption solutions. There was also greater interest in encryption key management, which is a critical part of any encryption solution.

One of the top questions we received regarding encryption and key management was, what are the benefits and challenges of IBM i native encryption libraries and key management? The IBM i native encryption and key management capabilities can be an easy way of protecting sensitive data on your IBM i. However, some companies who must encrypt and decrypt large amounts of data in short periods of time, or who must meet compliance regulations such as PCI-DSS or FFIEC, often run into performance issues when using the native encryption libraries and compliance issues if they must use a NIST-compliant key management solution. If a user needs to manage encryption keys in a multi-platform environment, then using a third-party key management solution that can manage keys in multiple operating systems and platforms is critical.

Greater interest in system logging was also evident. A strong system logging solution will collect security events in real time and detect a data breach as it happens. Many IBM i users were already using a log collection solution such as Splunk, AlienVault, or IBM’s QRadar SIEM solution; however, many users were also facing the challenge of collecting security events that are generated in many different formats, and need to be converted to a common format for collection, analysis, and alert management. The ability to convert these events and manage them in a cohesive way falls entirely on the capabilities of your system logging solution. We recommend IBM users focus on solutions, such as our Alliance LogAgent, that can convert logs from multiple formats into standards formats that can be read by your SIEM solution.

Lastly, Patrick presented on the importance of two-factor authentication on the IBM i. The importance of two-factor authentication has become more evident since many security experts deduced that some of the largest data breaches in the past few years perhaps could have been prevented using two-factor authentication. The Target and Anthem breaches are listed among these. Two-factor authentication is defined as an authentication method using two factors: something you have and something you know. If using two-factor authentication on the IBM i, anytime a user signs on, they will also receive a text or phone call providing them with a pin number they must enter in to their sign on client as well. Since hackers are becoming more and more adept at discovering a person’s password, two-factor authentication would stop a hacker from signing on as that person if they didn’t have access to their phone as well. Large companies such as Google and Apple are using these technologies already, and it won’t be long before use of two-factor authentication is a standard across all platforms.

Every year, COMMON gives us an opportunity to connect with IBM i users and some of our customers as well. We use this opportunity to spread the knowledge we have about the best security solutions available for the IBM i and learn from the community what new security needs coming down the line. If you weren’t able to attend COMMON this year, check out Patrick Townsend presentation on on two-factor authentication, available online here.

Real-time, Low-cost, Business Integration When and Where You Need It! 

Do you need a complete and affordable solution for implementing XML web services on your IBM i? Need a solution that won’t disrupt your existing applications and database so you can easily implement web services without complicated API programming or the deployment of external servers? Our Alliance XML solution includes all of the communications, XML parsing, data translation, and application integration components that you need. You can create XML documents from your existing database files and securely send them to remote web servers, and you can receive XML documents directly on your IBM i and process the data into your applications. 

QSA auditors and other security professionals focus on the protection of sensitive data after it traverses the Internet and then lands in a database on a hard disk drive. You need a solution that provides security at every level of processing and protects data in transit using session encryption. When sending or receiving XML documents Alliance XML can use the Transport Layer Security (TLS) protocol for strong encryption of the transferred data. The Alliance XML TLS support is based on the IBM Digital Certificate Manager and related IBM APIs for TLS sessions. This gives you an implementation that is compatible with native IBM i security. As an additional layer of security the Alliance XML HTTP servers provide IP address controls so that only known clients can use the servers.

When receiving XML documents with sensitive data you can enable field level encryption to protect the data. For example, if you receive a document with a credit card number or social security number, you can use strong encryption of the data to protect it before it is written to your database table. User APIs provide a means of decrypting the data so that it can be used in your RPG and Cobol applications.

The web protocols HTTPS and FTPS provide for the ability to encrypt the data in transit, and Secure Shell SSH also provides strong encryption. But after the data reaches the end point of its journey it lands in a database somewhere, and it is often exposed to loss at that point. I believe that’s why security auditors put emphasis on making sure that data is encrypted when it hits it’s destination.

Many companies have implemented web services in combination with the XML data standard to take advantage of low cost, real time integration with their customers and vendors. When you combine the ubiquity of the web HTTPS protocol with the W3C XML standard you get a powerful incentive to use this platform for business integration.

Care should be given to what happens to data when it leaves the realm of encrypted transit and lands on server hard drives. The right thing to do is encrypt sensitive data at the very beginning. This means that the tools you are using have to support encryption as a natural part of the process of converting XML data. Standard XML processing tools such as Xerces and Xpath do not have built-in encryption. The same is true for XML toolkits and APIs provided by IBM, Microsoft, and others. This leaves it to developers to try to intercept data after it is transformed from XML and before it lands in a database table or on a hard drive. That’s a real challenge.
 

In our Alliance XML/400 web services product on the IBM platform we built encryption right into the data transformation process. Alliance XML/400 customers can protect sensitive data by enabling the encryption option on a translation map. The solution does the rest. The data is encrypted before insertion into the database and there is no exposure as the data lands in the database on the hard drive. Our customers are taking advantage of this feature to meet PCI and other compliance regulations.

Encryption can help protect against another common threat, too. At the annual PCI SSC standards council meeting a few years ago, forensics expert Chris Novak of Verizon talked about how more than 75 percent of data loss events begin with a well known weakness that hasn’t been patched, and half of these are based on SQL injection attacks, this is still true today. With SQL injection, the attack on your servers starts with bad data inserted into a database in the clear, leaving open a later exploit. There are ways to prevent SQL injection through programming techniques, but encryption will also help defeat them.

Will encrypting your data provide all of the security protection you need? No, but it should be a major part of your defense-in-depth strategy to protect sensitive data.  

To view a replay of a webinar we presented on XML & Web Services, click below

 

Taking Security Beyond Usernames and Passwords

Security professionals understand that passwords alone are just not good enough protection, and the on-going flood of data breach reports just confirms this on a daily basis. Enterprise IBM i users aren’t going to stop using passwords to login to their IBM i platforms, and hackers aren’t going to slow the flood of attacks any time soon. But now, we can take a giant security step forward by implementing two-factor authentication (2FA) to dramatically reduce the risk of a security breach.

Compromised email, social media, online gaming, ecommerce, financial services and other types of cracked accounts continue to threaten both personal and corporate interests. Out of all the threats that face individuals and companies, account compromise stands out as one of the most easily addressed with available and mature security technologies.

Historically, companies used physical tokens to provide authentication on the IBM i beyond username and password. Even if someone hacked a user’s password, they still could not login without the physical token. Tokens represent another layer of protection, which is a step in the right direction. Unfortunately, tokens increasingly do not make fiscal sense for Enterprise IT departments who have to deploy, manage, and troubleshoot large numbers of tokens. There is a better way for organizations to quickly and cost-effectively roll out two-factor authentication to a large and sometimes global user base. Solutions that leverage the mobile phone as a reliable means of authentication have become readily available for the IBM i platform. For example, instead of tokens, businesses can simply send an SMS or voice message that contains a one-time authentication code to the individual user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone.

Mobile phones and landlines present key advantages for verification and authentication regimes:

• They possess unique identifiers – phone numbers, electronic identifiers and account numbers
• They remain in the possession of users or near at hand most of the time
• They are difficult to spoof
• If stolen or otherwise misappropriated, they are easy to disable
• Their association with actual individuals is verifiable through the operators that provide phone service

While none of these attributes alone are sufficient, together they provide a compelling basis for verification and authentication. The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat than a login password. Combining something the person knows with something they have, or something they are, which can then be used for two factor authentication.

1. Something you know - a password. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

2.  Something you have - a mobile phone. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication.

3. Something you are – biometric authentication options.  Physically scanning for an iris pattern or fingerprint.

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

• Requiring two passwords: using one factor twice is not 2FA!
• Using shield questions of which are actually fairly easy in our social world to determine.

The IBM i platform has a well-earned reputation for security, but security is only as strong as the weakest point in the enterprise network. User PCs, internal and external web servers, and network applications represent points of attack. These systems are not safe from:

• Memory scraping
• Keyboard logging
• Stolen vendor credentials
• Stolen user passwords from external web services

Due to the nature and the extent of these security threats on the IBM i, two factor authentication has become a viable solution for meeting compliance regulations and safeguarding the vast amount of data and numbers of users with access to sensitive information on the IBM i. We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts and IBM i users now have an affordable solution for their platform. Find out more by downloading this white paper:

Security can be hard, expensive, complicated, aggravating, confusing, and did I mention expensive?

As a security company, we hear this perception from new customers all the time. But there is one thing you can do for your IBM i that breaks all of these stereotypes. You can get an immediate boost in system security without much expense and without a big headache. And your users are already using this security technique on their favorite web sites.

Increase Security with Two Factor Authentication (2FA)

Almost every day a phishing email gets through our spam filters and lands in my inbox. Some of these emails are very nicely crafted and look like the real thing. The graphics are professional, the English is excellent and matches my expectations. The terminology is appropriate. Really nice work. And the links in the email are pure poison. Just waiting for that unsuspecting click to start installing malware on my PC to capture my IBM i user profile and password information.

Yup, that’s how it started at Target.

The great thing about Two Factor Authentication is that it gives businesses a lot of additional security for very little upfront cost. The aggravation factor has almost gone away. You no longer need large, expensive servers and tokens that always seem to get lost at just the wrong time. Your IBM i can do exactly what Google, Yahoo, Facebook, your bank, and many other Internet companies are doing to make security better. And your users already have the device they need - their mobile phone!

Alliance Two Factor Authentication uses the same network services and infrastructure that the big boys use for 2FA. This security solution leverages the Telesign global network to deliver PIN codes right to your mobile phone. No servers to rack up and maintain. No lost tokens.

I know, you have some reservations:

I don’t always have signal to my cell phone.

That’s OK, just send the PIN code to your voice phone. A nice lady will read you the code.

I’m in a hurry, I can’t wait for a PIN code.

PIN codes are often delivered in under a second. If you’ve got a mobile provider with a slow network, just have the PIN code delivered to your mobile phone as a voice call.

I left my cell phone home!

Right, just use one of your One Time Codes. No phone of any kind needed!

My IBM i is in Restricted State, it won’t work for me.

Alliance Two Factor Authentication does work in restricted state with a couple of steps.

I don’t want to have to enter a PIN code every time I log on, that’s just way too much work.

Don’t worry, your security administrator can configure Alliance Two Factor Authentication to only ask you once a day to authenticate, or at a user-defined interval. And if an attacker tries to access the IBM i from another device or IP address, they will have to authenticate. And that’s going to be hard to do when you have your mobile phone in your possession.

We’ve made Alliance Two Factor Authentication easy to evaluate and deploy on your IBM i. You can request a free 30-day evaluation from our web site and be up and running within an hour. You can start slowly with a few users, and then roll it out to everyone in your organization. They’ll get it right away.

You don’t have to be the next Target. Get cracking (so to speak).

Patrick

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For more information, request our 2FA Resource Kit!

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

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

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

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

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

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

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

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

Patrick

With V7R1 IBM introduced FIELDPROC (field procedure) exit points which Alliance AES400 for IBM i uses to encrypt database files at a field level. Since the cryptographic process is called by the database directly upon access, rather than by the application, this means that the process will work regardless of what type of application uses it. No application changes are needed, which is something our customers really like to hear.

These are five frequently asked questions we get around FIELDPROC encryption.

1. What type of fields are supported with FIELDPROC?

Surprisingly, virtually every field type is supported, whether it is character (even binary character), numeric (zoned, packed or binary) date, time, timestamp, Double Byte Character Set (DBCS), and hex. Some fields have certain restrictions, for example in order to implement fieldproc encryption on date, time, and timestamp fields you must specify a default value that is not ‘current date and time’.  You can define this in DDS or structured query language (SQL), and there is an option in the DB2/400 FIELDPROC encryption menu that will do this for you.

FIELDPROC will also handle blank fields by not encrypting them at all. This helps us achieve better results from certain SQL operations. FIELDPROC encryption however does not support fields with NULL values and they should be avoided or changed if necessary.

2. Will I need to make any changes to my applications?

As I mentioned above, it is not necessary to make application changes, but here is more detail as to why: In V7R1, AES/400 can create FIELDPROC exit points that tie to individual fields in a DB/2 file. When a file is opened for any operation, read, update, insert, or delete, the exit point calls one of our FIELDPROC applications, which calls our encryption or decryption APIs. It does this regardless of which application is accessing the file, thus creating application independent encryption.

A few things to consider are: when you backup your file you will need to also backup the FIELDPROC applications, and make sure you restore them at the same time as well. It is also important to remember that if the file is accessed through FTP it will be transferred in the clear.

3. Can I encrypt index fields?

In short, yes. However, encrypting index fields will affect the performance of your SQL operations, and the more indexes you encrypt, the more your performance will be affected. This happens primarily for the following reason: For faster performance DB/2 looks up records based on their encrypted values. This means that when you tell DB/2 you are looking for the record with social security number 111223333, and that field is encrypted, it will encrypt the search string and then retrieve the matching record for you. This is done as a performance enhancement especially when working with logical files on the IBM i. However for some SQL operations it decrypts all the records in order to read the index fields, so rather than encrypting single values to look up, it needs to decrypt a multitude of records.

4. What kind of performance can I expect?

In our test environment, which consists of a single processor IBM i platform, model 515, approximately 3500 CPW, V7R1 of the operating system with TR5 installed, we can process about 16,000 records per second. Systems with higher processing power should see better performance. This means that if we have a file with one million records and one field encrypted we can read the entire file in about 60 seconds. If they are 2 fields encrypted it will take us about 120 seconds because we are handling two million decryption calls.

5. Does using external key management affect performance?

In short, no. The time it takes AES/400 to retrieve a symmetric encryption key from our Alliance Key Manager server is approximately 0.0116 seconds. And this is through a secure TLS connection. There are network infrastructures in which this time may be slightly affected, firewalls, routers, switches, distance, however it should never create a noticeable difference in performance.

To learn more about automatic encryption on IBM i V7R1 using FIELDPROC, download the podcast "FIELDPROC Encryption on the IBM i" to hear IBM i security experts Patrick Botz and Patrick Townsend discuss encryption, key management, and meeting compliance regulations on the IBM i.

Education is what remains after one has forgotten what one has learned in school.

Albert Einstein

One important aspect of our work is supporting our customers and answering their questions. There is a lot to learn, and there are a lot of sources of information, and it can be difficult at times to decide what information to take in and what to let pass by.

Beyond answering their questions about broader topics such as security and compliance, we also end up discussing some very technical issues that they have questions about as well. It’s not usually until after someone begins working with our products that we step in to answer questions about the technical aspects, the nitty gritty, of how a product addresses their security and compliance needs. In this article I will cover in greater technical detail five frequently asked questions about working with PGP encryption, as well as some tips and tricks on how to get the most out of it.

1. I have encrypted a file for my trading partner, and I want to verify it, but when I try to decrypt it, why do I get an error?

If you are encrypting a file for a trading partner you are most likely using their public key. Because a public key can be given out to anybody, it becomes important to prevent just anyone from decrypting it. Thus the file can only be decrypted with your trading partner’s private key, which only they should have. Based on the principles of asymmetric encryption, it is impossible to encrypt and decrypt with the same key.

There is however a way to encrypt the file for both your trading partner and for yourself to decrypt. You can encrypt the file with multiple public keys, in this case your trading partner’s and yours. Our PGPENCRYPT command does this through the use of the ‘Additional user IDs’ parameter, in which you would define a public key for encryption to which you had a matching private key for. That way you would be able to decrypt it using your private key to verify the contents of the file.

2. How do I provide my trading partner with my key?

When you are exporting keys from the keyring there is one important question to ask, will the key be used for encryption or decryption? When you are exchanging files with a trading partner you have to remember that you will be encrypting with their public key and they will be encrypting with your public key. But decryption, again, can only happen with a private key.
So if you need to export a key for encryption it needs to be the public key, if it’s for decryption you should export the key pair.

Our PGPKEYEXP command can accomplish both for you. You would define the key to export with the ‘Export type’ parameter, where *PUBLIC exports the public key and *KEYPAIR exports both the public and private keys in one file. You can verify what was exported by viewing the file. Even though they keys themselves are unreadable the title is. An exported key pair would list the private key first.

It is important to note that under no circumstances should you provide your private key or the entire key pair to your trading partners or vendors. The option to export the key pair is built into the application to allow you to move individual key pairs between your company’s own servers.

3. My trading partner’s key has expired, can I update its expiration date using PGP commands?

There is a way to update the expiration date on a public key, but not one you received from a trading partner. The public key can be updated only if you have the matching private key and the private key’s password. Because your trading partner should not ever share neither their private key nor their password, you cannot update the expiration date on that public key.
You will need to attain the new public key from your trading partner. The good thing is that most trading partners have a system in place that should inform you ahead of time of the impending expiration of their public key and either provide the new key with that notice or provide instructions on how you can obtain it.

4. I have received a key from a trading partner and I have added it to the keyring but I can’t encrypt with it (or I am being asked if I want to trust the key every time I try to encrypt with it), how do I trust it?

When you first import a public key PGP will not ‘trust’ it, since information encrypted with it can’t normally be recovered (see Question 1 for options). When you try to encrypt with it, PGP will error out, although when you are encrypting interactively, it will prompt you. To trust the key you need to do the following 2 steps:

1. Sign the new key with your private key to validate the key using the PGPKEYSIGN command. Because you are using your private key to do this you will need its password as well.
2. Then you need to set its trust level using the PGPKEYCHG command. Once you have done this PGP will accept the key for encryption.

5. My trading partner wants me to sign the file. What does signing a file do?

Signing a file is a way that you can help your trading partner make sure the file they received really came from you. You can encrypt and sign a file or just sign it, on the latter the contents of the file remain visible but an encrypted string is added to the bottom containing your signature. A signature can only be created with a private key, so your trading partner can be pretty certain that the file could only have come from you. The signature is verified by PGP by using your public key to decrypt and read that encrypted string. The string is never stored in the clear but it is read and PGP returns a message that it has verified it. This does mean that anyone with your public key can verify your signature, but then again that is what you want. If a file is both encrypted and signed, the signature would be read by your public key and the contents decrypted by your trading partner’s private key. You can define the signing key in our PGPENCRYPT command with the ‘Signing user ID’ parameter and by providing the command with its password. You can also sign a clear text file or an already encrypted file with the PGPSIGN command.

For more information on encrypting data in transit with PGP, download the podcast, “PGP Encryption on the IBM i,” featuring data security expert Patrick Townsend.

Defend your data by adding another step to your security process!

With increased losses of sensitive data from websites, retailers, and covered entities in the medical segment, we are hearing about data breaches on an almost daily basis now.  Are we as concerned as we should be, or are we getting jaded to the inevitability of data loss? When it seems like everyone is getting hacked, what kind of things can we do to help prevent access to our sensitive data?

After the recent Target data breach (and a number of other ‘holiday’ breaches), more information is surfacing on how attacks happen through unsecured websites, phishing emails, memory scraping, and keyboard logging malware that can get installed on individual user PCs. Once the hackers have usernames and passwords they can work their way through a network to where the sensitive information is stored.

For those of you on the IBM i platform, it might interesting to note that the IBM i is not immune from attacks and data loss. IBM i has a well-earned reputation as a secure platform, yet we are seeing keyboard logging attacks get past that great security as users log-in to the IBM i from their PC. IBM i platforms are typically great reservoirs of sensitive information; credit card numbers, social security numbers, personally identifiable information of all types make the IBM i platform a clear target for attackers.

In addition to the basics: encrypting your data and properly managing your encryption keys, you can immediately improve your security posture in relation to log-in security, as well as application level security by using two factor authentication (2FA) to prevent unauthorized access.  

The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat. Combining something the person knows (password) with something they have, or something they are, which can then be used for two factor authentication.

• Something you know - a password

Security administrators can set system values for rules on passwords, require certain length passwords, characters and numbers, uppercase characters... but end-users are quite adept at creating passwords that can be easily remembered, yet meet the criteria of the strong password from the systems point of view. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

• Something you have - a mobile phone

Mobile phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:

• Companies don't have to buy expensive additional servers and hardware
• Users generally have a mobile phone already, and even if they replace their mobile phone, their phone number remains the same
• Reduced cost of administrative expenses

• Something you are - biometric authentication options (iris pattern or fingerprint)

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

• Requiring two passwords: using one factor twice is not 2FA!
• Using shield questions of which are actually fairly easy in our social world to determine (Just the other day I received a message on a social media site that said “Hey!  We might be related… what is your mother’s maiden name?”)

We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts.

Cell phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:

Earlier this year we introduced Alliance Two Factor Authentication for the IBM i, which fully implements 2FA using SMS text or a voice verification call to your mobile phone.  In case you don't have a mobile phone, or are in a location where you can't get cell service, we allow the user or system administrator to record up to five mobile and voice phone numbers per user. This gives you a lot of flexibility for putting in phone numbers for home, work, cell with either the text or voice option. In the rare chance you may be someplace without access to any type of phone, Alliance Two Factor Authentication provides up to 5 one-time codes for use when the phone services are not available. These are randomly generated numeric PIN codes a user has access to, that gives them the ability to authenticate even if they don't have a phone with them at the time.

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

For a more in depth technical discussion, please check out this great webinar on two factor authentication by security expert Patrick Townsend: