Townsend Security Data Privacy Blog

IBM i users who need to meet compliance regulations for actively monitoring their systems are faced with the challenge of collecting system and security event information from a variety of log sources. We know we have to collect information from the IBM security audit journal QAUDJRN, but there are often additional security events in the system operator’s message queue QSYSOPR. The system operator message queue receives message from the IBM i operating system as well as from user applications.

There are many challenges in processing messages in the QSYSOPR file. These include:

• The QSYSOPR message information is in an IBM proprietary format that is impossible for log collection servers and SIEM solutions to process. The messages must be converted to a usable format.
• Access to the QSYSOPR message file by an event collector can conflict with the access by the actual system operators.
• There are no event-driven APIs that allow you to collect new QSYSOPR messages in real time. Your QSYSOPR message collector application must detect new events and process them quickly.
• The QSYSOPR messages are not updatable, so your QSYSOPR event collector must keep track of the messages that have been processed, and must resume after a system IPL or a system failure without lost information.
• QSYSOPR messages are not automatically transferred to a log collection server or SIEM solution. Communications programs must be able to transfer the messages securely in real time.

Alliance LogAgent meets all of these challenges. QSYSOPR messages are automatically processed in near real time. To avoid potential access conflicts, Alliance LogAgent can collect messages from the QSYSMSG message queue. Messages are converted from the proprietary IBM format to the industry standard syslog format (RFC 3164) and converted from EBCDIC to ASCII. Messages are then transmitted to the log collection server or SIEM solution securely and in real time.

The Alliance LogAgent QSYSOPR message collector is a part of the base product. If you are currently using LogAgent to process QAUDJRN events, you can just enable the QSYSOPR message file option and you will start processing messages the next time the Alliance LogAgent subsystem starts. If you are implementing Alliance LogAgent for the first time, just enable the LogAgent QSYSOPR collector before you start the subsystem.

View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

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

The OpenSSL Heartbleed security vulnerability is arguably the biggest security exposure in the history of the Internet. While IBM i (AS/400, iSeries) customers may be somewhat isolated from the larger impacts of this vulnerability, there are good reasons not to take this event lightly.

First, a disclaimer: Only IBM can comment in a definitive way on any Heartbleed vulnerabilities in the IBM i. The following are my opinions based on several years of work on the platform.

[UPDATE: IBM has issued a Security Bulletin stating that the IBM i is not effected by CVE-2014-0160 (Heartbleed)]

The first important fact to know is that OpenSSL is not commonly used in traditional IBM i network applications. IBM has an SSL/TLS library named GSKit and a certificate management application named Digital Certificate Manager. The underlying secure TLS implementation is not based on OpenSSL for these IBM-supplied applications. They probably do not pose a security issue for IBM i customers.

IBM does use OpenSSL in some of their IBM i open source applications. For example, the SSH implementation on the IBM uses OpenSSL. On a V7R1 system I started an SSH session and looked at the output:

OpenSSH_4.7p1, OpenSSL 0.9.8m 25 Feb 2010OpenSSH_4.7p1, OpenSSL 0.9.8m 25 Feb 2010

As you can see in the first log message, OpenSSL version 0.9.8m is used in SSH. Fortunately this version of OpenSSL is not vulnerable to Heartbleed. You should check your implementations of SSH, Apache, Websphere, Perl, PHP, and other open source applications to verify that they do not use a version of OpenSSL with the Heartbleed vulnerability.

Most third party vendors use the IBM i SSL/TLS library for secure communications. These applications will not be vulnerable to this new Heartbleed issue. All of the Townsend Security applications are based on the IBM library and not on OpenSSL. However, there are third party IBM i applications that embed OpenSSL or which use the OpenSSL application in the PASE environment. You should immediately contact your application vendors to determine if there are any exposures in their applications.

It is important to understand that while the IBM i platform may not be directly vulnerable to the Heartbleed problem, you may have lost IBM i User IDs and passwords over VPN or other connections which are vulnerable. An exploit of Heartbleed can expose any information that you thought was being protected with session encryption.

Once you know that your IBM i and all of your network services are patched or are not vulnerable to Heartbleed, you should immediately force a password change for all of your users. Don’t take a chance on missing this vulnerability at some point in your network infrastructure and exposing your IBM i data to loss.

Patrick

Security researchers have discovered a vulnerability in certain versions of the very popular OpenSSL application that can lead to the loss of critical sensitive information. The vulnerability is called Heartbleed because if affects the TLS heartbeat function in secure, connections. Because OpenSSL is used by so many web applications, and because this vulnerability can be exploited, the severity is very high.

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.

For more information about the Heartbleed security vulnerability and what you can do, please visit the following site:

http://heartbleed.com/

While Townsend Security applications are not subject to this vulnerability, it is very important that you address other applications that are vulnerable. The loss of sensitive information in one application can lead to the compromise of an otherwise unaffected application. For example, the loss of passwords in one application can lead to the compromise of another application if the same password is used. And personally identifiable information lost from one application can be used for fraudulent impersonation in another application or web service.

Patrick

One of the big fears that companies have as they deploy encryption of sensitive data is that they might lose their encryption key and never be able to decrypt and recover their data. Having spent some of my career in IT management I certainly understand where this comes from. There is nothing like a corrupted backup to turn a good day into a bad one. The same is true if you lose your encryption key.

So how do we help make sure that our Alliance Key Manager solution running in Windows Azure protects you from this potential problem? Let’s look at all of the things we do in our key management solution, and the things you can do in Windows Azure:

Backup / Restore
The first line of defense is always to have a backup of your encryption keys and key access policies. Alliance Key Manager provides you with an option to securely back up your encryption keys, security policies, and server settings and to move this backup out of Windows Azure to your own secure storage. You can do a manual backup at any time, and you can automate the backups on a schedule that you define. You can even automate the transfer of the backups to an external FTP server using secure, encrypted transfer methods. Don’t have an FTP server to receive your backups? Don’t worry, we can provide you with one in our secure cloud facility.

Key and Policy Mirroring
The next line of defense is to implement real-time key and security policy mirroring from your primary Alliance Key Manager cloud instance to a failover key manager instance running in Windows Azure or to a key manager running outside of Windows Azure. Alliance Key Manager fully implements key mirroring over a secure, encrypted connection to one or more secondary key servers. The secondary key servers will contain exact copies of the encryption keys and their access policies, and will always be ready in the event your primary key server stops working. Alliance Key Manager supports Active-Active mirroring so that you will always have a full set of your encryption keys available to you even after a failover.

Windows Azure Availability Sets
Do you know about Windows Azure Availability Sets? This is a feature of Windows Azure to help you avoid unplanned outages due to failures of the cloud infrastructure or planned Windows Azure maintenance activities. We encourage our Windows Azure users to take advantage of Availability Sets when deploying a second Alliance Key Manager instance. It provides one more way to get the best reliability for your key management infrastructure in the Windows Azure cloud.

Mirroring Outside the Windows Azure Cloud
Lastly, if you are still worried about losing your encryption keys, you can always mirror the keys to a key manager located outside the Windows Azure cloud. You could mirror your keys to a physical key manager HSM located in your data center or the hosting provider of your choice. Or, you could mirror your encryption keys to a dedicated key manager in our cloud data center (see Alliance Key Manager Cloud HSM). Or, you can mirror your keys to a VMware or Hyper-V instance of Alliance Key Manager in your data center or the hosting provider of your choice.

Alliance Key Manager in Windows Azure goes the distance to help ensure that you never lose an encryption key. You might be losing sleep over your move to the cloud, but you shouldn’t lose sleep over your encryption strategy.

Patrick

The primary concern of cloud customers is the security of their sensitive data. Security remains one of the major barriers to cloud adoption. And that makes sense. Cloud platforms like Microsoft Windows Azure are by their nature shared environments. The computational resources are shared, the network resources are shared, and the responsibility for physical security is ceded to a third party. That would make anyone nervous.

There are also some additional practical issues. Where, for example, do you actually store your encryption keys that protect your data? For customers and software providers who are fully in the cloud, this is a difficult practical question. You just don’t have a convenient place to securely store encryption keys away from the data that they protect.

Until now.

Today we announced the availability of our latest encryption key management solution, Alliance Key Manager for Windows Azure. The same key management solution that we ship in our FIPS 140-2 compliant key management hardware security module (HSM) is now available as a virtual machine in Windows Azure. With a few clicks in the Windows Azure portal you can launch Alliance Key Manager for Windows Azure and start protecting encryption keys the right way.

All of the features that make a hardware HSM desirable - key management and encryption dedicated to you, exclusive administrative access to only you (sorry cloud provider), encryption and key management provably based on industry standards, and high availability now run as your dedicated virtual machine.

Alliance Key Manager for Windows Azure is deployed in just the way you would hope. An affordable, usage based pricing model, and managed through the same Windows Azure facility that you manage all of your other virtual machines. For added security, you can launch your virtual machine in a Windows Azure Virtual Private Cloud (VPC), and you can deploy two VMs in a Windows Azure Availability Set for better redundancy.

As is the case for our hardware key management solutions, our Windows Azure cloud offering supports encryption within the key management virtual machine. This means that you don’t even need to expose the encryption key in your Windows Azure web application. Just send the data to the key management virtual machine and encryption or decryption takes place there.

In conjunction with our launch into the Windows Azure platform, we’ve also added a great new feature we call “Ready-To-Use”. When you start your key management virtual machine for the first time it will automatically install a 30-day evaluation license, generate the certificates you need for authentication, and generate some encryption keys that are unique to you and ready to use with SQL Server, SharePoint, and your Windows .NET applications. You are ready to start encrypting in seconds.

There are many challenges to meeting compliance regulations, and you should be aware of the recommendations of the Cloud Security Alliance and of the PCI Security Standards Council for encryption and key management. You don’t need to compromise with poor key management, or a key management solution that has never seen the daylight of a FIPS 140-2 validation.

Happy cloud computing!

Patrick

Today we learned that the Target data breach may have started when hackers used stolen vendor credentials to access a Target web site or application. The application and vendor is not known at this point, but there are some lessons we can learn from this breach:

You should be sure that your vendor applications do not have fixed administrative passwords or backdoor passwords. Talk to your vendors and get their responses in writing. Don’t deploy any vendor solution that has fixed passwords that can’t be changed.

You should change any default passwords on installation of vendor solutions.

• Use strong passwords and regularly change them
• Use Dual Control and Separation of Duties for any highly privileged users such as system and security administrators
• Add additional security methods to protect against this type of attack (read on)

Is there anything we can do to mitigate this type of attack?

Yes, the use of Two Factor Authentication (sometimes called Multi Factor Authentication) authentication can go a long way towards preventing this type of attack. We know that passwords alone are a poor means of authenticating a user and providing protected access to applications. Passwords are easily guessed, are often very weak, and can be stolen from our systems or a from a third-party system. Two Factor Authentication (2FA) makes it difficult to use a stolen password to access a sensitive system.

How does Two Factor Authentication work?

Two Factor Authentication adds something new to your authentication process. In addition to providing a password (something you know) to access a system, you must also authenticate with something you have (such as a mobile phone or hardware token) or something you are (fingerprint or iris scan). By adding an additional authentication method that is not readily accessible to a hacker, you get much more security.

Mobile phones are ubiquitous and have become a common way to implement 2FA. After providing a password to a web site or application, a PIN code is sent to your phone via an SMS text message or voice phone call. You have to provide the correct PIN code in order to continue. This is the method that Google and Yahoo offer, and is a common feature in on-line banking web sites. A hacker may steal password credentials, but it is much harder to take control of your phone.

In recognizing the need for better access security we recently released our new Alliance Two Factor Authentication solution for the IBM i platform. It is intended to mitigate exactly this type of attack using mobile-based 2FA.

If you don’t get the SANS newsletter it would be well worth your time to sign up now. It is a mix of the latest security news, available training classes from SANS, and commentary. This was the leader in the last newsletter of 2013 (emphasis mine):

The top story at the end of 2013 could just as well have been the top
story ten years ago. Federal chief information security officers
continue to "admire the problem" by paying $250/hour consultants to
write reports about vulnerabilities rather than paying them to fix the
problem. Sadly most of the federal CISOs and more than 85% of the
consultants lack sufficient technical skills to do the forensics and
security engineering to find and fix the problems.  Paying the wrong
people to do the wrong job costs the U.S. taxpayer more than a billion
dollars each year in wasted spending plus all the costs of cleaning up
after the breaches.  How about a 2014 New Years resolution to spend
federal cybersecurity money usefully: either by ensuring all the
sensitive data is encrypted (at rest and in transit) and/or the
organization implements the Top 4 Controls on the way to implementing
the 20 Critical Security Controls?
- Alan Paller

The news of the Target data breach was tragic for both consumers and for the company. The story would have been quite different if the credit card numbers had been encrypted. But the sad truth is that many organizations, both public and private, are still vulnerable to the loss of unencrypted credit and debit cards.

Too often the Payment Card Industry Data Security Standard (PCI-DSS) is treated like a check-box exercise, and not like an active, on-going call to arms. And too many merchants remain vulnerable to this type of loss even today.

I agree with Alan Paller - we need to step well beyond PCI DSS and other compliance regulations and take a far more active and aggressive stance on protecting sensitive data. Minimally this should include:

• Encrypt all sensitive data with industry standard encryption (e.g. 256-bit AES)
• Store encryption keys away from the data they secure
• Protect encryption keys with an Enterprise Key Management system
• Actively monitor encryption and key management systems

Encrypting sensitive data is only one thing you need to do as a part of a security strategy. But as recent events demonstrate, you don’t have a security strategy without encryption and proper key management.

Best wishes for 2014!

Patrick

As a data security company, we talk to a lot of people concerned with keeping their systems and information safe.  Compliance regulations are often the driving force behind our conversations – and these discussions are with people who can be divided into two camps – as either being proactive or reactive.  The proactive group realizes that data breaches are not a matter of if, but when, and on average cost an organization over $7 million.  The reactive segment is often facing a failed security audit or has experienced worse – a data breach because the proper controls were not in place.

Not very often do we have a conversation about the immediate return on investment (ROI) of deploying a security solution.  Patrick Botz of Botz and Associates tells us that not only has he been having plenty of these conversations, he is helping companies save thousands of dollars a year with his SSO stat! service.

If you are a security professional, his name may sound familiar.  Prior to starting his own consulting company, he was the Lead Security Architect at IBM and founder of the IBM Lab Services security consulting team.

By enabling single sign-on (SSO) with the technology that an organization already has, Patrick Botz helps businesses see a return on their investment of his services typically within 2-6 months.  Recently he authored a white paper titled “A Guide to Practical Single Sign-On – The Case for Managed SSO” that takes a real-world look at single sign-on technology and offers a straightforward, sensible approach to SSO.

Rather than SSO being a technology problem, Botz asserts that managing passwords is truly a business problem.  As he writes in his white paper, “The REAL purpose of SSO is to significantly reduce the high cost of managing passwords across the organization.” The ROI can be best illustrated by a story he likes to tell from when he was at IBM:

“At one point, I started tracking the time I spent changing passwords and “recovering” from those changes.  I was very surprised to learn that instead of the 10-15 minutes I thought I was spending, it really was taking, on average, closer to 35-40 minutes! And I was just one of about 300,000 employees! Assuming 30 minutes on average across all employees, four times a year — that equates to 600,000 hours of time! If the average hourly rate per employee is only $20, that’s $1.2 million dollars!  And that’s just for end users!”

While the primary goal of SSO is to reduce the costs associated to managing multiple passwords, it also reduces the risk of a lost or stolen password due to employee negligence.  How often do we hear about confidential information “protected” with:

• Easily guessed passwords
• Written lists of passwords located under keyboards, desk drawers, etc.
• Lists of passwords stored in files on workstations or network drives
• Shared userIDs/passwords

So once an organization decides that they need an SSO solution, what should they consider before deploying one?  In the white paper, Botz discusses the pros and cons of the four technical approaches to SSO, but concludes that two technologies will ultimately do the lion’s share of work (60-80%) for most companies.  For these organizations, eliminating passwords with Kerberos and EIM ends up being the best starting point.

Typically, the extra cost involved in achieving 100% “Single Sign-On Nirvana” is simply not justified by the estimated costs.  Further, as Botz states in his white paper, “It turns out that most businesses get the best ROI by using technology that they already own to eliminate the high cost of managing passwords – over their entire multi-platform network.”  By not needing to invest in any additional technology, an organization is not responsible for any additional software licenses or maintenance fees.

After talking with Patrick Botz and reading his white paper, I am looking forward to using his SSO stat! service at Townsend Security!  For more information on Single Sign-On and how it can save your organization time and resources while increasing security, download his white paper “A Guide to Practical Single Sign-On – The Case for Managed SSO.”

It’s truly fascinating to watch one of the great technology paradigm shifts, isn’t it? We now take for granted that the applications we use run in the cloud and organizations are moving applications to the cloud as quickly as possible. It’s an amazing transformation of how technology is delivered to consumers and organizations of all types.

In this midst of this transformation and migration to the cloud, one issue remains at the top of everyone’s mind: Security.

Protecting sensitive data in the cloud has all of the same challenges as protecting data in on-premise IT infrastructure, and some new challenges as well. For example, when you use encryption to protect your data assets, security best practices say that you should use encryption key management hardware security modules (HSMs) to protect encryption keys. But where does this critical security device reside when your applications live in the cloud?

Our new Alliance Key Manager Cloud HSM solution is designed to answer this question. Starting today, we now offer our FIPS 140-2 compliant encryption key management HSM in the cloud. Cloud application vendors and cloud users can now get the best encryption key management without having to deploy HSMs in their own data center.

Here are a few highlights of our new offering:

• Alliance Key Manager HSMs in a secure cloud platform
• PCI-DSS and SOC validated secure physical infrastructure
• Only you have access to your key managers - no cloud provider access or administration is allowed
• Production and HA key servers always included
• Real-time key server mirroring with geographic, network, and power redundancy
• Server monitoring and notification included with the license
• Client-side encryption applications at no additional charge. Quickly and easily protect SQL Server, Oracle, MySQL and other databases.
• Cloud provider independence - you control your cloud provider choices
• Affordable options for perpetual and subscription licensing
• No set up fees through December 31, 2013!

I am proud of our leadership in encryption key management for enterprises large and small. This is the first cloud HSM offering that gives you exclusive control over your key management strategy and independence from your cloud provider.

Here at Townsend Security we are dedicated to making the best possible data protection easy-to-use and affordable for every size organization. If you thought that good encryption key management was out of reach, let us show you a new way forward. Evaluations are fast, easy, and free.

Patrick