Townsend Security Data Privacy Blog

I am often asked about how one can restrict access to Alliance Key Manager (AKM), our encryption key manager.  There are a few different options available here in relation to locking down and controlling who has access to which keys.  This often is a concern for bigger organizations that have multiple departments authenticating to the encryption key manager and performing key retrieval operations, but I’ve known smaller companies as well that take advantage of the granularity AKM provides in this area.

One way you can restrict access to Alliance Key Manager is by restricting keys to specific users or groups of users. The users and group access can be defined on a system level, or at the level of each key. When you create a key you can define the restrictions on user and group access.

Since all connections to AKM are mutually authenticated over a TLS session, you as a client (key requestor) must present an X509 digital certificate to AKM that is signed by a trusted Certificate Authority (which needs to be known to the key server).  Within your client certificate are multiple fields of user data collectively known as the Distinguished Name (DN). Further, within the DN you'll define fields with information regarding who you are, what organization you are with and where you're located. There are two fields in particular that the AKM server will look at to determine your Group or User privileges. These are the Common Name (CN) field and the Organization Unit (OU) field. We look at the common name to determine user access and the organization unit to grant group authority.

Lets look at an example.  There is an AES encryption key available on an AKM server used to protect an employee's personal data. It is restricted so that only members of the Human Resources group can use that key. So any individual with "Human Resources" defined as their OU can successfully request that key, all others are turned away. This is Group Restricted Access.

To further this example, the director of Human Resources, Sam, needs access to a specific key only he can use. There would then exist an encryption key on AKM that has group and user policy defined as "Sam / Human Resources" and Sam's X509 digital certificate would have the CN of "Sam" and the OU of "Human Resources." This would ensure only he is allowed to access that key. This is strict group and user control of key usage and deters other "Sams" in the company from getting the key, as well as other individuals within the "Human Resources" department.

There are a few other ways to restrict access. You can specify just specific users who can access keys and ignore the group altogether. This would require defining a user table within AKM and tying specific keys to it. Then any user with the appropriate CN can authenticate and use those keys. The same can be done for groups as mentioned previously or any combination of group or user status as defined by the group or user table laid out on AKM.

And lastly you can allow anyone with an authenticated x509 digital certificate that can latch up to the key server successfully request a key. This method ignores the CN and OU altogether and is the least restrictive level of key access. However it still locks down key control as only authenticated clients with proper certificates can gain access to encryption keys.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

The task of deploying encryption key management into your infrastructure to meet security and compliance best practices can be overwhelming at first.  To help give you a 'bird's eye view' of the core components of our Alliance Key Manager (AKM), our encryption key management HSM, I want to breakdown the three major components to it.  Having this understanding in your back pocket as you roll out AKM can help smooth out the process.

First up, your security team can utilize our AKM Java GUI console to create and manage AES encryption keys for use in your applications.  This is a program that you install on a Windows machine that communicates directly with the key server via a secure TLS session.  Here, keys can be created, expired, revoked, rolled or even deleted – requirements of PCI DSS and other compliance regulations.  You can also define a key access policy for each key that is created, specifying what groups or individuals can request and use it.  Alternatively, you can also use our Linux command line facility to completely automate encryption key management through scripting calls.

The second component focuses on your application that's doing encryption and requires access to an external key manager.  You’ll need to make some minor coding changes to your application layer to enable it to make API calls to our shared library that does key retrieval portion.  To help you succeed here we offer sample code in a variety of programming languages for your development team to work with.  All of these samples can be found on the AKM product cd.

If you need Extensible Key Management (EKM) for Microsoft SQL Server 2008 Enterprise Edition and above you can take advantage of Transparent Data Encryption (TDE) or Cell Level Encryption.  We see many organizations use TDE and EKM because they can easily implement encryption without changing any of their applications - and can be deployed relatively quickly.

Finally you have the ability to physically manage the key server appliance itself.  By using a web browser directed at the IP address of the appliance on your network you can create system and database backups, define mirrored servers, and enable Syslog to meet PCI-DSS and other compliance requirements.

Download our “Encryption Key Management Simplified” resources kit to find more information on meeting PCI DSS and HIPAA, encryption key management best practices, and more.

So you've decided to purchase an encryption key management HSM to help you pass a QSA audit and meet PCI DSS compliance.  Unfortunately just showing the auditor your paid receipt and key manager is not enough to satisfy requirements.  You have to actually be using them in a production environment.  Fortunately this is a fairly simple process to get started with Alliance Key Manager, our encryption key management HSM.  

Once the appliances are assigned IP addresses and reachable on your network, there are three fundamental tasks that you should complete prior to going into production.

First you'll want to setup and configure mirroring to your H/A failover server.  This is as easy as toggling on outgoing mirroring in the AKM.conf file of your primary server.  Next you'll want to have one of your Security Admins log into the Java based AKM Admin console for the production server and point it towards the failover server that will be receiving all the mirrored commands.  The final step to complete mirroring requires logging into the failover server and defining the incoming mirror details in the AKM.conf file for that appliance.  You'll also want to be aware of any firewalls in your network that could inhibit traffic and add exceptions accordingly.

The second part to deploying an encryption key management appliance involves defining your log collection of system logs for audit purposes and meeting section 10 of PCI DSS.  Alliance Key Manager supports transferring system logs via syslog-ng to a log collection server that is running a SIEM solution.  This is configured in the standard syslog manner by defining a log source, destination, and path.

The final and surprisingly perhaps most overlooked step to appliance setup is the creation of system backups.  Within Alliance Key Manager you will create two different types of backups from the outset.  The first will be a backup of your key encryption keys and configuration settings.  This backup needs to really only be run once during the setup of the device as there won't normally be changes to these settings going forward.  The second backup will be of the primary key management database, which will contain all your data encryption keys used by key retrieval clients.

During the backup process you'll be asked where you want these backups stored and define a backup destination.  Your choices include a local directory on the key server itself or sending it to an FTP server using SSL or SSH.  We  recommend sending your backups to a secure FTP server off the appliance in the event of a hardware failure and you can't reach the backup directory you'll still have access to these crucial images elsewhere for restoring purposes.

To make life easier on your network team we provide a scheduling facility that allows you to automatically create and transmit these backups at any specified time of your choosing.

Tackling these three tasks while setting up your Alliance Key Manager HSM will help you well on your way to passing that QSA audit.  The deployment team at Townsend Security can help you breeze through these steps as well as provide you documentation that covers these items in further detail.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

In part one of Meeting PCI-DSS Requirements for Encryption Key Management I discussed Separation of Duties and Dual Control, two critical components necessary towards meeting Section 3 of PCI DSS for encryption key management compliance.  Equally important to meeting section 3 are the notions of Split Knowledge, Audit Trail Logging and Strong Key Usage and Protection.

Section 3.6.1 of PCI DSS v2.0 states that your encryption solution must generate strong keys as defined by PCI DSS and PA-DSS using "strong cryptography."  On our Alliance Key Manager (AKM) all data encryption keys, key encryption keys, and authentication keys are generated using a NIST approved and certified cryptographically secure random number generator.  This meets NIST requirements for strong encryption key creation and establishment.  Furthermore in regards to Key Encryption Keys and Authentication Keys that protect your data encryption key database, the former keys are protected by a 2048-bit RSA key.  Since AKM is FIPS 140-2 certified and meets NIST requirements, you're covered on how keys are stored in a protected format, detection of key corruption, and the separation of data encryption keys from your key encryption keys.

Split Knowledge can also play a crucial role in protecting your data encryption keys.  Parts of the security standard state that you shouldn’t export a key in the clear from the AKM database and that the key needs to be protected.  For this to occur, you'd first have to have your Admin latch up to the key server utilizing a secure TLS connection with the proper credentials and authenticate to the server.  Once the connection is established, the admin is free to export or import symmetric keys, however upon export they will be required to protect the symmetric key with a RSA key. No manual establishment of keys in the clear is supported. By default this is out of the box functionality; we ensure this requirement by setting a configuration option for PCI-DSS mode.

Finally, there is the important item of collecting your system logs and transmitting them over your network to a waiting log collection server.  This waiting log server would ideally be running a SIEM product that monitors and analyzes log messages looking for malicious activity or critical errors. Specifically, AKM writes logs to four different log files; audit, error, backup, and trace logging, when enabled.  The key manager comes with Syslog-ng built in and ready to be configured.  You simply select your sources and define your destination of the collection server to begin transmission of your log files.  You can configure your SIEM product to send out alerts when certain events or errors occur that you want to be on the lookout for.

Want to learn more?  You can view a pre-recorded webinar titled "Encryption Key Management Simplified" and learn how encryption key management can be easy, why encryption key management is important, and what the barriers are to good encryption key management.

There are are a few major components of PCI-DSS that need to be addressed when implementing an external key manager into your data encryption equation.  Separation of duties for starters, simply states that those who have access to the sensitive data, such as card holder details or credit card numbers cannot also have access to the encryption keys that protect them.  Conversely, the same can be said for the individuals that are responsible for managing data encryption keys -- they should not have access to the sensitive data for which the keys they are creating are used to protect.  Quite simply, separation of duties is the concept of dividing critical data protection processes between different individuals. This helps reduce the opportunity and likelihood of fraud when processing sensitive data.

I often talk with companies who've until recently considered encryption key management as an afterthought to their security infrastructure.  Often times they would store encryption keys on USB sticks or locally, alongside the encrypted data.  This approach allows individuals within the organization access to both the keys and data, directly conflicting separation of duties.  Utilizing an external encryption key manager to house your encryption keys, as well as implementing a policy where your security team are the only ones managing those keys and your DBA's and users are the only individuals accessing the data, will help move you in the direction of PCI compliance.

But of course there are other pieces to PCI that one should be aware of when it comes to proper encryption key management.  While separation of duties is good practice, there is an additional level of security that can be implemented on the encryption key management side called dual control.  Dual control is a process that requires the involvement of two or more individuals to complete a specified task, such as creating a key, changing its attributes, revoking status, or destroying an encryption from use forever.  Think of dual control as the act of requiring two individuals with two different keys to unlock the launch codes for a nuclear missile.  You certainly wouldn’t want all that responsibility resting on the shoulders of just one person with no oversight in place.  The same can be said for the management of your encryption keys.

To implement dual control on Alliance Key Manager (AKM), our encryption key management HSM, you'd first active it in the AKM configuration file of the hardware appliance.  Then the two Security Admins responsible for key management would install our Java based admin console into their work environments and configure them to communicate with the key manager over a secure TLS connection.  Once this is established, the first Security Admin would authenticate to the key server and set an 'Authorized Administrator' time period.  This allows the the first Admin to specify a window of time (in minutes) where the other Admin can log onto the key manager and perform their duties.  Taking this approach to key creation and management adds that additional layer of security to your encryption key environment.

In Part II of 'Meeting PCI-DSS Requirements for Key Management'  I will discuss the importance of capturing your audit logs and transporting them to a collection server off the key manager device as well as dig into the concept of split knowledge and how AKM meets that requirement. Until then, download our white paper on encryption key management requirements for PCI.

I am often asked about what policy and features can be assigned to an AES encryption key that is created by Alliance Key Manager, our encryption key management HSM.  Simply put there are various options available at key level for each symmetric encryption key you create. This helps you line up with PCI-DSS, HIPAA/HITECH and other compliance regulations, as well as providing a well rounded security strategy for proper encryption key management.  I wanted to give you a little bit of flavor of what some of these key options are so you can get a sense of the flexibility when it comes to key creation.

To get started, when creating a symmetric key, you assign it a user friendly name.  This can be something as simple as ENCKEY_HR.  This makes it easily identifiable from a management standpoint for what it's used for and for what group will be using it.  And since these are AES keys we are creating, you'll be asked to specify what key size you wish to utilize for each individual key.  Your options are 128 bit, 192 bit, and 256 bit keys.  I normally recommend the 256-bit size as it is the strongest options available, but in all honesty, any size is adequately strong against any brute force attack it might come up against by a crafty hacker trying to decrypt your data  

When creating keys, you’re allowed to set activation and expiration dates.  This allows you to pre-create keys and to define a schedule as to when a key can be made available for use.  You may want to have a policy where keys expires every few years and you revoke their use from users.  If you're familiar with PCI requirements you'll know that you have to establish a crypto-period for your active encryption keys.  When creating an encryption key you can specify how many days that key will be made available before it automatically rolls over into a new version of that key.  The friendly key name you assigned to it at conception will never change, but behind the scenes you'll have a completely new instance of that key for use.  Additionally, in an event where you suspect a data breach or need to roll a key manually, these options are available for you as well.

To provide an additional layer of security to who can have access to encryption keys, we provide a Key Access table that lets you lock down who or what groups can have access to which keys. There are varying levels of granularity that are made available for you in this area. For example, from a very unrestricted sense where anyone in your organization with an authorized TLS session to the server can request a key, all the way to the very strict policy where only specified users within specified groups can requests certain keys. These credentials are all set at the key level and are defined on the key requestor side within the distinguished name of the digital certificate they are using to connect to the key server and establish a secure link for key retrieval.

Additionally, keys have mirroring attributes that can be set at the key level to ensure you don't experience a business interruption by always having access to keys in the event of a network outage.  I've seen customers never miss a beat when that unexpected outages occurs due to the fact that they have a hot failover standing by and ready to go.  Also, to help add a level of detail to the keys you'll be creating, we provide sixteen different metadata fields for you specify details unique for each individual key.  These fields enable you to easily track important details relevant to the key throughout its lifecycle.

Managing encryption keys with a Hardware Security Module (HSM) is the best way to ensure encrypted data remains secure. Learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.

Section 10 of PCI DSS requirements v2.0 states the need to track user activities, to be able to detect, prevent or minimize the impact of a data compromise.  Because of the mere fact that most every application under the sun produces a log entry for when something goes amiss, you can also use that same log file as a security tool.  It can provide a means of tracking and analysis when a possible data breach may be occurring as well as add crucial detail for investigative purposes.  Now a smart criminal knows to cover their tracks at the scene of a crime, and they can do this simply by wiping out any log data that may exist.  However if you’re capturing these logs in real time and sending them to a third party server, even the most savvy of crooks will be caught red handed.

Our Alliance LogAgent solution helps accomplish that, as well as satisfying parts of section 10 of PCI DSS by being able to capture logs from your IBM i’s audit journal, formatting them and sending them off to a waiting log collection server.  We monitor for log entries out of numerous places on the iSeries allowing the user the a level of granularity to choose what log messages to capture and kick over the wall to the waiting log server.  It's always a good idea to work hand-in-hand with your PCI auditor to make sure you're collecting all the appropriate events on your system to meet their requirements.

For instance, you'll want to make sure you're collecting AF (Authority Failure Events) events which come from the System Value QAUDLVL.  This particular event is triggered by all access failures, such as sign-ons authorization, and job submissions. It also includes incorrect password and user ID attempts from a device.  These details can play a crucial role in tracking down details around a possible breach into your system.  

As I mentioned, Alliance LogAgent sends these events to a listening collection server or SIEM solution.  We work with any SIEM product that is actively listening and waiting for logs to arrive and can accept messages in the RFC 3164 or Common Event format.  There are a number of SIEM products available on the market and they help parse the influx of log messages as they arrive, as well as send out notification and alert emails when something suspicious is detected.

Currently, the PCI guidelines don't include transmitting logs over a secure SSL/TLS session (it’s a very, very good idea).  However, looking ahead to when this becomes a requirement, you can rest assure that you’re already running software that can meet those needs.  LogAgent is already setup to handle secure SSL/TLS transmissions and is one of the reasons it stands apart from the competition.  The only change you'll have to make in the configuration of the product when switching over from UDP/TCP to SSL will be to provide an SSL application ID.  This is an ID that is associated with a digital certificate that you can create with IBM's Digital Certificate Manager (DCM).   Having this secure session in place will ensure that your log message data won't be intercepted on its journey to the collection server.

Download a free 30-day evaluation of Alliance LogAgent Suite and meet Section 10 of PCI DSS.  In under an hour, you can start collecting all system logs on your IBM i (AS/400) and converting them to syslog or CEF format for any SIEM or log collection server.

The Alliance LogAgent Solution for system logging on the IBM iSeries is able to grab log messages out of a variety of places such as your system's audit journal, (QAUDJRN), your history log (QHST), and system operator messages (QSYSOPR) and format them to either a standardized Syslog format, in this case RFC3164 or Common Event Format (CEF). Once formatted, we pass the messages over to the communications module that handles the transmission of the messages to your waiting log collection server using either the UDP, TCP or SSL/TLS protocol.  

LogAgent can send to any collection server that is listening for messages.  You simply assign either a remote host or IP address of the waiting server as well as the port number.  Ideally you would want a SIEM (like from LogRhythm, Solutionary, or SolarWinds, for example) running on that server to read the messages that are received, sort them and send out alarms to your security team when dubious messages arrive.

More often than not you'll want to use the Syslog format as it is generally accepted.  The RFC3164 format that we use is composed of three parts.  The first part is called the PRI, the second part is the HEADER, and the third part is the MSG.  

The PRI part is the Priority value and begins the log message.  Its value is contained within angled brackets and is either two or three digits in length.  It is comprised of the Facility value and the Severity level of the message.  The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity.  (Example: <40> )

The second part of the message is the header which will contain a timestamp, and an indication of the hostname or IP address of the device it originated from.  The MSG part will fill out the remainder of the syslog packet and contain the generated message and the text of the message.  

Here is a quick sample of a log message in RFC 3164 format.

<118> Apr 18 16:32:58 10.0.1.11 QAUDJRN: [AF@0 event="AF-Authority failure" violation="A-Not authorized to object" actual_type="AF-A" jrn_seq="1001363" timestamp="20120418163258988000" job_name="QPADEV000B" user_name="TESTFORAF" job_number="256937" err_user="TESTFORAF" ip_addr="10.0.1.23" port="55875" action="Undefined(x00)" val_job="QPADEV000B" val_user="TESTFORAF" val_jobno="256937" object="AFTEST" object_library="CUS9242" object_type="*FILE" pgm_name="" pgm_libr="" workstation=""]


If you're using a SIEM such as ArcSight who is expecting logs messages in the Common Event Format (CEF) you can easily switch the formatting from the configuration menu of LogAgent to send in this manner.  Much like the RFC 3164 version, the message contains a timestamp and hostname or IP address at the beginning.  This is followed by the Extension part of the message and is really a placeholder for additional fields.  Some common fields you'll find are CEF version, Device Vendor, Device Product Severity and Signature ID just to name a few.   

Example of what a CEF formatted log message looks like.

Feb 29 15:47:25 10.0.1.43 CEF: 0|PATownsend|IBM-QAUDJRN|1.28|1007|CO-Create object|4|msg=CO-Create object act=N-Create of new object actual_type=CO-N jrn_seq=102361 timestamp=20120229154725823000 dproc=ICC suser=MVAGANEK job_number=638012 eff_user=MVAGANEK object=X_BIGNUM object_library=ICAPITST object_type=*MODULE object_attrCLE

It's always a good idea to check with the team managing your log collection server to see what format they are expecting log messages to arrive in. Hopefully having a clearer understanding of what your choices are will help make the task of deploying system logging on your AS/400 smoother and easier to satisfy section 10 of PCI DSS compliance.  If you haven't yet, download a free 30-day evaluation of our Alliance LogAgent for IBM i system logging software.  Our customers have deployed the solution in under an hour from the time they download the evaluation from our website!