Townsend Security Data Privacy Blog

Alliance LogAgent is a product designed with the intent of reading your security audit journal event entries, then formatting and forwarding those events to any SIEM or LEM device, but LogAgent provides several significant features and functions that you may not be aware of.   In this article I will discuss five of these highly valuable features of the Alliance LogAgent product that you may not know about.

1. Exclude trusted users to reduce volume. In addition to allowing system administrators to filter out various event types from reporting, Alliance LogAgent will also allow you to filter out all events created by specified user profiles through the use of an “Excluded Users” list.  System admins may occasionally find it necessary to filter out all audit events created by implicitly trusted system user profiles.  Alliance LogAgent allows you to configure this ability at the IBM i level so that you can block those events from reaching your SIEM, thus reducing the volume of events that the SIEM must filter from reports.
2. Secure communications between agent and SIEM. While most SIEM solutions provide support for TCP and/or UDP connections to agents, Alliance LogAgent also supports the use of SSL/TLS secure connection for customers who need to protect the privacy of the communications between the agent and the SIEM.  With the simple addition of certificates to the IBM i Digital Certificate Manager and configuration of an Application ID tied to the certificate, Alliance LogAgent can be quickly configured to use SSL/TLS communications to protect your communications with the SIEM.
3. Exit Point monitoring. In the IBM i environment many IBM applications provide Exit Points that can be used to trigger flags for reporting or launching other processes.  Alliance LogAgent has the ability to monitor these Exit Points and create audit events that get reported to the SIEM so that system administrators can use the SIEM to monitor many of those functions.  Providing Exit Point monitoring within Alliance LogAgent allows the SIEM to provide administrators with valuable reporting of the use of many of these systems within the IBM i.
4. File Integrity Monitoring. File integrity monitoring is recommended under PCI DSS and other regulations.  Even in other environments it is often highly desirable to be able to verify and monitor the integrity of data within database files.  Alliance LogAgent has an add-on module that provides this highly valuable File Integrity Monitoring (FIM) function.  Database Monitor allows the admin to determine which files and which fields within those files need to monitored for access and integrity.  Database Monitor will record the original field data and also the new values recorded in the field, as well as application and user information for how and when the data was changed.  This integrity monitoring allows you to also set alerts to administrators if unauthorized users, or applications alter data, or if data changes violate configurable thresholds. 
5. Simplified formatting for event reporting. In the world of event management there are many possible SIEM and LEM systems and services available.  Some of these SIEM and LEM systems use Common Event Format (CEF) for handling event data, while others use the Syslog (RFC3164) format.  Alliance LogAgent provides configuration options to support either of these two formats and is compatible with a wide range of SIEM and LEM devices and services without any need for additional IBM i support or programming.  Simply select a couple of collector and formatting options in the product configuration panels, specify the destination address of the SIEM device, and start the system.  You can begin seeing your IBM i audit events at the SIEM in a matter of minutes from initial installation of the product.

With the importance of event monitoring becoming more critical for system administrators, it is important to choose a logging solution that will meet your needs.  Alliance LogAgent’s wide range of features, combined with the ease of setup and configuration, allows system administrators great flexibility while still allowing for rapid deployment with nearly zero impact on daily operations. 

In the world of PGP encryption, we often hear from users who tell us, “My trading partner says they need my private key for encryption. Is it ok to send it to them?” The simple answer to this question is no. Your private key is aptly named “private” because it should never be shared with others. The key intended for distribution is also aptly named as the “public” key.

The longer and more technical explanation of why you shouldn’t give out your private key is a little more confusing.

The PGP process requires that encryption be performed with a public key that your trading partner gives to you to use, if you are going to send encrypted data to them. You cannot encrypt the data with a private key. If your partner requires that the file be signed as a part of the process, then you will use your private key as a signature. In order to read that signature you must give your trading partner your matching public key to your private key. You should never give them your private key.

On the other hand, if someone wishes to send encrypted data to you, you must provide them with your public key in order for them to send you files. Your system should automatically recognize the key that was used to encrypt the file and will select the appropriate private key for the decryption process. You only need to provide the passphrase for the key to validate that you are authorized to the unencrypted data.

Here’s an example: XYZ Productions uses the services of ABC Personnel Services for payroll management. Each month YXZ sends payroll files to ABC for processing. Due to the confidential nature of the information in the file, XYZ and ABC have agreed to use PGP encryption to protect the data. Both companies export their public keys and send them to one another. As the originator of the file, XYZ uses the ABC public key to encrypt the file before sending it.  By doing so, the file can only be decrypted by the holder of the private key. XYZ then uses their private key to sign the file as a means of verifying the origin of the encrypted file. When the file is received by ABC, they validate the signature by comparing it to the XYC public key they have been given, then use their private key to decrypt the file for processing.

The safety of the confidential data in the example is protected because the encrypted files can only be read using the private key, which has never left the trust of the key generator.      

Remember, when exporting a key to send to a customer, one should always remember that the key type identifies if the key should be shared. Public keys are for sharing; whereas a private key should always be kept close to home.