Looking into 2016, what is the role encryption key management will play in securing sensitive data?
Encryption and key management are the Fort Knoxes of security technologies for organizations wanting to protect sensitive data from hackers and data breaches. While commonly used by retail and financial institutions (and gaining even more traction after the onslaught of retail data breaches we saw in 2014), we still see major gaps and problems with implementation of these technologies across multiple industries. In 2015, with over 181 million records exposed in data breaches by mid November, we ask ourselves, what are the challenges of implementing encryption and key management, how widely are they used today, and what can we expect from encryption and key management vendors looking forward?
While encryption has become an easily accessible technology, it remains a major point of struggle for most companies. Since organizations have multiple departments with siloed technical infrastructure, many different tools must be used to manage data across the enterprise. From HR to Accounting to stored customer data, many different platforms, operating systems, databases, and applications are used to store and process sensitive information. This makes locating this data extremely difficult as well as achieving consistent data encryption that can be managed from a single, central location.
Boards of directors and executives are becoming more aware that data security is not just a technical problem, but a governance, risk management, and compliance problem that deserves the same level of attention to risk as financial, legal, and corporate aspects of their business. However, employees at the IT level still hold the most buying influence over encryption and key management technologies.
These sorts of buying decisions have historically landed in the wheelhouse of IT Operations; however, the primary issue that arises in these decisions is that complicated data security projects are often perceived as a threat to operational continuity. When an IT professional feels they must choose between security and functionality, they will always choose function to avoid the dreaded business-down scenario. Companies should not have to chose between security and continuity, and today, security professionals advocate that executives assign an IT security team to advocate for security solutions and work with IT Operations to implement these technologies.
According to the Ponemon Institute 2015 Global Encryption & Key Management Trends Study, meeting compliance requirements such as PCI-DSS remains the primary driver for encryption and key management implementation. PCI-DSS and federal and financial regulations such as FISMA and GLBA/FFIEC also continue to set the strictest data security regulations. However, despite compliance with industry regulations, organizations still experience breaches, often by a hacker accessing their network through a third party vendor or through employee mistakes. Sadly, often these breaches reveal that data was not encrypted, despite industry compliance.
This flagrant lack of encryption begs the question, will our data security ever get better, or will hackers continue to be one or even two steps ahead?
The answer to that question may come from the fact that in many large corporations, about 80% of resources allocated for data security apply towards network and anti-virus security. This includes firewalls, malware detection, and other intrusion-prevention software. The problem with relying mostly on network security is that hackers continually succeed in breaking through these barriers, often using social engineering and phishing scams to achieve enough authority to open a door and walk right in. Once inside, they discover sensitive data stored in the clear and steal it.
Network security is always an important part of a data security plan, but time after time we see encryption, which is also a critical part of that plan, implemented after-the-fact. This comes back to the issue of sensitive data being difficult to locate inside an enterprise, but the sheer amounts of unencrypted data that hackers are able to discover leads one to believe that some organizations simply do not implement encryption very well. This may be backed up by the discovery that only 37% of companies in the U.S. deploy encryption extensively (as opposed to partially) across their enterprise.
Diving deeper into the challenges surrounding encryption, one of the most painful parts of encrypting data is managing encryption keys. Even if a company encrypts a database of customer credit card numbers, if they do not protect the encryption key, a hacker could easily find the key and decrypt the data, rendering the encryption useless. Unfortunately, protecting and managing encryption keys away from encrypted data is still something organizations fail to do.
As organizations begin to move into the cloud and virtualized environments, as many already have, another stumbling block will be lack of availability of hybrid (cloud and in-house) encryption and key management solutions.
Looking into 2016 and beyond, the key management solutions that will excel will be the solutions that can manage encryption keys anywhere your sensitive data is located whether that be in the cloud, virtual platforms, or hardware. A majority of companies believe that hybrid deployment in both cloud and on-premise is the most important feature of an encryption solution. Without strong hybrid key management, encryption of data spread across an enterprise and the cloud will become even more difficult. Key management vendors that follow their customers into virtual environments will, in the long term, deliver more comprehensive data security.
It’s hard to imagine that data breaches will begin to diminish any time soon, but hopefully organizations will learn from others’ mistakes. It is clear from the evidence that deployment of encryption is nowhere near complete across most organizations, and lack of encryption key management continues to be a challenge, but working with the right encryption key management vendor can ease this pain.
When looking for a key management vendor that can help you manage encryption keys across your enterprise, including the cloud, look for a key management vendor that has:
- No hidden or additional fees for nodes or client-side applications
- Commitment to innovation and development
- Commitment to legacy products
- Excellent reputation for customer support
We all now know that active monitoring and rapid response is one of the critical security controls that really make a difference. That is why system log monitoring makes the Top Ten list of almost all cyber security controls. What is not so well known is how hard it can be to get active monitoring right. We have a lot of Security Information and Event Monitoring (SIEM) solutions to choose from, but very few of them are effective right out of the box. Why is this?
First, system generated logs are a mess. They are largely unformatted text messages without unique identifiers that make it hard for a SIEM solution to interpret. Add many different spoken languages and you have a major headache when it comes to interpreting log messages.
Second, other than some basic formatting guidelines, information in system logs is not normalized. While some log formatting standards like Common Event Format (CEF) and Log Event Extended Format (LEEF) attempt to provide this, very few devices actually format to these standards. The lack of system log standards contributes to the confusion when SIEM solutions attempt to interpret the log messages. It would make a database administrator shed tears.
Lastly, many SIEM solutions collect logs once or twice a day with some type of batch transfer, and events are not processed in real-time. Real-time analysis is core to effective SIEM monitoring of system logs. Without real time event collection it is difficult or impossible to do event correlation and the result is missed positives. All of that intelligence built into modern SIEM solutions can go to waste.
One thing I like about the IBM Security QRadar solution is that it comes with pre-defined definitions that out of the box know how to interpret logs from a wide variety of devices. IBM packages these definitions in a configuration object known as a Device Support Module, or DSM. IBM QRadar customers get access to all of these DSM definitions and they can be easily updated as new and revised configurations become available. This saves a security administrator a lot of time in configuring the SIEM to recognize events.
Another thing I like about IBM Security QRadar is that it understands that normalized data is important. The QRadar Log Event Extended Format, or LEEF, builds on IETF system log standards by adding well-defined data formats and field definitions. If all of your systems are reporting an IP address like this:
then you know that event correlation is going to work a lot better.
Our IBM i (AS/400, iSeries) solution for IBM Security QRadar integration is named Alliance LogAgent for IBM QRadar. It implements support for the QRadar LEEF data format for all IBM i security events, and transmits events in real time. IBM has now released an updated AS/400 DSM that includes recognition of the more than 200 security events transmitted by Alliance LogAgent for IBM QRadar. This means that customers deploying or updating their QRadar implementation get a much faster implementation and a much better security posture right out of the box. This new solution installs on an IBM i server very quickly and in minutes can be sending security events to IBM Security QRadar.
No one security control will make you safe. But actively monitoring your system and audit logs is crucial to a good security implementation.
For more information, visit our Alliance LogAgent for IBM QRadar or get started with a free evaluation.
Center for Internet Secuirity
SANS Top Ten (see CSC 6)
Q: How does LogAgent send security information to my SIEM or log collection server? Is information batched or real time?
The Townsend Security solution for system logging and SIEM integration is Alliance LogAgent. It works with a large number of SIEM solutions including IBM QRadar, LogRhythm, Dell SecureWorks, NTT/Solutionary, Splunk, Alert Logic, HP ArcSight, McAfee, and many others. It brings the IBM i (iSeries, AS/400) into an active monitoring strategy that is so important to good security. Since real-time security event collection is crucial to active monitoring, customers often ask us how Alliance LogAgent achieves this? Let’s take a deeper dive into how this is accomplished.
The IBM security audit journal is named QAUDJRN and it collects most of the critical security events on the IBM i platform. Unlike many IBM i system logging tools, Alliance LogAgent collects events from this journal in real time. Using IBM provided application program interfaces (APIs), events are collected from the security journal as they are written to the journal by the operating system. There is no batch-oriented extraction of events once or twice a day, and no batch transfer using unsecure FTP. Alliance LogAgent is able to grab the events as they become available. This provides the real-time view of security events that is so critical to active monitoring, correlation and alerting by SIEM solutions.
Once the event is extracted it has to be converted into a usable format. The security event information in QAUDJRN is in an internal IBM format and is stored in the EBCDIC character set which is largely unusable by SIEM solutions. Alliance LogAgent immediately converts the important information into a system log format (syslog, Common Event Format, or Log Event Extended Format), and translates it to the ASCII character set that is used by SIEM solutions. To make the information usable to SIEM solutions the event information is normalized into fields that are easy for SIEM solutions to understand. These normalized fields are in the keyword=value format (more on this is another blog). The formatting also happens in real time so that there are no delays imposed by the conversion process.
Once the security event is extracted and converted to a usable format, it must be communicated to the SIEM solution for processing. Alliance LogAgent implements a set of syslog communications modules that immediately send the security event to the SIEM server. Alliance LogAgent supports three different syslog communications options:
- Internet UDP protocol
- Internet TCP protocol
- Internet TLS encrypted TCP protocol
By default these communications programs send security events to the standard syslog port of 514 on the SIEM server, but you can easily change the port number if needed. Not every SIEM solution supports encrypted transfer of log events, but Alliance LogAgent gives you this option along with non-encrypted options for log transfer.
Alliance LogAgent runs in a background batch process at a low priority so that it does not disrupt normal interactive response times. Using the optimized processes of Alliance LogAgent the IBM i customer achieves real-time processing of security events and gets the best results and maximum benefit from their SIEM solution. Security issues are identified immediately and the IBM i system administrator can react swiftly to potential security breaches.
Additionally, Alliance LogAgent takes a similar approach to monitoring other security event sources on the IBM i platform. The QHST system message facility is also monitored in near real-time as messages are logged to the QHST files. For messages sent to the system operator message queue QSYSOPR or QSYSMSG, Alliance LogAgent also monitors these message queues for events and sends the information to the SIEM server in real time. The same is also true of the Alliance LogAgent exit point monitoring applications.
Alliance LogAgent was built from the ground up to accommodate real-time security event collection and transmission to your SIEM solution. It is fast, efficient, and non-intrusive. Exactly what you need to collect and monitor security information on your IBM i platform.
When IBM i users deploy Alliance LogAgent to integrate their IBM i servers with their log collection and SIEM solutions they naturally ask about the storage requirements. This is probably because some IBM i logging solutions perform batch extractions of the security events and then use FTP or other file transfer mechanisms to transfer the data. And there can be a LOT of security event information to transfer thus expanding the need for storage on the IBM i platform.
Alliance LogAgent does not use an periodic batch extraction architecture for its implementation. Instead, Alliance LogAgent extracts security event information from the security audit journal QAUDJRN in real time and pushes the information directly to the log collection server or SIEM solution directly. So the answer to the storage question is easy:
Zero. Zilch. Zed. Nada.
There is no intermediate or temporary storage utilization when you deploy Alliance LogAgent. All events are extracted, converted to a standard system logging format, and transmitted directly without the need for intermediate files. This is true for all of the security log sources on the IBM i including the security audit journal QAUDJRN, the system message files QHST, the exit points, the message queues, and the Linux-style message files in the IFS file system.
Of course, the application itself including the programs and configuration files require some storage on the IBM server. A typical installation of Alliance LogAgent will require about 115 MB of disk storage. But this storage will not grow over time due to historical information or temporary storage.
That is good news for IBM i customers who are trying to control costs.
Securing our systems is a demanding task and we don’t need the added worry of additional system resource costs!
In a ruling that shocked Internet service providers and businesses in the US and abroad, the European Court of Justice ruled this week that current data Safe Harbour rules may not be adequate to protect the privacy of EU citizens and that individual countries may make their own rules about data privacy. Anyone who has lived in Europe and knows the historical context of governmental tracking and abuse of individual rights will certainly not be surprised by this ruling.
But why is this such a big deal?
Have you noticed how good Google, Facebook, Microsoft, Amazon, Yahoo and others are at showing you advertising that reflects your interests? They are really good at this because they are the ultimate data aggregators. They use their vast network of global systems to bring data about you together and then perform sophisticated analytics. This means that most Internet service providers are moving data across country boundaries into the United States or areas controlled by the US where that data is subject to government inspection.
Beyond the obvious advertising aspects of Internet services, many backup and archival systems are built on Internet-based storage services. This means sensitive backup data moves over the Internet and may move to servers or networks outside of the host country. Internet service providers have been working hard to make their systems resilient and this often means integrating across borders.
In fairness, it is not just the US government that snoops on individual activity - many governments around the world do the same thing. And that is the concern of the European courts.
If data can’t leave a country, that will have a major impact on Internet service providers. And, of course, that will have a major impact on the small and large businesses that use these services. It’s potentially a very large problem!
In a Computer Weekly interview with Andy Hardy, Managing Director of Code42, he noted the importance of encryption and key management in meeting the new requirements. Andy said:
“It need not be the end of business as we know it in terms of data handling. What businesses need to do now is safeguard data,” he said.
According to Hardy, businesses must ensure they can keep company and customer data private, even when backed up into a public cloud.
“The right technology will ensure data it is encrypted before it leaves the endpoint device, so that it cannot be decrypted in the cloud and hence remains private. The best technologies will ensure that encryption keys are kept by our customers on-premise, so only they can decrypt the data and that no one else can access it unless with prior direct request. This is the only way to ensure privacy in the public cloud post-Safe Harbour,” he said.
I think Andy has this exactly right. When encryption is done right it makes the data unintelligible to anyone without the encryption keys. Using a key management solution that is resident in the EU, which is dedicated to the data holder, and which does not allow third party administrative access will be crucial to meeting the new EU privacy laws.
That’s exactly what we do with our encryption solutions that integrate with Alliance Key Manager and we are already helping EU customers protect their data with strong encryption. EU customers can locate Alliance Key Manager within their own data center, or in a country-specific hosting center, or even in a cloud service provider platform where there are adequate guarantees around in-country hosting.
IBM introduced the DB2 Field Procedures (FieldProc) column level encryption interface in V7R1 of the operating system. It has been a great way for IBM i (iSeries, AS/400) customers to protect sensitive data in their DB2 for i files and tables, but customers often have questions about how this new capability works. One of the most common questions is “Can I encrypt index fields and will they work correctly?”
The answer to the first part of the question is YES you can encrypt index fields, and the answer to the second part of the question is THAT DEPENDS. Let’s take a deeper look at encrypted indexes with FieldProc.
First, let’s look at DB2 FieldProc strictly from a SQL point of view. Remember that SQL is IBM’s preferred interface to the DB2 relational database. So let’s start there:
The first thing to understand is that FieldProc is fundamentally a SQL construct. That is, it is designed for and implemented as a SQL facility. You can specify a FieldProc program on the SQL CREATE TABLE or ALTER TABLE commands, but you can’t specify FieldProc on traditional DDS source descriptions. FieldProc works great on index fields in your SQL applications! Your SQL statements will work just as you would hope and you will have a great new facility for implementing automatic encryption. With very few limitations you will find that encrypted indexes work without any issues for your SQL applications. I’ve rarely found a customer who was unhappy with IBM’s implementation of FieldProc in native SQL applications. This includes SQLRPG applications that use native SQL for the database interface.
But, of course, most IBM i customers are running a lot of legacy RPG or COBOL applications that do not use SQL. And this is where there are some significant restrictions on encrypted indexes.
First, you CAN use FieldProc on traditional database files created with DDS. It is not necessary to convert the database files to SQL in order to use FieldProc. Of course, FieldProc application support is installed using SQL statements, but they will work on traditional DDS created files with some minor limitations. So this part is not complicated.
Next, you CAN encrypt indexes that are created with DDS. However, you do have some significant limitations when using FieldProc with DDS files. For example, some join logical files that join on encrypted index fields will not work. You simply won’t be able to create join logical files that link using fields encrypted under FieldProc.
A more fundamental problem is that legacy RPG and COBOL applications will not work correctly with most encrypted indexes. Since the legacy file interface is not SQL, the legacy applications will not work as expected in many cases. For example, it is very common to use the Set Lower Limits (SETLL) command with the Read (READ) command to read a range of values in a table. In these legacy applications the SETLL value will be converted to the encrypted value by FieldProc, and then the next record will be read using the encrypted key value. But encrypted values will not be in the same order as the original plaintext values. This will lead to empty subfiles and empty or incorrect information on reports.
For many IBM i customers the limitations on encrypted indexes are not a big problem and they live with them. For many others encrypted indexes with legacy RPG applications is a significant problem that will make the use of FieldProc impossible.
Is there a solution for this problem? Well, of course you can convert all of your legacy databases and applications to SQL databases and SQL RPG applications, or even to native SQL applications. But this represents a major investment by many customers. But there is an alternative provided in the Open Access for RPG (OAR) implementation by IBM.
The Open Access for RPG implementation allows you to define a handler for file operations using one F specification in your RPG program. With this implementation the legacy file operations are handled by your new handler application. And that can be a set of SQL functions! This means that a legacy RPG program can become enabled for true SQL operations with a simple change and re-compile of the application. Of course, you must have the SQL handler functions ready to take over the file operations. I won’t go into creating SQL handlers in this blog, but be aware that creating SQL handlers is not for the faint of heart. You need to have extensive experience with SQL and understand the OAR architecture. If you’ve not done this before the IBM Lab Services team can provide assistance.
In summary, FieldProc is a great new facility and it is already helping a lot of IBM i DB2 customers to protect data with strong encryption. It works great with native SQL applications, but you need to be aware of some limitations when used with legacy RPG and COBOL applications.
Our Alliance AES/400 solution provides everything you need to implement FieldProc.
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.