Don’t Overlook These Network Auditing Improvements in IBM i 7.3
October 24, 2016 Alex Woodie
|
What is going across those network cables connecting your IBM i server to the outside world? It’s not always easy to tell, and IBM hasn’t exactly made it easy. But thanks to new security event types and exit points released earlier this year in IBM i 7.3, you can get deeper visibility into network traffic and make your company’s SIEM system work better with your IBM i along the way. The focus over the past few weeks has been on IBM i 7.3 Technology Refresh 1 and IBM i 7.2 TR5. There is a lot of good stuff in there, to be sure. But it is worth shining the light a bit on a past security enhancements that didn’t get the attention they deserved. This is critical stuff–the lack of visibility into network activity before IBM i 7.3 is, frankly, a little bit scary. Specifically, IBM added several new security event types and exit points with IBM i 7.3 to boost network auditing. The improvements enable all sockets-based UDP and TCP traffic in and out of the system–including traffic that is encrypted–to be tracked and audited through the security audit journal (QAUDJRN). This is significant, because itis the first time this level of visibility has been brought to network connections that use sockets. While IBM has supported auditing of TCP sockets connections, there were significant gaps in the coverage. IBM now has you covered for all TCP and UDP sockets-based connections with the NETSCK and NETUDP event types with IBM i 7.3. You can audit all UDP and TCP sockets-based traffic (except for Telnet traffic over TCP; more on that later) by enabling *NETSCK and *NETUDP audit levels on your server. When you these turn on, IBM i will begin collecting valuable information about the UDP and TCP connections through QAUDJRN. The entries will include critical information about the flow of traffic across the network, including the local IP address and port and the remote IP address and port (as well as whether it’s an IPv4 or IPv6 connection). IBM also unveiled a new *NETTELSVR value to monitor Telnet traffic over TCP. “Previously, the Telnet server was specifically not audited with TCP sockets connections because the quick reconnect rates of some Telnet clients could result in a high number of audit records on a system,” IBM’s Dawn May writes in a very informative July 2016 posting to her “i Can” blog on the new auditing capabilities in IBM i 7.3.
Considering the potential harm that a hacker or disgruntled employee could do with a TN5250 connection into an IBM i server, and the lack of audit coverage in the IBM i system prior to IBM i 7.3, it’s great that this has finally been addressed. But wait, there’s more! Also in IBM i 7.3, IBM added the *NETSECURE audit level to audit (supposedly) secure network traffic using Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption protocols. (We say supposedly because even TLS, which was supposed to be more secure than the SSL protocol its replacing, is having its own share of security problems.) This feature will tell you what security protocols and cipher suites are being used on your system. It will also tell you about successful and unsuccessful attempts to create encrypted connections that utilized VPN Internment Key Exchange (IKE) negotiations, successful IP Security (IPSec) connections, and secure UDP traffic. It is great to have all this information about TCP and UDP connections into your IBM i server, including the ones protected with SSL/TLS encryption. But making sense of the QAUDJRN is a daunting task. Larger IBM i shops will almost certainly need some sort of power tool to chew through the log data to find the anomalies. For these customers a security information and event management (SIEM) solution will be warranted. In a recent podcast, Townsend Security CEO Patrick Townsend talked about the new QAUDJRN event types and exit points that debuted in IBM i 7.3, which are supported with the Townsend Alliance Log Agent.
“Remember that almost all SIEM solutions that help you identify threats really look at the IP address of the source, both inbound and outbound, from the IBM i platform,” Townsend says. “So enabling these new event types is critically important, I think. You need to be collecting that information and forwarding it to a SIEM solution.” Products like the Alliance Log Agent can automatically convert QAUDJRN records into industry standard SYSLOG format used by many SIEMs. It also supports the extended log format standards used by SIEMs like HPE‘s ArcSight and IBM’s own QRadar. IBM i shops that feed the network traffic data into a SIEM solution will stand a better chance of identifying anomalous traffic that’s associated with a security breach, Townsend says. This is a critical capability to have, considering that 84 percent of security breaches are detected after the fact through analysis of logs, according to the recent Verizon 2016 Data Breach Investigation Report (pdf). But SIEMs, when properly fed with historical data, should also be able to identify new attacks as they occur, and provide real-time threat protection (at least theoretically). In light of the recent hacking incidents involving WikiLeaks, the Democratic National Party, and U.S. Government accusations of state-sponsored hacking in Russia–not to mention the ongoing barrage of security vulnerabilities in encryption protocols and cipher suites used in IBM i and nearly every other system in the world with names like Heartbleed, Sloth, Bar Mitzvah, and Drown–perhaps it’s worth taking a fresh look at the new network auditing functions that IBM delivered earlier this year. You can hear Townsend’s complete podcast at player.fm/series/security-insider-podcast-edition/ibm-i-73-security-new-logs-to-collect-and-monitor. RELATED STORIES IBM i 7.3: High Time For High Security Verizon Outlines Disturbing AS/400 Breach At Water District IBM Patches Pair Of TLS Flaws In IBM i IBM Patches More OpenSSL Flaws In IBM i IBM Blocks ‘Bar Mitzvah’ Attack In SSL/TLS
|
