Townsend Security Data Privacy Blog

Today, data security is more important than ever. We live in world now where organizations of every size - from small companies to large global companies – need to make sure their sensitive data is safe. The bad guys are getting much better with more sophisticated attacks. Even mid-sized companies are now targets. So, with the most up-to-date security features included in IBM i 7.1 (V7R1), why would you still be using or consider using the V6R1 release?  I recently sat down with Patrick Townsend, Founder & CEO, to discuss the latest IBM i OS and the security reasons a company who is on an upgrade path from V5R4 should bypass V6R1 and install V7R1.

What do you have to say to the company who traditionally moves up just one release? For example the company that would just upgrade to V6R1 because they feel that it has all the kinks worked out.

Well, I understand that motivation and I have been in that seat before. OS upgrades are always something you want to be very cautious about - whether you are talking about your IBM i or even your Linux, UNIX, and Windows servers. You know that a certain number of bugs will get worked out after a new release has come into the market and you tend to be a little cautious about applying the latest release upgrade. Having been released for over a year, V7R1 is now pretty mature and I haven’t heard of any significant upgrade problems.

IBM i users that are on V5R4 know that IBM recently announced the end of support date for that release (which means maintenance and support will stop in about a year) and people will need to upgrade. There are two reasons it is a good idea to jump past V6R1 straight and to V7R1. First, it is a fully supported path by IBM. Second, there are security benefits to making that jump. You are getting significant new security features in V7R1 that you won’t see in V6R1. I know that there are external factors that sometimes influence moving forward on releases. Some software vendors may not be ready for V7R1 and this can represent a significant barrier in terms of getting to the latest release of the operating system. If you have not yet begun a discussion with your software vendors on whether they have certified their software on V7R1, now is the time to do that. IBM makes it very easy for a software vendor to test their software on a pre-release version of the operating system. We do that, and your other software vendors should be doing that too, well before IBM releases a new version of the operating system. This is one time that you should balance the security benefits of V7R1 against the cautionary approach of going only to V6R1, which will be just one step for many people.

Download our podcast “IBM i Security: Skip V6R1 and Upgrade to V7R1” for more information on the security reasons that you should go straight to V7R1. Additionally, we will discuss how Townsend Security can help you take advantage of FIELDPROC, a new addition to V7R1, which allows companies to encrypt their sensitive data without changing their applications.

In June 2010, a computer worm called “Stuxnet” made worldwide news when it infiltrated Iranian science labs. Many of Iran’s industrial facilities including Natanz, were seriously harmed as a result of this worm. Uranium enrichment is a project that many global nuclear outfits are working on. The idea is to create a higher concentration of the Uranium isotope U-238 to make for a more reactive metal. The source codes for all of these machines are stored on computers, so they are run by what the computers are instructing them to do. When the bug hit, the sophisticated centrifuges began spinning too fast causing the machines to self-destruct.

The dials and gauges looked like they were functioning correctly, so the Iranian officials knew that an external virus or bug must have invaded their computer, with the specific instructions to destroy their appliances. After investigation, it was discovered that it wasn’t a virus, but a worm. A virus will corrupt individual files on a computer, but a worm is malicious software that spreads through a computer network. For a computer to avoid contracting a bug, computer security is paramount.

Having proper encryption and key management possibly could have prevented a disaster like this from happening. It really shouldn’t have had a chance. The Iranian government was running programs that needed the highest level of security and they could have done more to prevent this from happening.

We help our customers deal with security issues all the time. Alliance Key Manager, our encryption key management Hardware Security Module (HSM), has built-in encryption and decryption services. With an HSM, the encryption key never leaves the appliance, keeping the encryption key separate from the data it protects. By using encryption and key management, Iran could have possibly prevented Stuxnet from modifying the source code that caused their servers to self-destruct.

The effects of the Stuxnet worm were devastating for Natanz and other industrial facilities in Iran. Their nuclear projects were setback an estimated four months. This is of course, an extreme case with intended malice toward the government. This worm was specifically designed only to harm Iran’s centrifuges. Ralph Langner, an independent computer security expert and the man who discovered the intent of Stuxnet said, “The attackers took great care to make sure that only their designated targets were hit. It was a marksman’s job.”

 Hopefully, there isn’t a company or organization out there that will feel the need to specifically target your company. But there was some collateral damage to other computers caused by Stuxnet, and encryption and Key Management can prevent the effects or other worms. Take a look at the program!

For more information on encryption and key management, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data.

Yesterday, our partner, Symantec, released a survey on enterprise encryption practices.  The study contained both good news and bad shows when it comes to encryption and key management.  

First the good news, in a recent interview with eWeek Tim Matthews, senior director of product marketing at Symantec said, “About 48 percent of the survey participants reported their organization had increased their use of encryption over the past two years, with one third reporting "somewhat to extremely frequent" deployments of "rogue" projects without any centralized management oversight.”

Now the bad news, Tim Matthews goes on to say, “Business groups and employees are often independently encrypting the data without involving the IT department. While the move to encrypt is a good thing, these unauthorized deployments are a challenge for IT because the data is lost and irretrievable if the employee loses the key, forgets the passphrase or leaves the company without passing on custody of the encryption keys. If IT doesn't have the key, it also becomes harder to properly backup the data or to access the information as part of an e-discovery request”

We understand the difficulties in managing encryption keys and have been helping companies for years with this challenge, so when we saw this statistic about poor key management, it did not come as a big surprise to us, because we hear about the challenges first hand.  The study showed:   “About 52 percent of the respondents said they have had serious key management problems, with about a third claiming that keys were lost or misplaced keys and another third citing key failure. A little over a quarter, or 26 percent for the participants, said former employees refused to hand over keys when they left the company.”

We have posted several different checklists for companies to help them in their selection of key management vendor. One of our more popular lists is the 10 questions that you should ask your potential key management vendor. Given the news in the study, we thought it was worth showing this list again:

1. Is your key manager FIPS 140 certified?  What is the certificate number?
2. How would you describe the encryption key payload as retrieved from the key server?  Is it simple or complex?
3. Is there a common key retrieval application interface on all platforms?  What are the differences?
4. What platforms do you support for key retrieval?  (Note any gaps in platform coverage for your company)
5. Do you provide working sample code for the platforms I need? (Windows, Linux, UNIX, IBM i, IBM z)
6. Do you supply binary libraries for all Enterprise servers?
7. Do you have a Java key retrieval class and examples? Is it standard Java or JNI?
8. Do you charge separate license fees for each client operating system?
9. Do you require that we purchase consulting services from you?  Why?
10. I am an independent software vendor (ISV), can you brand the solution and certify the solution for us?

We encourage you to download and read the study from Symantec. We are sure you will find it very informative.  Then once you have read the study and have decided you need to learn more about encryption key management, listen to this informative 15-minute podcast.

One thing that jumped out at me at this year’s RSA conference in San Francisco was the number of new vendors showing off mobile identification solutions.  There were at least four new vendors of mobile-based two factor authentication solutions, and one regular exhibitor with a new entry in this area. These vendors didn’t have the biggest booths or the most lavish give-aways, but as a category they certainly made a big splash.

I think there are really two things responsible for this big change:  Two factor authentication is now more important for security, and everyone now carries a cell phone or mobile device. The second part of this is completely obvious. In fact, I often see people carrying multiple cell phones. The ubiquity of the  cell phone makes them an ideal platform to deliver a one-time password or PIN code. And phone numbers are a lot easier to manage than hardware tokens.

The first part of this, the change in the security landscape, is not as well known to many people. As we’ve moved to a de-perimeterized security reality, we are more dependent on passwords to authenticate the users of our systems. And security professionals know how weak that dependence is. People who access our systems persist in the use of weak passwords, and the bad guys get better and better at password cracking and harvesting. By itself, password authentication is a poor defense, and that’s why two factor authentication is getting a lot of attention.

So what is two factor authentication? It means that you use two different authentication methods to access a system. Those authentication methods include:

•    Something you know (like a password or PIN code)
•    Something you are (fingerprint, iris)
•    Something you have (cell phone, HID card, hardware token)

By combining two of these authentication methods during system access you greatly reduce the chance of a security breach. For web applications, you generally find the use of a password with a PIN code generated with a hardware token (something you know, something you have), because it really hard to use a fingerprint reader or iris scanning device (something you are).  And that’s why cell phone based two factor authentication is picking up steam.

Don’t be confused by security systems that use one factor twice. I’m sure you’ve seen it at work on banking web sites. First you enter a password, then you answer a personal question (where were you born, the age of your oldest child, etc.). This is one factor authentication (something you know) used twice. This is when 2 times 1 is not equal to 2.  The use of one factor authentication twice does not add up to two factor authentication, and does not provide the same level of security.

Cell phones and mobile devices are a great way to deliver that second authentication factor. You have to have your cell phone to get the one time PIN code used for authentication. And everyone has one.

For more information on data security and compliance issues, visit the regulatory compliance section of our website to learn more.

Patrick