Upgrading For Federal Reserve Bank MQ Integration

For financial institutions using WebSphere MQ V6.x or older to communicate with the Federal Reserve Bank, your time is running out… and fast. WebSphere MQ V6.x went End of Support on September 30th, 2012 and the Federal Reserve Bank is requiring upgrades to a current, supported version.

WebSphere MQ V7.0.0 and V7.0.1 went End of Support at the end of September 2015. For those of you wondering about WebSphere MQ V7.1, you might want to reconsider. While still technically supported by IBM, V7.1 is likely looking at another upgrade within the next 18 to 24 months.
From a business perspective, I recommend financial institutions upgrade to IBM MQ V8.x. At the very least, you could consider MQ V7.5.x.

IBM MQ V8.x, rebranded from WebSphere MQ is now full equipped with fix pack 3 and has proven to be very stable.

Further, MQ V7.5.0.5 and MQ V8.0.0.3, have deprecated SSLv3 connections due to the Poodle Exploit and reduced the number of supported Cipher Suites. (It is critical you understand the supported connection protocols and Cipher Suites supported by the Federal Reserve Bank.)
But MQ upgrades are only half the story.

If you haven’t been keeping pace with MQ updates, you’ve likely not been keeping pace with OS either. OS updates to supported versions are arguably equally as critical as MQ.

Interested in learning more about your options? Let’s start a conversation. Reach out to TxMQ today.

America Needs An Education On Software Asset Management (SAM)

I recently had the privilege of attending (and co-sponsoring) the IBSMA SAM Summit in Chicago with some colleagues. It was a fantastic event with great sessions, a wonderful format and venue and amazing networking opportunities.   Representatives were in attendance from all of the major software vendors and many tool companies, alongside SAM consultancies like TxMQ.
What I noticed right away, though, was the skewed attendance. It’s wonderful seeing so many foreign firms travel thousands of miles to attend a conference in the US, but I’m really surprised by the lack of American and Canadian firms in attendance.
I have a theory I’ve been forwarding on why. Like many of my theories, this one’s based on a limited sampling of statistically insignificant data sets. So please give me a lump or two of salt for starters.
First, some contextual background: It’s clear to any informed American that we, as a nation, excel at many things. We eat well, spend well, vacation well, enjoy the finer things in life when we can afford them (and oftentimes when we cannot), and we love kicking problems down the road. Denial is more than an art form. It’s a social science.
Social Security reform? Not my problem – let future generations deal with it.   National debt? Please. My kids and grandkids can pay that off. The environment? Fossil-fuel consumption? Hardly seems to be an issue for my generation.
And US management is too often focused on putting out fires, instead of building fireproof things. So it shouldn’t have been a surprise to see so few American firms interested in understanding and investing in compliance improvement and best practices.
We must work to change the culture of America at a macro level, that much is clear. But we can all work today to change the culture of our workplaces to embrace SAM and declare it a must-do effort – not a future “nice to do if we get audited” thing.
Software Asset Management should NOT be undertaken as an audit-defense practice, but as a part of an overall corporate strategic leadership. Corporate best practice should be to have a tightly integrated leadership organization that includes a SAM leader alongside corporate-compliance officers, security officers and financial overseers.
From software-renewal-agreement negotiations to better alignment between software usage and needs, SAM brings tremendous goodness to organizations.
I’ve written separately on much of the value of SAM, as have many others, so I won’t get into a deep-dive here. But I will say again that a well-run company, with a solid SAM program, delivers greater value to its shareholders by:

  • Minimizing waste (like unused software and entitlements)
  • Maximizing efficiency (by limiting the wasted time replatforming out-of-compliance software or applications)
  • Creating a more positive environment for stakeholders (there’s less stress and worry because there’s less uncertainty and confusion around assets and their allocation or disposition)

Let’s all do our part to help educate our workplaces on SAM as a necessary part of corporate governance and leadership. I’m ready to start the conversation: mailto:chuck@txmq.com.

Hacking into Healthcare: Why hackers want health data and how healthcare SMBs can protect their patients

As I was reading about Cedar Sinai’s recent implementation of Bottomline’s Healthcare Data and Security Solution, I couldn’t help but to wonder – why is patient data at risk in the first place?
Clearly, we can all understand why big box shops like Target and Home Depot were hacked; credit card numbers are better than cash. Siphoning electronic funds is the digital age’s form of Bonnie and Clyde-style bank robbing. So, realistically, what could a hacker possibly stand to gain from breaching healthcare data security and gaining access to my records?
After consulting with a few colleagues in the healthcare industry, I realized there is one extraordinarily valuable piece of information that all U.S. residents have – a social security number. With that 9-digit treasure chest, individuals with more nefarious tendencies can open a line of credit under your SSN, file for a fraudulent tax refund and open financial accounts. But, that’s not all.
Medical identity threat was up 40 percent in 2013. Stolen health credentials go for about $10 each, double and sometimes triple the black market value for credit card numbers. This information can be used in hundreds of ways, but what they’re really after is your identity.
In some cases, only a few that I found, are hackers ever really interested in your maladies. Social security checks, yes, credit lines, yes… your latest blood pressure reading? Not so much. But it does happen. Mostly, though, they’re breaching healthcare data security so they can pretend to be you, convincing a bank they are you, which is much more valuable than health history.
So that’s why protecting patient data is extremely important to healthcare organizations. It isn’t just about not having the world know about your heart condition, although that certainly is one reason. It’s about what people are capable of doing once they get ahold of all the information that they need to take control of your financial credibility. Cedar Sinai’s decision to implement Bottomline puts them one step farther away from a reputation-damaging data breach.
That being said, what can smaller companies do for healthcare data security? Bottomline has a price tag that could bankrupt small specialty providers. What are the security options out there for the healthcare SMBs?
While there are many options out there, IBM has a whole arsenal of data, application and integration security options – many of which are scalable for both size and budget. Fortune 500s all the way to private locally-owned practices can benefit from a number of these solutions. These security products are packaged to meet individual organizations’ needs, ranging from identify protection to fraud prevention, from encryption to vulnerability assessment. How do you know what’s right for you? As an IBM Business Partner, TxMQ assists companies with the selection, deployment and maintenance of enterprise security options. As experts in securely integrating solutions in the cloud, we can not only help make your patient records more secure, but we can help you digitize them, as well. We’ll stay with you for as short or as long as you need us.
Photo from BrainFoodTV.com

Upgrade Windows Server 2003 (WS2003) – Do It Today

Another day, another end-of-support announcement for a product: On July 14, 2015, Windows Server 2003 (WS2003) goes out of support.
Poof! Over. That’s the bad news.
What’s the upside? Well, there isn’t really an upside, but you should rest assured that it won’t stop working. Systems won’t crash, and software won’t stop running.
From the standpoint of security, however, the implications are rather more dramatic.
For starters, this automatically means that anyone running WS2003 will be noncompliant with PCI security standards. So if your business falls under these restrictions – and if your business accepts any credit cards, it certainly does – the clock is ticking. Loudly.
There’ll be no more security patches, no more technical support and no more software or content updates after July 14, 2015. Most importantly, this information is public. Hackers typically target systems they know to be out of support. The only solution, really, is to upgrade Windows Server 2003 today.
TxMQ consultants report that a large percentage of our customers’ systems are running on Windows Server, and some percentage of our customers are still on WS2003. There are no terms strong enough terms to reinforce the need to get in touch with TxMQ, or your support vendor, for an immediate plan to upgrade Windows Server 2003 and affected systems.
Server migrations oftentimes take up to 90 days, while applications can take up to 2 months. Frankly, any business running WS2003 doesn’t have 60 days to upgrade, let alone 90. So please make a plan today for your migration/upgrade.

IRS Get Transcript Breach – The Agency Didn't Adequately Prepare

The announcement came yesterday: Chinese hackers had breached the federal government’s personnel office. In isolation, this might seem a single event. But when viewed in the grouping of several other top-level hacks, it becomes clear that the federal government is extremely vulnerable.
One clear parallel was the recent IRS Get Transcript breach, announced in late May, which is believed to trace to the Soviet Union. The information was taken from an IRS website called Get Transcript, where taxpayers can obtain previous tax returns and other tax filings. In order to access the information, the thieves cleared a security screen that required detailed knowledge about each taxpayer, including their Social Security number, date of birth, tax-filing status and street address. The IRS believes the criminals originally obtained this information from other sources. They were accessing the IRS website to get even more information about the taxpayers, which would help them claim fraudulent tax refunds in the future. Might the information in the more recent hack also provide the fuel for a future hack? Quite likely, in my opinion.
What’s especially bothersome to me is the IRS had received several warnings from GAO in 2014 and 2015. If the warnings had been implemented, there would have been less of an opportunity for the attack. The IRS failed to implement dozens of security upgrades to its computer systems, some of which could have made it more difficult for hackers to use an IRS website to steal tax information from 104,000 taxpayers.
In addition, the IRS has a comprehensive framework for its cybersecurity program, which includes risk assessment for its systems, security-plan development, and the training of employees for security awareness and other specialized topics. However, the IRS did not correctly implement aspects of its program. The IRS faces a higher statistical probability of attacks, but was unprepared. Let’s face it: The US federal government is a prime target for hackers.
The concern here, of course, is the grouping of attacks and the reality that the US government must be more prepared. I’ve managed IT systems and architecture for more than 3 decades and I’ll say this: The IRS testing methodology wasn’t capable of determining whether the required controls were in effective operation. This speaks to not only physical unpreparedness, but a general passive attitude toward these types of events and the testing protocols. The federal government doesn’t adequately protect the PII it collects on all US citizens, and simply sending a letter to those impacted by a breach is not enough to prevent recurrence in the future.
I don’t need to tell you that. The GAO told the IRS the same thing: “Until IRS takes additional steps to (1)address unresolved and newly identified control deficiencies and (2)effectively implements elements of its information security program, including, among other things, updating policies, test and evaluation procedures, and remedial action procedures, its financial and taxpayer data will remain unnecessarily vulnerable to inappropriate and undetected use, modification, or disclosure.”
These shortcomings were the basis for GAO’s determination that IRS had a significant deficiency in internal control over financial-reporting systems prior to the IRS Get Transcript Breach.
Author Note: In my next blog on security, I’ll talk about the NIST standard for small businesses, with recommendations to prepare and protect in the wake of these high-level breaches.
(Photo by Ray Tsang)

What The Premera Breach Teaches Us About Enterprise Security

By TxMQ Middleware Architect Gary Dischner
No surprise to hear of yet another breach occurring – this time at Premera Blue Cross. The company became aware of a security breach on Jan. 29, 2015, but didn’t begin to notify anyone involved (including the state insurance board) until March 17, which was 6 weeks later. The actual attack took place in May 2014 and may affect 11 million customer records dating back to 2002.
As with many companies that experience a security breach, the excessive delays in first identifying and confirming that a breach has occurred, coupled with the typical delays in assessing and providing notification, subsequently led the state insurance board to fault Premera with untimely notification. A review of the HIPAA regulations for breach reporting indicates that a notification of those impacted absolutely needs to occur within 60 days. Many companies, including Premera, just aren’t equipped with the tools and security-management processes to handle these incidents. For Healthcare companies, HIPAA guidelines state that notification to the state insurance commissioner should be immediate for breaches involving more than 500 individuals. Consequently, Premera is now being sued by the state insurance commissioner.
A company found guilty of late notification should concern the public: There’s at least the appearance of a general lack of concern over both the impact and severity to its customers, partners and constituents. Blue Cross Premera has responded to its own behavior with efforts to protect itself and to cover up details of the incident, rather than be forthright with information so that those impacted can take the needed steps to protect themselves from further exposure and potential consequences, such as fraud and identify theft.
A secondary concern is the lack of security-management measures around protected data at many companies. In this case, the audit recommendations – which had been provided to Premera on Nov. 28, 2014 – found serious infractions in each of the following domains:

  • Security management
  • Access controls
  • Configuration management
  • Segregation of duties
  • Contingency planning
  • Application controls specific to Premera’s claims-processing systems
  • HIPAA compliance

More and more companies are being reminded of the data exposures and related risks, but remain slow to respond with corrective measures. Companies of high integrity will take immediate responsive measures and will openly express concern for the repercussions of the exposure. Companies that do not? They should be dealt with severely. Let this Premera example serve as the Anthem breach for companies that are holding sensitive data. As a customer or business partner, let them know you expect them to take every measure to protect your healthcare and financial information.
And in closing, let’s all take away a few lessons learned. Security assessments must become a regular operational function. Self-audits demonstrate a company’s high integrity and commitment to identifying process improvements for security management. Such efforts should be assessed quarterly with reports to the company board to make sure every vulnerability is remediated and customers who are working with the company are protected. After all, it’s only the company that can secure its own technical environments.
Photo by torbakhopper

Managed File Transfer: Your Solution Isn't Blowing In The Wind

If FTP were a part of nature’s landscape, the process would look a lot like a dandelion gone to seed. The seeds need to go somewhere, and all it takes is a bit of wind to scatter them toward some approximate destination.
Same thing happens on computer networks every day. We take a file, we stroke a key to nudge it via FTP toward some final destination, then turn and walk away. And that’s the issue with using FTP and SFTP to send files within the enterprise: The lack of any native logging and validation. Your files are literally blowing in the wind.
The popular solution is to create custom scripts to wrap and transmit the data. That’s why there’s typically a dozen or so different homegrown FTP wrappers in any large enterprise – each crafted by a different employee, contractor or consultant with a different skillset and philosophy. And even if the file transfers run smoothly within that single enterprise, the system will ultimately fail to deliver for a B2B integration. There’s also the headache of encrypting, logging and auditing financial data and personal health information using these homegrown file-transfer scripts. Yuck.
TxMQ absolutely recommends a managed system for file transfer, because a managed system:

  • Takes security and password issues out of the hands of junior associates and elevates data security
  • Enables the highest level of data encryption for transmission, including FIPS
  • Facilitates knowledge transfer and smooth handoffs within the enterprise (homegrown scripts are notoriously wonky)
  • Offers native logging, scheduling, success/failure reporting, error checking, auditing and validation
  • Integrates with other business systems to help scale and grow your business

TxMQ typically recommends and deploys IBM’s Managed File Transfer (MFT) in two different iterations: One as part of the Sterling product stack, the other as an extension on top of MQ.
When you install MFT on top of MQ, you suddenly and seamlessly have a file-transfer infrastructure with built-in check-summing, failure reporting, audit control and everything else mentioned above. All with lock-tight security and anybody-can-learn ease of use.
MFT as part of the Sterling product stack delivers all those capabilities to an integrated B2B environment, with the flexibility to quickly test and scale new projects and integrations, and in turn attract more B2B partners.
TxMQ is currently deploying this solution and developing a standardization manual for IBM MFT. Are you worried about your file transfer process? Do you need help trading files with a new business partner? The answer IS NOT blowing in the wind. Contact us today for a free and confidential scoping.
Photo by Alberto Bondoni.

IBM WebSphere Message Broker And Integration Bus Both Vulnerable To POODLE

[fusion_text]Shortly after its announcement that WebSphere MQ could be exposed to the POODLE vulnerability, IBM issued a similar warning for its IBM WebSphere Message Broker and IBM Integration Bus (IIB) products. POODLE is short for Padding Oracle On Downgraded Legacy Encryption and it exploits an opening in SSLv3. Because SSLv3 is enabled by default in IBM WebSphere Message Broker and IBM Integration Bus, hardening against POODLE is critical. (See TxMQ’s coverage of the WebSphere MQ vulnerability here.)
OpenSSL could allow a remote attacker to bypass security restrictions. When configured with “no-ssl3” as a build option, servers could accept and complete an SSL 3.0 handshake, which could then be exploited to perform unauthorized actions.

Affected Products

The specific list of affected products includes:

  • IBM WebSphere Message Broker V7.0 and V8.0
  • IBM Integration Bus V9.0
  • IBM WebSphere Message Broker Hypervisor Edition V8.0
  • IBM Integration Bus Hypervisor Edition V9.0
  • IBM SOA Policy Pattern for Red Hat Enterprise Linux Server

Workarounds

The most important action is to disable SSLv3 and switch to TLS protocol on Message Broker and IIB servers and clients. Product-specific instructions, with direct links to the more detailed instructions in the IBM Knowledge Center, are listed below.

Inbound Connections

The attack vector is around inbound. The outbound connections may stop working if the server disallows SSLv3.
Inbound HTTP connections using the Broker-wide listener: Instructions found here.
mqsichangeproperties broker name -b httplistener -o HTTPSConnector -n sslProtocol -v TLS
Inbound HTTP connections using the integration server listener will by default use TLS (as the integration server listener defaults to TLS). If however it has been modified to match the broker-wide listener, use these instructions to make the necessary changes to use TLS.
mqsichangeproperties broker name -e integration_server_name -o HTTPSConnector -n sslProtocol -v TLS
Inbound SOAP connections using the non-default broker-wide listener: Instructions found here.
mqsichangeproperties broker name -b httplistener -o HTTPSConnector -n sslProtocol -v TLS
Inbound SOAP connections using the integration server listener (the default choice) will by default use TLS (as the integration server listener defaults to TLS). If however it has been modified to match the broker-wide listener, use these instructions to make the necessary changes to use TLS.
mqsichangeproperties broker name -e integration_server_name -o HTTPSConnector -n sslProtocol -v TLS
TCPIP Server inbound: Instructions found here.
mqsichangeproperties MYBROKER -c TCPIPServer -o myTCPIPServerService -n SSLProtocol  -v TLS
WebAdmin inbound: Instructions found here.
mqsichangeproperties brokerName -b webadmin -o HTTPSConnector -n sslProtocol -v TLS
ODBC (DataDirect) OpenSSL as configured in odbc.ini: The ODBC Oracle Wire Protocol driver allows for the EncryptionMethod connect option to be set to a value of 5, which means only use TLS1 or higher. Setting EncryptionMethod=5 for the Oracle Wire Protocol driver will avoid POODLE. This functionality has been available since 6.1 version of the Oracle WP driver. The providers of DataDirect drivers are working on similar functionality to all other ODBC drivers that support SSL and upgrading the version of OpenSSL used within the drivers to pick up the enhancement to SSL negotiation.
The client-based ODBC drivers (DB2 Client and Informix Client) rely on the SSL implementation within the database’s client libraries. See client libraries to learn about possible exposure to POODLE.

Outbound Connections

Once the servers are changed to use TLS, it’s important to update the outbound settings with the following commands. Note that in all the following instructions, TLS can be substituted for SSL_TLS or SSL_TLSv2 if needed.
For HTTP connections: Instructions found here.
Then in the SSL tab of the Request node(s) select TLS for the Protocol.
For SOAP connections that have been modified to use the non-default SSLv3 protocol: Instructions found here.
Then in the SSL tab of the Request node(s) select TLS for the Protocol.
TCPIP Client: Instructions found here.
mqsichangeproperties MYBROKER -c TCPIPClient -o myTCPIPClientService -n SSLProtocol -v TLS
JMS Nodes: Some information found here. Follow instructions as provided by your JMS Provider.
Follow instructions as provided by your JMS Provider.
CICS Nodes: Instructions found here.
the CICS nodes use TLS by default, so no change needed.

Security Providers

WSTrust: Set the environment variable MQSI_STS_SSL_PROTOCOL to “TLS”
TFIM: Set the environment variable MQSI_TFIM_SSL_PROTOCOL to “TLS”
Click here for IBM’s full CVE-2014-3566 bulletin.
TxMQ is an IBM Premier Business Partner and “MQ” is part of our name. For additional information about this vulnerability and all WebSphere-related matters, contact president Chuck Fried: 716-636-0070 x222, mailto:chuck@TxMQ.com.
TxMQ recently introduced its MQ Capacity Planner – a new solution developed for performance-metrics analysis of enterprise-wide WebSphere MQ (now IBM MQ) infrastructure. TxMQ’s innovative technology enables MQ administrators to measure usage and capacity of an entire MQ infrastructure with one comprehensive tool.
(Photo by greg westfall under Creative Commons license.)
[/fusion_text]

POODLE Vulnerability In SSLv3 Affects IBM WebSphere MQ

Secure Socket Layer version 3 (SSLv3) is largely obsolete, but some software does occasionally fall back to this version of SSL protocol. The bad news is that SSLv3 contains a vulnerability that exposes systems to a potential attack. The vulnerability is nicknamed POODLE, which stands for Padding Oracle On Downgraded Legacy Encryption.

The vulnerability does affect IBM WebSphere MQ because SSLv3 is enabled by default in MQ.
IBM describes the vulnerability like this: IBM WebSphere MQ could allow a remote attacker to obtain sensitive information, caused by a design error when using the SSLv3 protocol. A remote user with the ability to conduct a man-in-the-middle attack could exploit this vulnerability via a POODLE (Padding Oracle On Downgraded Legacy Encryption) attack to decrypt SSL sessions and access the plaintext of encrypted connections.”

The vulnerability affects all versions and releases of IBM WebSphere MQ, IBM WebSphere MQ Internet Pass-Thru and IBM Mobile Messaging and M2M Client Pack.

To harden against the vulnerability, users should disable SSLv3 on all WebSphere MQ servers and clients and instead use the TLS protocol. More specifically, WebSphere MQ channels select either SSL or TLS protocol from the channel cipherspec. The following cipherspecs are associated with the SSLv3 protocol and channels that use these should be changed to use a TLS cipherspec:
AES_SHA_US
RC4_SHA_US
RC4_MD5_US
TRIPLE_DES_SHA_US
DES_SHA_EXPORT1024
RC4_56_SHA_EXPORT1024
RC4_MD5_EXPORT
RC2_MD5_EXPORT
DES_SHA_EXPORT
NULL_SHA
NULL_MD5
FIPS_WITH_DES_CBC_SHA
FIPS_WITH_3DES_EDE_CBC_SHA

On UNIX, Linux, Windows and z/OS platforms, FIPS 140-2 compliance mode enforces the use of TLS protocol. A summary of MQ cipherspecs, protocols and FIPS compliance status can be found here.

On the IBM i platform, use of the SSLv3 protocol can be disabled at a system level by altering the QSSLPCL system value. Use Change System Value (CHGSYSVAL) to modify the QSSLPCL value, changing the default value of *OPSYS to a list that excludes *SSLV3. For example: *TLSV1.2, *TLSV1.1, TLSV1.

TxMQ is an IBM Premier Business Partner and “MQ” is part of our name. For additional information about this vulnerability and all WebSphere-related matters, contact president Chuck Fried: 716-636-0070 x222, chuck@TxMQ.com.

TxMQ recently introduced its MQ Capacity Planner – a new solution developed for performance-metrics analysis of enterprise-wide WebSphere MQ (now IBM MQ) infrastructure. TxMQ’s innovative technology enables MQ administrators to measure usage and capacity of an entire MQ infrastructure with one comprehensive tool.
(Photo from J Jongsma)

WebSphere DataPower not affected by "Shellshock" Virus

IBM released a notice this morning stating that the IBM DataPower appliance is not vulnerable to the Shellshock vulnerabilities, also referred to as the Bash Bug and the two memory corruption vulnerabilities.
DataPower doesn’t use Bash anywhere and therefore it is not impacted by any of the Bash vulnerabilities.
Inparticular, dataPower in all editions and all platforms is NOT vulnerable to the Bash vulnerabilities: CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, and CVE-2014-6278.
However, it is recommended that you review your entire environment to identify vulnerable releases of Bash ad take appropriate action where needed.
Source: http://www-01.ibm.com/support/docview.wss?uid=swg21685435&myns=swgws&mynp=OCSS9H2Y&mync=E