Townsend Security Data Privacy Blog

Lately I’ve seen some criticism of the OpenSSH implementation on the IBM i platform which seems to imply that using a third-party implementation of the Secure Shell (SSH) file transfer application is better without the IBM no-charge licensed OpenSSH implementation. I disagree with that opinion and think there are good security and implementation reasons to stick with the IBM OpenSSH implementation.

Here are some reasons why I like OpenSSH:

OpenSSH is supported by an global open source community

Tatu Ylönen founded SSH Communications in 1995 and produced the first versions of an open source SSH implementation. Since 1999 the OpenSSH application has been maintained by the OpenBSD Project which is funded by the OpenBSD foundation and managed by Theo de Raadt. OpenSSH is available on a wide variety of operating systems including the IBM i where it is deployed as a no-charge licensed product and maintained by IBM.  OpenSSH continues to be actively developed and new encryption algorithms have been added recently.

OpenSSH is a widely used by large and small organizations

By some estimates the OpenSSH implementation of the SSH protocol and applications commands a 97 percent market share for SSH implementations. This means that OpenSSH is in wide use by large and small organizations to securely manage their eCommerce needs. This also means that OpenSSH receives a lot of scrutiny by compliance and security experts. Widely deployed solutions tend to get more scrutiny from security experts, and this is true for OpenSSH.

OpenSSH is secure

No application is immune to security challenges. However, OpenBSD and the OpenSSH application in particular have a stellar record for security. With security products, deep expertise and commitment matter. OpenSSH started with security as a leading goal by its developers and it shows. Over the last few years there have been fewer than a dozen security issues, and most were unlikely to be exploited and all were patched rapidly through updates by IBM. The OpenBSD set of applications that include OpenSSH have a great record on security. If you think the IBM i platform has a good security record, take a look at OpenSSH.

IBM provides technical support for OpenSSH

We have all developed a deep appreciation for IBM’s commitment to security over the years. It is one of great values of the IBM i platform. As new vulnerabilities are discovered you need to have a reliable and timely source of patches and enhancements and IBM has stood behind this critical application. Security notifications are managed by IBM so that you know when you need to do an update. By making OpenSSH a no-charge licensed program IBM i customers get patches through the normal PTF update process. Do you know any third-party IBM i vendor with an equal commitment to notification, maintenance and patching? IBM has earned our trust through this process.

OpenSSH is PCI compliant

PCI Qualified Security Assessors (QSAs) like Coalfire, TrustWave and others recognize that a properly patched implementation of OpenSSH meets PCI Data Security Standards (PCI-DSS) compliance, and IBM also tracks OpenSSH for PCI compliance. This again reflects IBM’s and OpenBSD’s commitment to security. If you are using a third-party IBM i solution for SSH how well is it tracked by the PCI audit community?

SSH is a complex protocol

Bruce Schneier said “Complexity is the enemy of security.” SSH is a complex protocol and this means that extra care needs to be taken in its development, deployment and maintenance. No third-party SSH solution rises to the level of care taken by the OpenSSH community and by IBM. Almost every business depends on secure file transfer for daily business operations. Deploying the most secure SSH solution is a critical security step.

OpenSSH does not use OpenSSL or Java JSSE

We’ve read a lot over the last few months about security issues in OpenSSL and Java. Many IBM i customers are confused about the relationship between OpenSSH and OpenSSL. In fact, OpenSSH does not use the OpenSSL library for communications. This means that OpenSSH was not subject to the HeartBleed and other OpenSSL vulnerabilities. We are all also now painfully aware of the security issues in Java. Most browsers no longer allow Java plugins for this reason. Third-party SSH products may or may not use OpenSSL or Java for communications. If you are running a third-party IBM i SSH solution, do you know if it uses OpenSSL or Java?

Third-party SSH solutions provide no significant advantage over OpenSSH

OpenSSH is a secure, reliable, and resilient implementation of SSH for secure data transfer that is backed by IBM and a worldwide community of users and developers. Our Alliance FTP Manager solution fully integrates with the IBM i OpenSSH application for secure, automated and managed file transfer. Our solution automates the OpenSSH transfer of hundreds of thousands of file transfers every day without compromising security.

My opinion? You probably don’t need more IT risk in your life. Stick with OpenSSH for your security needs. You will be in good company.

Patrick

The New York Department of Financial Services (NYDFS) surprised the financial services industry by fast tracking new cybersecurity regulations in September of 2016. Due to go into effect in January of 2017 with a one-year transition period, it takes a very prescriptive approach to cybersecurity which includes a mandate to encrypt data at rest. The financial sector is broadly defined as banks, insurance companies, consumer lenders, money transmitters, and others. The law is formally known as 23 NYCRR 500 and you can get it here.

There isn’t much wiggle room on the requirement for encrypting sensitive data. You can use compensating controls if you can show that encryption is “infeasible”. But I am not sure how you would show that. All modern database systems used by financial applications support encryption. It would be hard to imagine a financial database where encryption would not be feasible. Don’t plan on that being an excuse to delay encrypting data at rest!

The time frame is short for implementing the encryption mandate. One year seems like a long time, but it is extremely aggressive given the development backlog I see in most banks.

Here are some things you should start doing right now:

1) Inventory All of Your Financial Systems

This seems like a no-brainer, but you might be surprised how many organizations have no formal inventory of their IT systems that contain financial data. This is a top-of-the list item on any cybersecurity list of recommendations, so making or updating this list will have a lot of benefits.

2) Document Storage of All Sensitive Information (Non-Public Information, or NPI)

For each system in your inventory (see above) document every database and storage mechanism that stores NPI. For database systems identify all tables and columns that contain NPI. You will need this documentation to meet the NYDFS requirements, and it is a roadmap to meeting the encryption requirements.

3) Prioritize Your Encryption Projects

You won’t be able to do everything at once. Following all modern cybersecurity recommendations, prioritize the systems and applications that should be addressed using a risk model. Here are a few factors that can help you prioritize:

• Sensitivity of data
• Amount of data at risk
• Exposure risk of the systems and data
• Compliance risk
• Operational impact of loss

It is OK to be practical about how you prioritize the systems, but avoid assigning a high priority to a system because it might be easiest. It is better to tackle the biggest risks first.

4) Establish Encryption Standards

Be careful which encryption algorithms you use to protect sensitive data. In the event of a loss you won’t want to be using home-grown or non-standard encryption. Protect data at rest with NIST compliant, 256-bit AES encryption. This will give you the most defensible encryption strategy and is readily available in all major operating systems such as Windows, Linux, and IBM enterprise systems.

5) Establish Key Management Standards

Protecting encryption keys is the most important part of your encryption strategy and the one area where many organizations fail. Encryption keys should be stored away from the encrypted financial data in a security device specifically designed for this task. There are a number of commercial key management systems to choose from. Be sure your system is FIPS 140-2 compliant and implements the industry standard Key Management Interoperability Protocol (KMIP).

Hint: Don’t fall into the project-killing trap of trying to find a key management system that can meet every key management need you have in the organization. The industry just isn’t there yet. Pick a small number of key management vendors with best-of-breed solutions.

With encryption standards well defined and an encryption key management strategy in hand you are ready to get started with your encryption projects.

6) Analyze Performance and Operational Impacts

Encryption will naturally involve some performance and operational impacts. Encryption is a CPU intensive task, so plan on doing some performance analysis of your application in real-world scenarios. If you don’t have test environments that support this analysis, get started now to create them. They will be invaluable as you move forward. Modern encryption is highly optimized, and you can implement encryption without degrading the user experience. Just be prepared to do this analysis before you go live.

There are also operational impacts when you start encrypting data. Your backups may take a bit more storage and take longer to execute. So be sure to analyze this as a part of your proof-of-concept. Encrypted data does not compress as well as unencrypted data and this is the main cause of operational slow-downs. For most organizations this will not be a major impact, but be sure to test this before you deploy encryption.

8) Get Started

Oddly (to me at least) many organizations just fail to start their encryption projects even when they have done the initial planning. A lack of commitment by senior management, lack of IT resources, competing business objectives, and other barriers can delay a project. Don’t let your organization fall into this trap. Do your first project, get it into production, and analyze the project to determine how to do it better as you move forward.

Fortunately we have a lot of resources available to us today that were not available 10 years ago. Good encryption solutions are available and affordable for traditional on-premise environments, for VMware infrastructure, and for cloud applications.

You can meet the NYDFS requirements and timelines if you start now. But don’t put this one off.

Patrick

Resources:

New York Department of Financial Services:

https://www.dfs.ny.gov/legal/regulations/proposed/propdfs.htm

Harvard Law School analysis of NYDFS:

https://corpgov.law.harvard.edu/2016/09/24/nydfs-proposed-cybersecurity-regulation-for-financial-services-companies/

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."

Active monitoring (sometimes referred to as Continuous Monitoring) is a critical security control for all organizations. And it is one of the most effective security controls you can deploy. The large majority of security breaches occur on systems that have been compromised days, weeks, or even months before sensitive data is lost. A recent Verizon Data Breach Investigations Report1 indicates that a full 84 percent of all breaches were detected in system logs. This is why the Center for Internet Security includes active monitoring as a Critical Security Control (Control number 6).

There are several elements of a truly effective Active Monitoring strategy:

Central Collection and Repository of All Events
Attackers almost never start with your core IBM i server directly. They attack a web application or infect a user PC and work their way into the IBM i server. A defensible active monitoring strategy has to collect events from across the entire organization. By the time they show up on your IBM i server they have probably compromised a number of intermediate systems and an opportunity to prevent the breach has been missed. Collect all events across your entire IT infrastructure to gain the best early detection opportunities.

Real Time Event Collection
Data breaches are happening much faster than in the past. In some cases the loss of data happens just minutes after the initial breach. This means that you must collect security events in real time. Good active monitoring solutions are able to digest threat information
in real time and give you the chance to deter them. Avoid batch event collection – you can collect IBM i security audit journal information in real time and you should.

Event Correlation
Event correlation is key to an effect active monitoring solution. This is typically accomplished through the use of special software implemented in Security Information and Event Management (SIEM) solutions. Highly automated SIEM solutions have the ability to correlate events across a large number of systems and automatically identify potential problems. They do exactly what we want computer systems to do – handle large amounts of data and apply intelligent interpretation of the data.

Anomaly Detection
Anomaly detection is another aspect of active monitoring. That unusual system login at 3:00am on a Sunday morning would probably escape the attention of our human IT team members, but good active monitoring solutions can see that anomalous event and report on it.

Alerting and Resolution Management
When a problem is discovered we need to know about it as soon as possible. A good active monitoring solution will inform us through a variety of alerting channels. Emails, text, dashboards and other mechanisms can be deployed to bring attention to the problem - and we need to be able to track the resolution of the event! We are all processing too much information and it is easy to forget or misplace a problem. 

Forensic Tools
Forensic tools are critical to an active monitoring solution as they enable the rapid analysis of an attacker’s footprints in our system. The key tool is an effective and easy-to-use query application. Log data can include millions of events and be impossible to inspect without a good query tool. The ability to save queries and use them at a later time should also be a core feature of your forensic toolset.

IBM has done a good job of implementing security from the ground up on the IBM i platform. But that doesn’t mean that it is immune from data breaches. All of the PCs and servers on your network with the IBM i server are potential attack points for a data breach. And make no mistake, cyber criminals know that the IBM i server is a rich target. Implementing encryption in IBM i DB2 is an essential part of a defense in depth strategy. But there are lots of pitfalls to avoid. Let’s take a look at some of them (I am shamelessly plugging our Alliance AES/400 solution, too):

Locally Stored Encryption Keys and Key Management

One of the surest ways to defeat your encryption strategy is to store encryption keys on the same system that stores sensitive data. The IBM i server is no exception. Compliance regulations and security best practices require that you store encryption keys away from the IBM i server in an encryption key vault designed for this purpose. Why is this a security best practice? Cybercriminals are often able to achieve privilege escalation on a compromised IBM i server and then get access to locally stored keys. Storing encryption keys off of the IBM i server makes the compromise of the sensitive data much harder.

How Townsend Security Can Help

The Townsend Security Alliance AES/400 product integrates seamlessly with Townsend Security's Alliance Key Manager solution for protection of encryption keys and key management best practices. Alliance Key Manager stores encryption keys in a hardware security module or VMware instance that is attached to the IBM i server by a secure, authenticated TLS connection. As a FIPS 140-2 compliant key management solution, Alliance AES/400 with Alliance Key Manager solves the key management problem!

High Availability and Key Mirroring

Encryption key management is a part of your critical infrastructure. The loss of an encryption key means the loss of your data! Your encryption key management solution should implement real-time key mirroring and real-time security policy mirroring. In the event the key manager is unavailable due to a hardware or network failure, the failover to a secondary key server should be automatic without business interruption. A key management solution based on the IBM i master key facility cannot achieve real-time mirroring and protection from these failures.

How Townsend Security Can Help

Alliance Key Manager implements real-time key mirroring to one or more backup key servers. The mirroring implementation is active-active meaning that any changes you make to keys or access policies on the secondary server will be mirrored to the production server when it comes back online. This perfectly matches your IBM i high availability failover strategy if you use MIMIX, iTera, Vision, or IBM DataMirror.

Encryption and Insider Threats

Insider threats include both intentional and unintentional access to and loss of sensitive information. Unintentional losses of data represents the largest insider threat. Accidentally copying data to a PC or development environment can lead to a reportable data breach event. This is especially true when access controls to sensitive data are only controlled by native IBM i object level security. You should certainly use native IBM i security mechanisms, but access to decrypted sensitive data should also be controlled using a “whitelist” approach. This will help minimize the intentional and unintentional access by security administrators. Note that it is not only the security profile QSECOFR that has all access to sensitive data: all users with All Object (*ALLOBJ) authority or who adopt this level of authority through a group profile or supplemental group are at risk for intentional or unintentional loss of sensitive data.

How Townsend Security Can Help

Alliance AES/400 implements a whitelist approach for controlled access to decrypted sensitive data. All configuration changes to security policies are logged to the IBM security audit journal QAUDJRN. You can achieve effective Separation of Duties between managers of the encryption keys and security administrators on the IBM i platform.

Poorly Performing Encryption Libraries

Encryption can also present an operational risk to IBM i customers. In order to meet service level expectations of end users encryption and decryption operations must be efficient. Unfortunately for IBM i customers the native AES encryption software libraries provided in the operating system may not provide an adequate level of performance. Even with the new IBM i POWER8 servers with on-chip encryption, the performance of AES encryption and decryption tasks is poor. It is important to assess the size of your protected databases and the nature of batch operations that require access to unencrypted data in order to avoid negative impacts to both interactive and batch applications.

How Townsend Security Can Help

Alliance AES/400 uses the Townsend Security NIST-validated AES encryption library for encryption and decryption tasks. This optimized AES encryption library is more than 100x faster that native IBM i encryption libraries on POWER7 processors, and more than 50x faster on POWER8 processors.

Encrypted Indexes

Many IBM i customers are surprised to learn that their RPG applications will not work correctly with DB2 FieldProc for encrypted indexes (key fields). FieldProc is IBM’s automatic column level encryption feature implemented at the DB2 database level. FieldProc is attractive to IBM i customers because it does not require modifications to applications. While native SQL applications can easily handle encrypted indexes, RPG applications do not use the native SQL Query Engine (SQE) and will not work properly with encrypted indexes. Most IBM i customers exclusively use RPG or have a mix of RPG and SQL applications. The issue with RPG and encrypted indexes represents a major roadblock to encryption. Be sure that your encryption strategy can support encrypted indexes, or be prepared to modernize RPG applications to use native the SQL Query Engine.

How Townsend Security Can Help

Townsend Security tackled the problem of encrypted indexes and offers a solution to the RPG challenge through its Open Access for RPG SQL library. Changing one line of code in your RPG application can automatically use the native SQL Query Engine for database access. This eliminates the challenges of encrypted indexes with FieldProc encryption.

Data Masking

Compliance regulations such as PCI Data Security Standard (PCI-DSS) and security best practices require that we only allow authorized users access to fully decrypted sensitive data. But other users must have access to our database applications. This means that intelligent data masking should be built into your IBM i applications. As noted above, data masking should be based on a whitelist approach and not purely based on object or database level authority. You should have the ability to define masking rules (mask all but the last 4 characters, etc.) and you should be able to define a default masking rule that applies to all unauthorized users. While Row and Column Access Controls (RCAC) can provide some data masking capability, you must manage individual user level authorities to implement this control.

How Townsend Security Can Help

Alliance AES/400 fully implements data masking using a whitelist approach and provides protections from users with All Object (*ALLOBJ) or Security Administrator (*SECADM) privileges. Data is masked in the internal decryption routines and fully exposed data is never visible in the application program.

System Audit Logs

No security policy or solution can be effective on a stand-alone basis and this includes encryption and key management. A good encryption and key management strategy involves monitoring all access to sensitive data, monitoring changes to encryption and key management configurations, monitoring all use of encryption keys, and storing audit logs for future forensic reference. The use of Security Information and Event Management (SIEM) solutions is highly recommended as a part of your monitoring and alerting strategy. Be sure that all access to encryption and encryption keys is fully audited and logged.

How Townsend Security Can Help

Alliance AES/400 and Alliance Key Manager implement system logging and audit for all aspects of administration, configuration and use. Alliance Key Manager implements full logging of all aspects of key management and the server it runs on, and transmits logs to a SIEM solution in real time. Alliance AES/400 fully logs all administrative operations and decryption tasks to the IBM i security audit journal QAUDJRN. The optional Alliance LogAgent solution transmits these logs as well as all IBM i security events to a SIEM solution or log collection server.

Encryption and key management don’t have to feel dangerous or scary! I hope the above points about encryption and key management for the IBM i help you develop a roadmap for successful (and safe!) encryption.

Patrick

In case you missed it, IBM just released a security notification for the IBM i platform - all versions of the operating system from 6.1 through 7.3. This one is important and you should take a look at it right away. The vulnerabilities are related to OpenSSL and to OpenVPN which uses OpenSSL. The vulnerability is called the SWEET32 Birthday attack. OpenSSL is used in several places on the IBM i platform, so patching this should be a priority.

Here is the link to the description of the problem and a list of the PTFs that you need to apply for all currently supported platforms. Be sure to read it all the way through.

I recommend that you follow the guidance in this document to turn off Triple DES ciphers.

In addition to patching the IBM instances of OpenSSL and OpenVPN, IBM recommends that you contact your third party software vendors to determine if they have vulnerabilities.

Let me be pre-emptive here:

None of the Townsend Security solutions for the IBM i use the OpenSSL library for secure TLS sessions. Our solutions exclusively use the IBM i System TLS library. Why is that? Well, we ported OpenSSL to the IBM i platform more than 10 years ago. While we were successful with the port to the IBM i, I made a decision that we would not release it nor use it in our IBM i products. OpenSSL is a complex application with many moving parts. I agree with Bruce Schneier that complexity is the enemy of security. It is so easy to introduce a problem in a cryptographic library even if you work in this area a great deal. I felt then, and I feel now, that the maintenance and support of the TLS library should remain with IBM and that the native IBM i System TLS library is the best platform for us and our customers. I believe that this was a good decision then, and remains a good decision now. It has protected our customers from a number of security problems.

Our Managed FTP solution does use the OpenSSH solution for secure FTP sessions. OpenSSH uses the OpenSSL solution for cryptographic operations, but not for secure session establishment and it is not subject to this vulnerability. We use the IBM OpenSSH distribution and not our own port of OpenSSH for the very same reason as above.

I am NOT criticizing the OpenSSL development team. I’ve worked directly with the OpenSSL team over the years and have deep respect for them. They have a gargantuan task in maintaining one of the most widely used secure communications products in the world. Security programming will humble you and, if you are lucky, it will make you risk averse. On the IBM i platform we chose to use the IBM i System TLS library and I still think that was a wise decision.

There are multiple third-party IBM i products that do use their own version of OpenSSL. You need to be talking to them right away. Unfortunately I know of one or two that are no longer supporting the IBM i platform. So you may have some difficulty getting resolution on this issue. I wish you luck in this endeavor!

If you are interested you can read about the SWEET32 attack here.

If you are one of our IBM i customers I recommend that you sign up for our newsletter. If you’ve opted out in the past you might not be getting security notifications from us. When you opt out we honor that request and won’t opt you back in. You have to do that here. 

Patrick

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."

   PRTUSRPRF TYPE(*AUTINFO)
   SPCAUT(*ALL)

   CHGUSRAUD USRPRF(QSECOFR)
   OBJAUD(*ALL) AUDLVL(*AUTFAIL *CMD
   *PGMADP *NETCMN *PGMFAIL)

   CHGOBJAUD OBJ(PRODLIB/ORD001)
   OBJTYPE(*PGM) OBJAUD(*ALL)

   CHGAUD OBJ(‘/mydirectory’)
   OBJAUD(*ALL) SUBTREE(*ALL)
   SYMLNK(*YES)

I’ve been spending some time digesting the proposed State of New York financial regulations that are due to go into effect in the new year. The new regulations are fairly prescriptive which has its good and bad points. But it is very clear that the regulators have had it with “opt out” security controls for banks. One of the areas of focus is on the role of the Chief Information Security Officer, or CISO. Let’s take a closer look at what the new regulation says about the CISO and what it means to your financial organization.

First, you have to have one of these.

Larger national and global institutions already have someone filling the CISO role. This won’t be anything new for them. The CISO is responsible for the overall security policy and practices of their organization. I think this will be a larger challenge for smaller regional banks and credit unions. Much of their IT infrastructure is probably outsourced and they depend on a network of vendors and service providers to fill their security needs. So these folks are going to have to on-board someone to fill the CISO role. And the experienced CISO is in hot demand. Hiring a qualified individual will be a challenge.

See below for a suggestion on how you can tackle this problem with a virtual CISO.

Second, the CISO now has to report to the board of directors or the equivalent level in your organization at least twice a year. And the report has to include a fair amount of detail on the security posture of the organization! This is going to be a major shift in almost every financial institution, and is probably a big shock for many! Currently the CISO typically reports to the CEO or similar level of executive management. It is going to be an uncomfortable change for the CEO to let go of this direct report and have unfiltered information going straight to the board of directors.

Why did the State of New York demand this change? I am just guessing here, but way too often I’ve seen the recommendations of a CISO stifled at the CEO level. Business line managers have a hard time understanding the relative importance of investing in security when there are so many demands for resources. Line of business needs often pre-empt security needs. For this reason many large companies are failing to invest in the way they should. I think the State of New York decided that the CISO needs to provide information directly to the board to improve governance, risk management, and compliance. Yeah, that GRC thing.

Lastly, too many financial institutions treat security as a checkbox item, rather than as an ongoing adaptive process. Without a level of seriousness about cyber security in the organization the right things are not prioritized and security investments aren’t made. Making sure that a qualified security professional is in the driver’s seat should help financial institutions become more secure, and thus the data of their customers better protected. A CISO can push this agenda forward.

Smaller institutions will certainly have some difficulty in acquiring the talent needed to meet the CISO role. I suggest that you consider a Virtual CISO (yes, that is a thing) to fill this need for the short or long term. The timelines for the new regulation are very short and you will have to meet some requirements within six months and all of them within one year. That is a very short timeframe for any financial institution.

Here are just a few suggestions:

If you are an IBM i (AS/400, iSeries) shop, look to an expert on this platform to help you. One that I work with on a regular basis is Botz and Associates. I’ve worked with Patrick Botz for many years and he is a long-time advocate for approaching security as a business process, just as this regulation mandates. He was the head of security for the IBM i platform for many years and can help you with his new Virtual CISO service.

Another security firm that I’ve worked with is Coalfire. I’ve always been impressed with their ability to really understand our needs and become that trusted advisor that you need. They also have a Virtual CISO service to help you meet the new regulations, and you get a good security friend in the process.

Here is where you can find the proposed State of New York regulations, it is a pretty easy read.

Financial institutions and their service providers have a big challenge ahead and very tight deadlines. Time to get cracking!

Patrick

New York State has finally had enough. Most people think that their bank has strong encryption in place to protect them from cyber criminals and nation-state actors. But that is too often just not the case. After a number of high profile data breaches at larger financial institutions, and a worrying increase in attacks on banks, the State of New York is about to require that banks implement some stringent security controls to protect Non-Public Information (NPI). The  new regulations are not a difficult read and you can find the proposed new regulations here.

Let’s take a look at some of the new requirements.

First, banks are required to develop a cyber security program. This means that there must be formal security processes in place, and appropriate management oversight. Banks are required to have systems and processes to identify threats, respond to them, and recover from an attack. The regulation also requires appropriate reporting of security events, something that is not always honored in today’s environment.

Next, banks are required to have a Cybersecurity Policy that addresses a number of areas related to information security, incident response, access controls, data privacy and other areas. If you are familiar with the Center for Internet Security Critical Security Controls or the NIST Cybersecurity Framework, these points will be familiar to you. As you might expect, a premium is placed on ongoing adaptive responses to new threats, so these frameworks are not a check-box response to the problem. Banks are being asked to step up to a new level of seriousness around IT security.

You also need a Chief Information Security Officer (CISO) position designated in your organization. And, interestingly, the CISO is required to report to the board of directors of the bank. I find this requirement interesting as it means that boards of directors cannot remain ignorant about the state of the bank’s IT security. And this means that it will have to become a part of the governance process of the board.

The new regulations now get down into the weeds about what you should be doing. Here are some of the areas:

• Vulnerability and Penetration testing
• Collect and archive system logs
• Implement restricted access controls
• Conduct risk assessments at least annually
• Hire cybersecurity professionals and make sure they stay current on new threats
• Require third parties to adhere to the same security rules as the bank
• Use multi-factor authentication for internal and external access to NPI
• Train and monitor all personnel with access to NPI (SIEM, anyone?)
• Encrypt NPI
• Develop and incident response plan

The requirement to deploy encryption is surprisingly strong. It is a mandate unless deploying encryption is unfeasible. Given the wide availability of encryption in all major operating systems and databases, I believe it will be difficult for a CISO to argue against the use of encryption. Clearly the regulators want banks to encrypt sensitive NPI data.

Who does the new rule affect?

The new rule affects any financial institution that is regulated by the New York Department of Financial Services. This will affect all national and global banking organizations as New York is one of the leading centers of global finance. It may also affect regional banks through the extension of the rules to affiliates. Regional and local banks should review their relationships with larger banks to try to understand their requirements under these new laws.

When does the new rules take effect?

The new rules take effect on January 1, 2017. In terms of time, that is very soon! And there is only a 180 day transition period. CISOs can request an extension, but these controls must be in place by January of 2018. That is a very aggressive timeframe!

How is the IBM i (AS/400, iSeries) affected?

Almost all large banks and financial institutions use the IBM i server somewhere in their organizations. The IBM i server is perfect for the back office applications that banks run and which need a very high level of availability. Many of the largest third party banking applications are deployed on IBM i servers.

But banks are going to face a big challenge with IBM i DB2 database encryption. The Non-Public Information that must be protected is often used for indexes in the DB2 database. While IBM DB2 supports column level encryption, it won’t work well RPG programs that use encrypted indexes. Here at Townsend Security we have a fix for this problem! By implementing an OAR-based SQL interface for RPG files we are removing the impediment that banks face with encryption on the IBM i server. You can read more here.

Patrick

IBM i (AS/400, iSeries) customers now know that their systems are no more secure than any other. That is, they are just as much a target as any Windows or Linux server that exist in less secure network environments. This is not a criticism of the IBM i security implementation, it just reflects the fact that our IBM i servers are connected to a wide range of other devices including user PCs, network devices, local and WAN networks, and so forth. The attack surface is broad, IBM i servers are a rich target for data thieves, and we are all just one user PC infection away from an IBM i server data breach.

A lot of IBM i customers postpone deploying a system logging and SIEM solution to actively monitor for security threats, even though this is one of the most effective means of detecting and preventing a data breach. There is a reason that the Center for Internet Security recommends system log collection and monitoring with a SIEM solution as the 6th Critical Security Control. It just works really well when done properly.

I suspect that cost is one of the reasons that projects are postponed. This reasoning is “penny wise and pound foolish”. Here’s why:

• There are now very cost effective log collection and SIEM monitoring solutions available for the smaller Enterprise. Some of these solutions are cloud-based and some can be deployed in VMware infrastructure. Cost is not as big an issue as it has been.

• The failure to collect system logs means that it will be difficult to do the forensic investigation that you must do after a data breach. Imagine a costly data breach and then imagine not being able to figure out how the data thieves entered your system! All too often this means that a second and third data breach happens after the first. Without collecting system logs you won’t be able to deploy the forensics tools to trace the path of the cyber criminal through your organization. Another data breach is almost a certainty.

• Early detection is one of the most effective means of preventing the data breach. This means large savings on outside security consultants, litigation costs, and the deployment of log collection and monitoring tools at inconvenient times. Early detection is a life-saver for those who can prevent a breach.

• Log collection and SIEM monitoring solutions are easier to deploy than ever. While deploying an active monitoring system was complex and costly in the past, many SIEM solutions can be deployed and start working to protect your organization is just a matter of hours. Unlike in years past when SIEM solutions took weeks to install, configure and deploy, many are now extremely easy to setup and administer.

From a Governance, Risk Management and Compliance point of view deploying the CIS Critical Security Controls is a minimum requirement. Here is what the California Department of Justice said in this year’s data breach report under “Recommendations”:

“The 20 controls in the Center for Internet Security’s Critical Security Controls identify a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.”

Every senior executive in the modern organization understands that canceling the fire insurance policy on their headquarters building would be a bad idea. You would be one fire away from the end of your career. The same now holds true for IT security. Shareholders and the board of directors now understand that the failure to use reasonable measures to protect data assets is a fundamental failure of governance. Don’t be the executive who has to try to defend that failure!

Patrick

OpenSSL is one of the most widely used cryptographic applications and libraries. A new group of security vulnerabilities have just been identified for OpenSSL and they need attention right away. IBM i (AS/400, iSeries) customers often feel isolated and protected from the security issues with OpenSSL, but this attitude can lead to trouble. IBM i customers need to monitor for vulnerabilities in OpenSSL and patch their IBM and third-party applications.

IBM uses the OpenSSL application in the Hardware Management Console, or HMC. The HMC is a highly privileged application that can manage many instances of IBM i logical partitions in a customer environment. You should carefully monitor security patches from IBM and apply them to your HMC. You can find IBM’s security alerts and notifications here.

On the IBM i platform itself you should be aware that the PASE environment includes the OpenSSL application. The PASE environment is an AIX emulation environment that is usually present on IBM i customer systems. Since PASE is an IBM licensed program you should apply Program Temporary Fixes (PTFs) to resolve issues with OpenSSL in PASE.

The IBM i no-charge OpenSSH licensed program also contains the OpenSSH application. However, the OpenSSH application does not use OpenSSL for session security. The primary use of OpenSSL in the OpenSSH application is for cryptographic functions. While this reduces the security threat, it does not eliminate it. You should update OpenSSH when they are PTF patches available.

The OpenSSL application is also found in the Linux-like environment of the QSHELL application in later versions of the IBM i operating system. If you use the Start QShell (STRQSH) command you can use the “type openssl” command to determine where it is located. You can view the version of OpenSSL with this command: “openssl version”. As in the above examples, be sure you apply PTFs when there are security notices for OpenSSL.

Lastly there are a number of third-party applications that embed the OpenSSL application. If these third-party applications are not using the IBM-provided OpenSSL libraries, you will need to contact those third party software providers to receive an update. Be sure you carefully review any third party application, open source application or free tool for the presence of OpenSSL. Any application that performs FTP data transfers, implements an inbound or outbound web service, or  communicates with an encryption key management server should be reviewed (see below for a statement about IBM i solutions from Townsend Security).

Here at Townsend Security we have several IBM i security applications that perform secure encrypted TLS connections. None of these applications use the OpenSSL application. Instead we use the native IBM i GSKit library for TLS session security which is configured using the IBM no-charge licensed Digital Certificate Manager (DCM) product. Our Alliance FTP Manager, Alliance AES/400 FieldProc encryption, Alliance Token Manager, Alliance Two Factor Authentication, and Alliance XML/400 solutions are not subject to the OpenSSL security vulnerabilities. Note that our Alliance FTP Manager solution uses the IBM OpenSSH application, so as mentioned above be sure to apply those OpenSSH security updates from IBM if you are using OpenSSH for transfers.

In addition to signing up for IBM i security alerts at the above web site, you can subscribe to US-CERT notifications here.

Hat tip to Alex Woodie for his article on IBM i OpenSSL vulnerabilities. You can find it here.

Patrick