Many compliance regulations such as PCI-DSS and HIPAA require that data be completely hidden or partially masked for all users who are not authorized to see the data. When IBM i (AS/400, iSeries) customers implement DB2 Field Procedure (FieldProc) encryption, how do they implement data masking at the same time? In this blog I want to talk about general principles of data masking, how IBM DB2 FieldProc applications can implement data masking, and some limitations that you need to know.
Data Masking and the FieldProc Architecture
There is no direct facility provided by IBM in the DB2 FieldProc architecture to implement data masking for you. This means that your FieldProc application must implement this for you. FieldProc applications are written by you or provided by your vendor (see below for information about the Townsend Security solution). Since data masking is designed to protect sensitive data in the clear, this means that data masking should be implemented in the decryption logic. When a row is read from a database table the FieldProc application is called by DB2 to perform decryption. At that point the determination must be made on whether the user is allowed to see the entire column value in the clear, whether it should be partially masked, or whether it should be fully masked.
Data Masking Security Architecture
One of the core security principles of data masking is that it should be based on user whitelists and not on user object authority. This is not an intuitive idea for most IBM i system administrators because so much of IBM i security is based on file object level authorities. So why would data masking not rely on object authority?
One of the main efforts of a cyber criminal upon gaining access to your system to escalate their privilege level in order to access sensitive data and achieve the ability to manipulate system configurations. On the IBM i platform the attacker will try to gain security administrator privilege or All Object (*ALLOBJ) authority. If your data masking strategy is based on object authority it is immediately defeated when the attacker gains greater privilege. This is why data masking should be based on a whitelist approach and not on native object authorities, and why we took this approach in our Alliance AES/400 FieldProc implementation.
Users and Groups
Like many other operating systems the IBM i provides for user groups. On the IBM i platform user groups are defined by a Group Profile, and individual users can belong to this group or it can be included in their supplemental group. Group profiles are a convenient way for IBM i security administrators to define authority rights for anyone in the group and not have to define these rights for each individual user. If you are a user you inherit the rights to the groups you belong to. A data masking implementation should incorporate user groups into its implementation through a whitelist approach.
Data Masking Options
Data masking options should allow for masking of an entire field, or just a portion of the field. The PCI Data Security Standard (PCI DSS) is probably most clear on data masking requirements for compliance. Only authorized users (defined by PCI as “personnel with a legitimate business need can see the full PAN”) should see an entire field unmasked and all others should see only a portion of the field (The first six and/or last four digits) or the field should be fully masked. When establishing your whitelist of users you should be able to define the data masking options at the same time as you define the user or the group.
Data Masking for Numeric Fields
On the IBM i platform we have a challenge when it comes to masking numeric fields. Numeric fields can only contain a numeric digit and can’t contain an asterisk or other typical masking character. For numeric fields you must determine a masking pattern that can’t naturally occur in the data. Perhaps you could choose a masking option that filled a numeric field with all 9’s. This would work if the field could not naturally contain all 9’s. An example might be a salary field. If you have a 9.2 zoned numeric field it is unlikely that anyone would have a salary equal to $9,999,999.99 and masking with all 9’s would work. Just be aware that masking numeric fields requires some forethought and planning.
Limitations and Gotchas
Data masking with FieldProc encryption is generally very effective and easy to do. But there are a few limitations. Consider a program that reads data from table A and uses a column value to read a record from table B. And assume that the value read from table A is encrypted. If a user can only see masked data, the data will be masked when read from table A and the lookup on table B will fail. This is a subtle limitation but it has occurred in the real world!
Data masking is a powerful additional security control for your FieldProc applications. If you are aware of the limitations it is a great tool to help you get better security for your IBM i databases and applications.
IBM i FieldProc encryption by Townsend Security
Townsend Security provides a full IBM DB2 FieldProc solution for the IBM i server platform with Alliance AES/400. In addition to strong 256-bit AES encryption, it provides IBM i customers with flexible data masking options on decryption. It has full support for individual and group profiles, and the security administrator can specify a default masking rule to apply to any users not explicitly allowed to see unmasked or partially masked data.
IBM i (AS/400, iSeries) customers have a great automatic encryption option with DB2 Field Procedures, or “FieldProc”. As with any encryption facility, users always have questions and concerns about performance. Performance impacts extend beyond just the impact of encryption itself, so let’s look at various aspects of performance when it comes to IBM i FieldProc.
IBM FieldProc Architecture
One of the largest impacts on performance comes from the actual architecture of FieldProc itself. IBM DB2 FieldProc is basically implemented as an event-driven exit point at the column level. What this means is that any insert, read, or update operation will trigger a dynamic program call to the FieldProc application program to perform encryption or decryption. There is definitely a performance penalty for this architecture. An application program that reads a large database on a modern IBM i server may be able to process hundreds of thousands of records per second. With FieldProc, that may be reduced to tens of thousands of records per second as the FieldProc program is invoked for each row in the table. You can still get good performance with FieldProc enabled (read on), but there will be an impact.
FieldProc Program Performance and Optimization
A FieldProc program is just an application program that you create or that your encryption vendor provides to you, so it can have its own performance issues. How much file I/O does the FieldProc program perform for each encryption or decryption task? How optimized is the application code? How optimized is the compilation of the program? Does the program perform any caching of internal information to improve performance? Like any program on any platform or operating system, a FieldProc program may perform well or not.
Surprisingly, there can be really big differences in the performance of encryption libraries even when doing the same type of encryption. You might think that 256-bit AES would have the same performance regardless of the vendor. And you would be really wrong about that. On the IBM i server platform I’ve seen a difference of more than 100 times between two different 256-bit AES encryption libraries. To put this in a practical context, this is the difference between 10 hours of batch processing versus 5 minutes of batch processing. That’s pretty dramatic. Encryption libraries can be optimized and should be optimized for performance. That is not always the case.
Number of Columns Under Encryption Control
The number of columns in a table will affect the performance of your FieldProc implementation. If you have three columns in a table under FieldProc control you will definitely see an impact on performance compared to a single column. Each read of a row in the table will result in three separate calls to a FieldProc program to perform decryption. This is not a linear impact on performance. That is, you won’t see an impact on the order of three times the impact of one column under FieldProc control. But there is a gradual impact as you add columns in the table. By the way, FieldProc will be called for each column even if your application does not use the column.
Encryption Key Management
Using encryption means using encryption keys. Assuming that you are not using a poor security practice such as storing the key on the same server as the encrypted data, the interface to your key management server represents another potential performance impact. How keys are retrieved and prepared for use by the encryption software can represent a hidden drag on performance. While a single key retrieval from a key server may take just a few milliseconds, the performance impact can be dramatic when thousands or millions of key retrievals are needed from a key server.
Encryption Key Caching
Because encryption key retrieval can slow the overall encryption process, it is important that a FieldProc application use secure key caching logic to minimize the number of key retrieval operations. If your nightly processing retrieves 10 million records for reporting, you definitely don’t want to retrieve encryption keys 10 million times. A good FieldProc implementation should securely cache encryption keys. This means that keys should not be exposed in program dumps or debug mode of operation.
IBM i servers vary a great deal in CPU performance and the number of processors that are available to applications. Entry level servers may have a single processor that is shared between multiple partitions. High end IBM i servers can have a large number of processors and rival Mainframes in raw processing power. This will definitely have an impact on encryption performance. The number of processors is less important than the power of each processor. It sometimes surprises IBM i customers that adding a processor to a system might have minimal impact on encryption performance. But upgrading to a faster processor can make a big difference. Also, more modern IBM i servers have very powerful POWER7 and POWER8 chips and these will help with encryption performance.
POWER8 On-Board Encryption
The new IBM POWER8 systems now have built-in support for AES encryption. This is similar to the Intel AES-NI implementation. While this does provide some improvement in encryption performance, it won’t be as much as you might expect. The built-in chip support for AES encryption seems to be optimized for encrypting very large chunks of data at one time. If you are encrypting a credit card number of social security number, you won’t see a really dramatic improvement in performance. IBM i customers using ASP encryption should really benefit from the built-in encryption. In some cases such as with Townsend Security's Alliance AES/400 encryption for IBM i, the software implementation provides big performance advantages over the on-chip POWER8 implementation.
Native SQL Applications
As most IBM i customers know, IBM has been on a tear to improve SQL in DB2 for some time. We’ve seen increasingly better performance of SQL applications over time. In the current release of the IBM i operating system and DB2 database the performance of SQL is impressive. Because SQL performs better, you will see better performance when implementing FieldProc in native SQL applications. Of course, you don’t need to convert your databases from DDS to DDL/SQL to use FieldProc, but if you do you will see better overall performance.
IBM i Navigator and SQL Plan Cache
When discussing database performance it is always important to mention the IBM i Navigator SQL Plan Cache function. This application comes with every IBM i server and is always available. It can show you how well your DB2 applications are performing, and can even recommend steps you can take to improve performance! When using FieldProc it can be a very helpful tool.
More about Townsend Security’s AES/400 FieldProc Solution for IBM i DB2
The Townsend Security solution for FieldProc encryption is called Alliance AES/400. It is the fastest performing FieldProc solution in the market and implements all of the FieldProc recommendations above.
Each new release of the IBM i (iSeries, AS/400) operating system brings the likelihood that IBM has added new security events to the security audit journal QAUDJRN. Version 7 Release 2 (V7R2) of the IBM i operating system was no different. There are four new security event types collected in the security audit journal. Let’s take a look at these new events:
PTF Operations (event type PF)
This new event type records significant Program Temporary Fix (PTF) operations. This includes operations like loading a PTF, applying a PTF, removing a PTF, PTF superseded, and other PTF operations. It also includes operations on licensed products. Saving, restoring, deleting, and installing licensed programs are included in this group. Because of the potential impact on on-going operations of your IBM i server by PTF activity you should monitor these types of events and forward them to your SIEM solution.
PTF Object Change (event type PU)
This event records changes to objects that occur due to PTF operations. These events are created when PTFs are applied or removed, and the event will tell you if the PTF object is new or changed. PTF objects can be database files, programs, IFS files and many other types of objects. Because of the potential impact on on-going operations of your IBM i server when PTFs are applied or removed you should monitor these types of events and forward them to your SIEM solution.
Row and Column Access Control (event type AX)
Row and Column Access Controls are new in V7R2 and provide significant new security features for IBM DB2 for IBM i. Users can now control access to DB2 information at both a row and column level. This new AX event records changes to column masks and row permissions including changes, additions, and removal of RCAC controls. Because row and column access controls are a part of your normal security strategy, you should monitor these changes with your SIEM solution.
Query Manager Profile Changes (event type X2)
This new security audit journal event type records changes to Query Manager profiles. The implementation of the event represents a radical departure from the decades-long definition of security audit journal types as it does not have a normal description file in library QSYS, and it does not have the typical format for security audit journal entries. You must use SQL and special steps to instantiate the information and monitor it correctly. Query manager profile changes can affect user rights to sensitive data and so should be monitored by your SIEM solution.
These are the new IBM security event types that were added to the QAUDJRN security journal in IBM i V7R2. You will want to be sure your IBM i system logging solution addresses these events and that your SIEM solution is monitoring them appropriately. Alliance LogAgent supports these events in the latest version which you can download through the normal update process.
This is a guest blog by Nick Trenc, CISSP, QSA, PA-QSA, VCP. Nick is an IT Security Architect at Coalfire Labs.
In any environment where potentially sensitive data is stored using Microsoft’s SQL Server, one of the key issues is how to best protect that data. Microsoft SQL Server does offer several security controls natively, but almost all of them require some sort of extensive configuration and management in order to be done according to security best practices. Additionally, SQL Server’s own security controls do face some shortcomings.
If using SQL Server’s own encryption tools, database encryption keys are stored right next to the data they are used to protect. This makes it easier for would be malicious users to capture both the protected data and the keys used to protect that data.
This is where Townsend Security’s Alliance Key Manager (AKM) comes in to play. Utilizing the built-in SQL support, IT administrators can generate, store, and manage keys within AKM away from the data those keys are used to protect. This enables separation of duties and dual control which are both best practices and requirements of several compliance frameworks.
Alliance Key Manager utilizes the Extensible Key Management (EKM) functionality of SQL Server (Enterprise Edition 2008 and newer) to centrally manage encryption keys. In addition, AKM also includes native support for SQL Server Transparent Data Encryption (TDE) which can be used to encrypt all of the tables within SQL Server. Finally, AKM includes support for SQL Server Cell Level Encryption (sometimes called Column Level Encryption), integrates directly with the Windows Certificate store, and includes features for key caching and mirroring for high availability.
For more information on using AKM to specifically meet PCI DSS compliance within a virtual environment (but also applicable to most environments), please see the VMware Product Applicability Guide for PCI 3.0 published by Coalfire Systems with collaboration with Townsend Security and VMware.
Periodically changing the encryption key for protected data is a security best practice and a part of many compliance regulations like the PCI Data Security Standard (PCI DSS).
This encryption key change is sometimes referred to as “Key rotation” or “Key rollover” and these terms mean the same thing. When performing a key change operation you generate a new encryption key, decrypt the protected data with the old encryption key, and then encrypt the data with the new encryption key. After the defined cryptoperiod for the key you archive or escrow the key and it is no longer be used.
There are several factors involved in defining the cryptoperiod for a key. If you want to know more about defining cryptoperiods, you can get a good description in the NIST Special Publication 800-57 Part 1, “Key Management Best Practices”, section 5.3.
Townsend Security's Alliance Key Manager helps you with key rollover by allowing you to specify a cryptoperiod for any symmetric key, and then automatically generating a new key for you at the end of the cryptoperiod. In Alliance Key Manager the cryptoperiod is specified as the number of days from the key creation date. At midnight on the last day of the cryptoperiod, a new version of the key is created and it becomes the default encryption key. The old key is retained and is fully active so that data can still be decrypted with that key.
Like most enterprise key management solutions Alliance Key Manager provides a user-friendly name for an encryption key, and a version identifier. The key name is a normal character name and might be something like Credit card, Human resources, and so forth. The name is meant to provide an easy way for a user or security administrator to locate and use a key.
In Alliance Key Manager the version of the key is called the “Key instance” and is a unique character string. When managing keys the key instance name might look something like this: TGV0IGZyZWVkb20gcmluZw==. Key instance names are always unique and a key may have any number of key instances.
The most recent version of the key is the default, or current, instance of the key. When you retrieve a key in your application, you can leave the key version blank and you will automatically get the most current version of the key. When Alliance Key Manager performs key rollover the new version of the key becomes the current version of the key.
Alliance Key Manager supports three rollover settings for each symmetric key:
- Automatic key rollover at the interval you specify
- Manual rollover that you initiate through the security console
- No key rollover
Whatever key rollover strategy you decide to implement, Alliance Key Manager will provide the tools you need. You can fully automate key rollover, roll keys manually at your convenience, or dis-allow key rollover so that new versions of the key are never generated.
IBM introduced Field Procedures (FIELDPROC, or FieldProc) on the IBM i (AS/400, iSeries) platform in V7R1 of the operating system. It is a strategically important implementation and is a permanent part of the DB2 for IBM i database going forward. The FieldProc implementation is an event-driven exit point directly in the DB2 database and is invoked for most of the standard CRUD operations (but not delete). While the FieldProc implementation can be used for many things, IBM i customers primarily use it as a mechanism to automatically encrypt and decrypt data at the column level. It is now a widely adopted and deployed method for data protection on the IBM i and IBM System z Mainframe editions of the DB2 database.
While the benefits of the data at rest protection offered by FieldProc encryption is clear, our customers often ask us if FieldProc encryption will also protect their backups. It is a good question because there are times when making a copy of a file with FieldProc encryption causes the data to be decrypted by the copy. So does DB2 data remain protected with normal IBM i backups?
Fortunately, the answer is Yes - your backups will be protected with FieldProc encryption when you use any of the normal SAVE commands on the IBM i platform including commands like Save Object (SAVOBJ), Save Library (SAVLIB), Save Save File Data (SAVSAVFDTA), Save Changed Objects (SAVCHGOBJ), and the various IBM Backup Recovery and Media Services (BRMS) commands.
While it is rare, I have seen some uses of the Copy File (CPYF) command to copy data to backup tapes or files. In this case your data will be automatically decrypted during the copy operation and will NOT be protected in the backup image. To save data in encrypted format ALWAYS use one of the IBM save commands, the IBM BRMS application, or any third party backup solution that uses the IBM SAVE commands.
Another related question that we often get is how can I verify that the data is actually encrypted on the backup image? This is a good question because security auditors often want an independent verification of the encrypted status of the data. One way to verify the encrypted status of the data is to use the IBM Dump Tape (DMPTAP) command to dump the contents of the tape after a save operation. Try saving the file without FieldProc encryption, then save it with FieldProc encryption enabled. The Dump Tape command will show the contents of the data and you can easily see unencrypted values or encrypted values in the dump reports. Note that you may need to turn off save compression in order to view the data with this method.
Another way to verify the encrypted status of data is to use the same procedure, but save the file or table to a save file (SAVF). You can then use FTP to transfer the file to your PC in binary mode and use a file viewer to review the contents. Unfortunately, you can’t use the Display Physical File Member (DSPPFM) command as it does not display save files. On your PC you might like to use a utility like UltraEdit as it can view data in the EBCDIC character format. You can easily determine that your data is encrypted in the save file.
Either of these techniques can be used to verify the encrypted status of your files when saved with FieldProc active. You can rest assured that your data is protected on backup tapes and images and that the encryption key is not stored with the data!
Townsend Security provides a FieldProc implementation in our Alliance AES/400 solution. It integrates seamlessly with our Alliance Key Manager solution which manages encryption keys through the entire key life cycle. The Alliance AES/400 solution is the only IBM i FieldProc encryption solution that is NIST validated for the AES encryption library, and which combines this level of encryption with a NIST validated encryption key management solution, giving you provable compliance with industry standards.
Backup data protection is a great added benefit to FieldProc encryption on the IBM i platform. I hope this discussion helps resolve any question you have about FieldProc encryption and backup protection.
This is a guest blog by Nick Trenc, CISSP, QSA, PA-QSA, VCP. Nick is an IT Security Architect at Coalfire Labs.
For those protecting the front lines of our credit card data in merchant environments, few other things keep those in charge (as well as IT administrators) awake at night than the threat of a breach. Questions often arise along the lines of: Will my company be able to survive? What can I do to protect myself? How do I prevent my company from being next? And how do I limit any losses should it happen to us?
One of the key components to the protection of cardholder data at any merchant location is the use of strong cryptography along with just-as-strong cryptographic key management procedures. PCI DSS Requirement 3 outlines what the PCI council believes to be the baseline for strong cryptographic key management procedures and is a key element of any PCI DSS audit.
Successful key management with a strong cryptographic algorithm is the best place to start with getting encryption of your cardholder data correctly protected while it is contained within your environment. But key management can be confusing, difficult and downright impossible depending on the size of your environment. Figuring out if your keys are strong enough, or if they are rotated often enough or if they are protected from would-be hackers. On top of that, figure in the ever-increasing complexity of today’s business systems to include cloud, virtual computing, data mining, and others, the ability to quickly and easy manage encryption keys across several platforms and environments becomes key for PCI DSS compliance.
This is where a tool like Townsend Security's Alliance Key Manager (AKM) comes in to play. Available as a physical hardware security module (HSM), a cloud HSM, a virtual appliance (VMware) or in the cloud (AWS, Azure), Alliance Key Manager can help merchants meet PCI DSS requirements for encryption key management by creating, managing, and distributing AES 128-bit, 192-bit or 256-bit encryption keys all without the risks involved with clear-text key administration.
As a QSA, it is certainly encouraging to see a complete encryption solution that removes some of the worries of traditional manual clear-text key management procedures. AKM can relieve pressure to meet portions of PCI DSS Requirement 3 such as the need to render Personal Account Numbers (PAN) unreadable using strong cryptography with associated key-management processes and procedures (PCI DSS 3.4). It directly meets PCI DSS Requirement 3.5.2 to store keys within a secure cryptographic devices such as a HSM along with additional encryption requirements such as 3.6.2 – Secure Key Distribution, and 3.6.3 – Secure Key Storage. In addition, AKM can make PCI DSS Requirements 3.6.6 for Split Knowledge and Dual Control not applicable as there are no manual key-management operations involved. This (virtual) device is a useful cost-effective tool to help meet your PCI DSS compliance.
For more information on using AKM to meet PCI DSS compliance specifically within a virtual environment (but also applicable to most environments), please see the VMware Product Applicability Guide for PCI DSS 3.0 published by Coalfire Systems with collaboration with Townsend Security and VMware.
IBM i (iSeries, AS/400) users are often confused about user names in the IBM security audit journal QAUDJRN, and how they are reported to their log collection server or SIEM solution by Alliance LogAgent. To understand this it is important to know that every batch or interactive job on the IBM i platform actually has two user names: a job user name and a current user name (sometimes called the effective user). These two user names are often the same, but there are many times when they are different. Let’s take a look at some examples.
The IBM FTP server runs under the IBM user name QTCP as it waits for a connection from an FTP client. The user name QTCP is provided by IBM and is used for a number of network services. When an FTP client connects to the IBM FTP server and logs in, the job user remains QTCP but the current user is now the name of the actual user who logged in to the FTP session. If a user named BILL logged in you would then have these two user names:
Job user name: QTCP
Current user name: BILL
Both of these user names are recorded in the IBM security audit journal. You can see this information when you use the Display Audit Journal Entries command DSPAUDJRNE. Try selecting the job start event “JS” and you will see this in the output:
But there is a big difference in the capabilities and security risk between these two users. The user QTCP is an IBM supplied user with no ability to log into the system, and the user BILL is an actual user whose authorities and capabilities are in effect. If BILL is a highly privileged user he will have the ability to do a lot of damage and may even be able to retrieve any database file on the system.
Monitoring both user names in your SIEM solution and retaining the history of the activity on these two users is critical for your security strategy on the IBM i.
In Alliance LogAgent we collect and report both of these names when sending information to your log collection server and SIEM solution in the Syslog format. When you look at these events you will see something like this:
If you are using the Common Event Format (CEF) that is preferred by HP ArcSight’s SIEM solution, you will see information like this:
If you are using the new IBM QRadar log event extended format (LEEF), Alliance LogAgent will send the information like this:
The “usrName” keyword is predefined to IBM QRadar and is the user credential that is monitored for anomalies and suspicious behavior. So it is important that the effective user be supplied in this case.
Both user names contain important security information, and both should be reported to your SIEM solution for active monitoring. Alliance LogAgent always sends both user names to make your monitoring and security strategy more effective.
As a security architect, security administrator or database administrator, one of the first big questions you face with the encryption of data at rest is how to organize, plan, and implement encryption keys to protect that data. Should you use one key for everything? Or, should you use a different key for each application? Or, perhaps you should use a different key for every table and column? Or, should you use a different key for each department? It is hard to find good security best practice guidance on this topic, so let’s put some focus around this question and see if we can come up with some general principles and guidance.
First, I like to start by identifying any applications or databases that contain highly sensitive information such as credit card numbers, social security numbers, or other personally identifiable information. These sources will be the high-value targets of cybercriminals, so you will want to protect them with your best security. For each of these applications and databases, assign encryption keys that are not used by any other application or database, and carefully monitor the use of these keys. Your encryption key management solution should help you with monitoring key usage. The objective is to protect the highly sensitive data and the related encryption keys from unauthorized access. If you have multiple sensitive applications and databases, assign each its own unique key.
Second, identify all of your major applications that are used across a broad set of departments within your company. Since these applications span multiple departments and will have a broad set of users with different needs, you should assign each of these applications their own specific encryption keys. In the event one application or database is compromised, it will not affect all of the other applications and databases.
Third, the remaining applications and databases are probably those that are used by one specific department within your organization. You will probably find that most departments in the organization have a number of specialized applications that help them get their work done. In terms of raw numbers, this might be the largest category of applications. Assign each department its own set of encryption keys that are not used by other departments. You may find that you need to sub-divide the department and assign keys for each sub-group, but the goal is to use encryption keys for the department that are not shared with other departments.
Lastly, cloud implementations are a special category and should always have separate keys. In the event that a Cloud Service Provider experiences a security breach, you will want to be sure that your internal IT systems are not affected. Assign specific encryption keys for your cloud applications and do not share the keys with internal, non-cloud applications.
Over the years I’ve occasionally seen organizations create and use a very large numbers of keys. In one case a unique key was used for every column and row in a table. In another case a different key was used for every credit card transaction. Large numbers of keys present management problems, and probably lowers overall security. Keep the number of encryption keys to a manageable level.
The above guidelines should help you protect your sensitive data and easily manage your encryption keys. There is a summary table for the above guidelines:
|Highly sensitive data and applications
||Assign and use unique and non-shared encryption keys. Do not share keys across application and database boundaries. Carefully monitor encryption key usage.
| Broadly used applications and databases
||Assign and use unique and non-shared encryption keys. Do not share keys across application and database boundaries.
| Departmental applications and data
|| Assign and use departmental encryption keys. Do not share keys among departments.
| Cloud applications
|| Assign and use unique encryption keys. Do not share encryption keys with non-cloud, IT applications.
There are always exceptions to general rules about how to deploy encryption keys for the best security. The above comments may not be appropriate for your organization, and you should always adjust your approach to your specific implementation. Hopefully the above will be helpful as you start your encryption project.
Our Alliance LogAgent customers often ask us which IBM i security events we transmit from the IBM security audit journal QAUDJRN to their log collection server or SIEM solution. There are several factors that affect which security events get collected by the IBM i operating system, and even which events are collected by Alliance LogAgent for transmission to your SIEM server. Let’s take a look at these:
When your new IBM i server is delivered it is not configured to collect any security events. You must create the QAUDJRN journal and the journal receiver as a first step. Then you must change some system values in order to activate security event collection. This is the first step in answering the question about which security events Alliance LogAgent transmits. It can only transmit the events you enable and you set these with the system values.
The first system value you must set is QAUDCTL. When you receive your new IBM i platform this system value is set to *NONE meaning that no security events are collected. You should probably change this to:
You now need to set the QAUDLVL and QAUDLVL2 system values to specify the type of events you want to collect. On a new IBM i server these system values are blank. IBM makes it easy to collect the security events through a special system value named *SECURITY. If you set the QAUDLVL system value to *SECURITY you will collect only the security-related events on the IBM platform. Of course, there are other events that you might like to collect. Press the F1 help key to view a complete list of events. If they won’t all fit in the QAUDLVL system value just add them to the QAUDLVL2 system value and specify *AUDLVL2 in the list.
You can now use the Change User Audit (CHGUSRAUD) command to audit users. I would suggest you turn on full user auditing for any security administrator, any user with All Object (*ALLOBJ) authority, and any user with audit (*AUDIT) authority.
You can also turn on object level logging with the Change Object Auditing (CHGOBJAUD) command. Be sure to specify all libraries and files that contains sensitive data. Do the same thing for IFS directories using the Change Audit (CHGAUD) command.
You’ve completed the first step in configuring security event collection. Alliance LogAgent can only report what you configure the system to collect and this first step defines those events.
Alliance LogAgent can also be configured to filter security events. The default is to report all of the events collected in the system audit journal QAUDJRN, but you can narrow these to a defined set of events. In the Alliance LogAgent configuration menu you will see an option to Work With Security Types. This will list all of the event types collected in the QAUDJRN journal. You can use function key F13 to set group patterns, or change each event. The F13 option is nice because it has a *SECURITY option that will let you set all security events on for reporting. Or, you can edit an individual security event to change its reporting status. For example, to turn off reporting of Spool File actions, edit the SF event and change the reporting option to No:
Send to log server . . . . . . . 2 1=Yes, 2=No
When you make this change Alliance LogAgent will no longer send spool file action information to your SIEM solution.
It is not wise to turn off the reporting of security events in Alliance LogAgent! You will always want to collect and report these events.
Setting the system values and configuring Alliance LogAgent security events are the primary ways you determine which events are transmitted to your log collection server. There are additional filtering options in Alliance LogAgent to include or exclude objects, IFS files and libraries and these can help you further refine the events that are transmitted.