Townsend Security Data Privacy Blog

IBM i FieldProc Architecture and Implementation

Posted by Luke Probasco

Excerpt from the eBook "IBM i Encryption with FieldProc - Protecting Data at Rest."

FieldProc Architecture

IBM i Encryption with FieldProc FieldProc is a type of column-level exit point that is implemented directly in the DB2 database. As is typical with any of the other IBM exit points, IBM provides the architecture for the exit point to invoke a user application, but IBM does not provide that application. Customers or vendors can create a FieldProc application based on the documented architecture of the exit point. Townsend Security is one vendor who provides such software.

A note on terminology:
We will use the term “column” when referring to a field in a file, and we will use the term “table”
to refer to a physical file. For the purposes of discussing FieldProc these terms are interchangeable and we will use the more modern terms “column” and “table”. In a similar way we will use the term “index” to refer to a column that is either a primary or secondary key. A secondary key would include a key de ned in a logical file.

The exit point architecture is very simple. There are only two commands and three functions that are supported. The two commands are:

  • Start FieldProc
  • End FieldProc

The three functions that are handled by a FieldProc program are:

  • Initialization
  • Encode (Encrypt)
  • Decode (Decrypt)

When FieldProc is started on a column the FieldProc program is called for Initialization, and then called for each row in the table to provide for the encryption of the column. When FieldProc is ended the FieldProc program is called for each row to decrypt the data. All other normal read, change, and insert operations call the FieldProc program to provide for encryption or decryption as needed. FieldProc is not invoked for a delete operation on a row.

FieldProc Implementation

FieldProc is a SQL feature and is implemented through SQL commands. That is, FieldProc is not implemented through DDS, but only through SQL. Through SQL you create or alter a table to have the FIELDPROC attribute like this:

ALTER TABLE employee alter column
salary set FieldProc Userpgm

Likewise you can remove a FieldProc attribute using a SQL DROP statement like this:

ALTER TABLE employee alter column
salary Drop FieldProc

As noted above when you start FieldProc with the CREATE TABLE or ALTER TABLE commands, the effect is immediate. Starting FieldProc causes the FieldProc program to be called for each row in the table to perform encryption. Dropping the FieldProc attribute of a column causes the FieldProc program to be called for each row to decrypt the data.

Certain operations will cause FieldProc to be invoked even if the column data is not being used. For example, a legacy RPG program might read a file from beginning to end but not use a particular column that is under FieldProc control. Even though the column is not used in the RPG program FieldProc will be invoked to decrypt the value of the column for each row.

Note that a native SQL SELECT statement that does not include the encrypted column will NOT invoke FieldProc for decryption. Some work management operations are difficult with the current IBM implementation of FieldProc. For example, save and restore operations when the restore library is different than the save library can be problematic. Additionally, change management operations where there are changes to column attributes can be difficult to manage and require decrypting the database, applying the change, and then re-encrypting the database. These limitations are especially true in legacy RPG applications.

Supported Field (Column) Types

Most column types are support for FieldProc including character, numeric, date, time, and timestamp  fields. You can use FieldProc on null-capable  fields and double-byte character  fields. Some type of derived and counter  fields do not support FieldProc, but IBM i customers will  find that all normal application  fields are supported. With FieldProc there is no need to change the  eld size or attribute, nor is there any need to change or re-compile applications.

Legacy DDS Files

Many IBM i customers have the impression that legacy DDS  files will not support FieldProc encryption. This is not true! You can readily implement FieldProc encryption on  files created with DDS and it is not necessary to convert them to DDL and SQL tables. As IBM notes there are some advantages to doing so, but it is not necessary and the large majority of FieldProc users continue to use DDS  files. As noted above, you can only start and stop FieldProc using SQL commands, but these SQL commands work  ne on DDS-created  files.

Encrypting Multiple Fields in One File

DB2 FieldProc control can be started on multiple columns in one database table. Three is no practical limit on the number of columns you can select for FieldProc implementation. Of course, there are performance implications for encrypting multiple columns as the FieldProc program will be called independently for each column under FieldProc control. But many IBM i customers place multiple columns in a table under FieldProc encryption control. In some cases customers place hundreds of columns under FieldProc control. FieldProc’s support for multiple columns includes columns that are Primary or Secondary keys to the data. Please see the following sections for a discussion of limitations related to encrypted indexes and legacy RPG applications.

IBM i Encryption with FieldProc


Related Posts Plugin for WordPress, Blogger...

New York, Financial Institutions, and IBM i Encryption

Posted by Patrick Townsend

New York State has finally had enough. Most people think that their bank has strong encryption in place to protect them from cyber criminals and nation-state actors. But that is too often just not the case. After a number of high profile data breaches at larger financial institutions, and a worrying increase in attacks on banks, the State of New York is about to require that banks implement some stringent security controls to protect Non-Public Information (NPI). The  new regulations are not a difficult read and you can find the proposed new regulations here.

Let’s take a look at some of the new requirements.

IBM i Encryption with FieldProc First, banks are required to develop a cyber security program. This means that there must be formal security processes in place, and appropriate management oversight. Banks are required to have systems and processes to identify threats, respond to them, and recover from an attack. The regulation also requires appropriate reporting of security events, something that is not always honored in today’s environment.

Next, banks are required to have a Cybersecurity Policy that addresses a number of areas related to information security, incident response, access controls, data privacy and other areas. If you are familiar with the Center for Internet Security Critical Security Controls or the NIST Cybersecurity Framework, these points will be familiar to you. As you might expect, a premium is placed on ongoing adaptive responses to new threats, so these frameworks are not a check-box response to the problem. Banks are being asked to step up to a new level of seriousness around IT security.

You also need a Chief Information Security Officer (CISO) position designated in your organization. And, interestingly, the CISO is required to report to the board of directors of the bank. I find this requirement interesting as it means that boards of directors cannot remain ignorant about the state of the bank’s IT security. And this means that it will have to become a part of the governance process of the board.

The new regulations now get down into the weeds about what you should be doing. Here are some of the areas:

  • Vulnerability and Penetration testing
  • Collect and archive system logs
  • Implement restricted access controls
  • Conduct risk assessments at least annually
  • Hire cybersecurity professionals and make sure they stay current on new threats
  • Require third parties to adhere to the same security rules as the bank
  • Use multi-factor authentication for internal and external access to NPI
  • Train and monitor all personnel with access to NPI (SIEM, anyone?)
  • Encrypt NPI
  • Develop and incident response plan

The requirement to deploy encryption is surprisingly strong. It is a mandate unless deploying encryption is unfeasible. Given the wide availability of encryption in all major operating systems and databases, I believe it will be difficult for a CISO to argue against the use of encryption. Clearly the regulators want banks to encrypt sensitive NPI data.

Who does the new rule affect?

The new rule affects any financial institution that is regulated by the New York Department of Financial Services. This will affect all national and global banking organizations as New York is one of the leading centers of global finance. It may also affect regional banks through the extension of the rules to affiliates. Regional and local banks should review their relationships with larger banks to try to understand their requirements under these new laws.

When does the new rules take effect?

The new rules take effect on January 1, 2017. In terms of time, that is very soon! And there is only a 180 day transition period. CISOs can request an extension, but these controls must be in place by January of 2018. That is a very aggressive timeframe!

How is the IBM i (AS/400, iSeries) affected?

Almost all large banks and financial institutions use the IBM i server somewhere in their organizations. The IBM i server is perfect for the back office applications that banks run and which need a very high level of availability. Many of the largest third party banking applications are deployed on IBM i servers.

But banks are going to face a big challenge with IBM i DB2 database encryption. The Non-Public Information that must be protected is often used for indexes in the DB2 database. While IBM DB2 supports column level encryption, it won’t work well RPG programs that use encrypted indexes. Here at Townsend Security we have a fix for this problem! By implementing an OAR-based SQL interface for RPG files we are removing the impediment that banks face with encryption on the IBM i server. You can read more here.

And you can get a quick look at how this helps in this short video: 


Tags: Compliance, IBM i

Related Posts Plugin for WordPress, Blogger...

System Logging for the IBM i - A Must Have Security Control

Posted by Patrick Townsend

IBM i (AS/400, iSeries) customers now know that their systems are no more secure than any other. That is, they are just as much a target as any Windows or Linux server that exist in less secure network environments. This is not a criticism of the IBM i security implementation, it just reflects the fact that our IBM i servers are connected to a wide range of other devices including user PCs, network devices, local and WAN networks, and so forth. The attack surface is broad, IBM i servers are a rich target for data thieves, and we are all just one user PC infection away from an IBM i server data breach.

IBM i Security: Event Logging & Active Monitoring A lot of IBM i customers postpone deploying a system logging and SIEM solution to actively monitor for security threats, even though this is one of the most effective means of detecting and preventing a data breach. There is a reason that the Center for Internet Security recommends system log collection and monitoring with a SIEM solution as the 6th Critical Security Control. It just works really well when done properly.

I suspect that cost is one of the reasons that projects are postponed. This reasoning is “penny wise and pound foolish”. Here’s why:

  • There are now very cost effective log collection and SIEM monitoring solutions available for the smaller Enterprise. Some of these solutions are cloud-based and some can be deployed in VMware infrastructure. Cost is not as big an issue as it has been.
  • The failure to collect system logs means that it will be difficult to do the forensic investigation that you must do after a data breach. Imagine a costly data breach and then imagine not being able to figure out how the data thieves entered your system! All too often this means that a second and third data breach happens after the first. Without collecting system logs you won’t be able to deploy the forensics tools to trace the path of the cyber criminal through your organization. Another data breach is almost a certainty.
  • Early detection is one of the most effective means of preventing the data breach. This means large savings on outside security consultants, litigation costs, and the deployment of log collection and monitoring tools at inconvenient times. Early detection is a life-saver for those who can prevent a breach.
  • Log collection and SIEM monitoring solutions are easier to deploy than ever. While deploying an active monitoring system was complex and costly in the past, many SIEM solutions can be deployed and start working to protect your organization is just a matter of hours. Unlike in years past when SIEM solutions took weeks to install, configure and deploy, many are now extremely easy to setup and administer.

From a Governance, Risk Management and Compliance point of view deploying the CIS Critical Security Controls is a minimum requirement. Here is what the California Department of Justice said in this year’s data breach report under “Recommendations”:

“The 20 controls in the Center for Internet Security’s Critical Security Controls identify a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.”

Every senior executive in the modern organization understands that canceling the fire insurance policy on their headquarters building would be a bad idea. You would be one fire away from the end of your career. The same now holds true for IT security. Shareholders and the board of directors now understand that the failure to use reasonable measures to protect data assets is a fundamental failure of governance. Don’t be the executive who has to try to defend that failure!



Tags: System Logging, IBM i

Related Posts Plugin for WordPress, Blogger...

The IBM i, OpenSSL and Security Patching

Posted by Patrick Townsend

alert.pngOpenSSL is one of the most widely used cryptographic applications and libraries. A new group of security vulnerabilities have just been identified for OpenSSL and they need attention right away. IBM i (AS/400, iSeries) customers often feel isolated and protected from the security issues with OpenSSL, but this attitude can lead to trouble. IBM i customers need to monitor for vulnerabilities in OpenSSL and patch their IBM and third-party applications.

IBM uses the OpenSSL application in the Hardware Management Console, or HMC. The HMC is a highly privileged application that can manage many instances of IBM i logical partitions in a customer environment. You should carefully monitor security patches from IBM and apply them to your HMC. You can find IBM’s security alerts and notifications here.

On the IBM i platform itself you should be aware that the PASE environment includes the OpenSSL application. The PASE environment is an AIX emulation environment that is usually present on IBM i customer systems. Since PASE is an IBM licensed program you should apply Program Temporary Fixes (PTFs) to resolve issues with OpenSSL in PASE.

The IBM i no-charge OpenSSH licensed program also contains the OpenSSH application. However, the OpenSSH application does not use OpenSSL for session security. The primary use of OpenSSL in the OpenSSH application is for cryptographic functions. While this reduces the security threat, it does not eliminate it. You should update OpenSSH when they are PTF patches available.

The OpenSSL application is also found in the Linux-like environment of the QSHELL application in later versions of the IBM i operating system. If you use the Start QShell (STRQSH) command you can use the “type openssl” command to determine where it is located. You can view the version of OpenSSL with this command: “openssl version”. As in the above examples, be sure you apply PTFs when there are security notices for OpenSSL.

Lastly there are a number of third-party applications that embed the OpenSSL application. If these third-party applications are not using the IBM-provided OpenSSL libraries, you will need to contact those third party software providers to receive an update. Be sure you carefully review any third party application, open source application or free tool for the presence of OpenSSL. Any application that performs FTP data transfers, implements an inbound or outbound web service, or  communicates with an encryption key management server should be reviewed (see below for a statement about IBM i solutions from Townsend Security).

Here at Townsend Security we have several IBM i security applications that perform secure encrypted TLS connections. None of these applications use the OpenSSL application. Instead we use the native IBM i GSKit library for TLS session security which is configured using the IBM no-charge licensed Digital Certificate Manager (DCM) product. Our Alliance FTP Manager, Alliance AES/400 FieldProc encryption, Alliance Token Manager, Alliance Two Factor Authentication, and Alliance XML/400 solutions are not subject to the OpenSSL security vulnerabilities. Note that our Alliance FTP Manager solution uses the IBM OpenSSH application, so as mentioned above be sure to apply those OpenSSH security updates from IBM if you are using OpenSSH for transfers.

In addition to signing up for IBM i security alerts at the above web site, you can subscribe to US-CERT notifications here.

Hat tip to Alex Woodie for his article on IBM i OpenSSL vulnerabilities. You can find it here.


IBM i Encryption with FieldProc

Tags: IBM i

Related Posts Plugin for WordPress, Blogger...

Creating the IBM Security Audit Journal QAUDJRN

Posted by Patrick Townsend

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."

IBM i Security: Event Logging & Active Monitoring

The QAUDJRN security audit journal does not exist when you first install a new IBM i server. You must create the journal receivers and the journal to start the process of security event collection. As is the case with any journal on the IBM i server you must first create a journal receiver and then create the QAUDJRN journal and associate it with the journal receiver.

The first step is to create a journal receiver which will be the actual container of security events. You can create the journal receiver in a user library or in the IBM general-purpose library QGPL. Creating a library to hold the journal receivers is recommended as this allows more flexible system management. You should use a sequence number in the last four or ve characters of the journal receiver name. This allows the IBM i operating system to automatically create new receivers. You can use this command to create the journal receiver.

   TEXT(’Auditing Journal Receiver’)

Now that we have created the first journal receiver, we can create the QAUDJRN journal. The QAUDJRN journal is always created in the operating system library QSYS. You can use this command to create the journal and associate it with the first journal receiver:

AUT(*EXCLUDE) TEXT(’Auditing Journal’)

Tags: System Logging, IBM i

Related Posts Plugin for WordPress, Blogger...

IBM i Security: Event Logging & Active Monitoring

Posted by Patrick Townsend

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."

Active monitoring and log collection are at the top of the list of effective security controls. IBM i (AS/400, iSeries) users have to solve some special challenges to implement this critical security control. The IBM i server is a rich source of security information. Unlike many Windows and Linux server deployments the IBM i platform can host a complex mix of back-office applications, web applications, and open source applications and services. For convenience we will address these various log sources in terms of primary sources and secondary sources. Primary sources should be given priority in your implementation processes, as the most critical events are likely to be found in primary event sources.

Primary Sources

IBM i Security: Event Logging & Active Monitoring IBM Security Audit Journal QAUDJRN
When configured properly the IBM i server records a wide variety of security events in the security journal QAUDJRN. Events such as password failures, network authentication failures, failed SSL and TLS network negotiations, application and database authority failures, and many others go straight into the security audit journal QAUDJRN. This would naturally be the first focus of your event monitoring strategy. We discuss the setup and configuration of the QAUDJRN journal below.

System History File QHST
The system history message file QHST (actually a collection of files that start with the name QHST) is also a repository of important security information. All job start, job termination, and abnormal job termination events are recorded in the QHST files. Additionally, important operational messages are written to QHST files and should be collected and monitored.

Exit Points
The IBM i operating system provides a number of “hooks” for network and other services on the IBM i platform. These hooks are referred to as exit points. IBM i customers or vendors can write applications that collect information and register them for the exit points. Once registered an exit point monitoring application can collect information on a wide variety of activities. These include information on inbound and outbound FTP sessions, TCP sockets activity, network authentication, administrative commands through Operations navigator, and many other core operating system services. A good active monitoring strategy should collect information from exit points and pass the information to the centralized log collection server.

Secondary Sources

Web Applications
Most IBM i customers do not deploy the server as a primary web server, but selected web applications and services are often incorporated into a customer’s primary web deployment. The IBM i supports a rich set of web server platforms including IBM Websphere, PHP, Perl, Python, and traditional HTML/CGI services. When web applications are deployed on an IBM i server they are a target for traditional attacks. Web logs should be included in your event collection and monitoring strategy.

Open Source Applications
For some years IBM has been bringing a wide variety of open source applications to the IBM i platform. This includes applications like OpenSSH with Secure Copy (sCP), Secure FTP (sFT) and remote command shell. Many other application frameworks have
been added like Perl, PHP, and Python. All of these applications provide entry points and potential points of compromise for attackers. If you deploy these types of solutions you should enabled and collect their logs.

System and Applications Messages in QSYSMSG AND QSYSOPR
Many customer and vendor applications write important operational and security messages to the system operator message queue QSYSOPR and to the optional system message queue QSYSMSG.



Tags: System Logging, IBM i

Related Posts Plugin for WordPress, Blogger...

Privately Held Companies Think They Don’t Need to Worry About Security and Compliance

Posted by Patrick Townsend

In my role at Townsend Security I engage with companies both large and small and have many conversations about data breaches and security. One pattern that I see a great deal is the belief by privately held companies that they are not subject to compliance regulations, are not a target by cybercriminals, and don’t have much to worry about. The feeling seems to be “Gee, we are not publicly traded so we don’t have to do all that security stuff. It’s hard and expensive and it doesn’t really apply to us. Besides, we are too small for hackers to bother with.” I’m sure I’ve heard exactly these comments a number of times.

For the sake of these small businesses who represent the real backbone of our economy, we need to dispel these myths. Let’s look at a few of them:

We Don’t Need to Meet PCI Compliance
Download Whitepaper on PCI Data Security Anyone who takes credit or debit cards in their business must comply with the PCI Data Security Standard (PCI-DSS). When you signed your merchant agreement you agreed to be bound by the data security standards for payment cards. This is not a government regulation - this is an agreement between you and your payment provider and they all require this compliance. It doesn’t matter if you are small or large, privately held or publicly traded on the NYSE. You have to meet PCI compliance for security. Failure to comply with PCI-DSS standards can put you a jeopardy for loss of the ability to accept credit card payments. This can be devastating for any company.

I Only Store a Small Number of Credit Cards, PCI Doesn’t Apply to Me
This is an incorrect understanding of the PCI Data Security Standard. Processing a small number of payment transactions, or a low dollar amount, may put in you a lower category for PCI compliance, but the PCI-DSS still applies to you. In the event of a data breach you may find that you have new on-site PCI audit requirements, additional liabilities, and you may have to pay a higher rate to authorize payment transactions. These effects can really hurt your business. Rest assured that if you take credit card payments the PCI-DSS requirements apply to you.

We Don’t Need to Meet HIPAA Compliance and Reporting
If you are a medical organization defined as a Covered Entity under HIPAA regulations you need to meet HIPAA data security requirements. This includes both privately held as well as publicly traded organizations. There is no exclusion for privately held organizations whether you are a country doctor with a small practice or a large HMO or hospital chain. A quick review of the compliance actions by OCR shows that privately held organizations are just as likely to be fined as larger organizations. And penalties often do not stop at monetary fines, there are often requirements for years of on-site security audits and assessments that are very costly.

We are Not Big Enough to be a Target
Many executives and members of the IT organization at privately held companies believe that they are not a target of hackers and cybercriminals simply because they are privately held and small. This falls into the category of wishful thinking. In fact, as the FBI reports, smaller private companies are increasingly the focus of cybercriminals and are experiencing significant financial losses. Here is what John Iannarelli, and FBI consultant, says:

"Time and again I have heard small business owners say they have nothing to worry about because they are too small to interest cybercriminals. Instead, small businesses are exactly who the criminals are targeting for two primary reasons. In the criminal's mind, why go after large companies directly, when easier access can be attained through small business vendor relationships. Secondly, since small businesses have less financial and IT resources, criminals know they are less 'compromise ready' and tend to be less resilient."

We Don’t have to Report a Data Breach
Many smaller privately held companies are under the mistaken impression that compliance laws do not require them to report a data breach. This is incorrect - state and federal laws that require data breach notification require small businesses and privately held companies to report data breaches. Being small or privately held does not exclude you from data breach notification.

Compliance Regulations Don’t Apply to Us
It is true that if you are a private company the Sarbanes-Oxley compliance regulations certainly do not apply to you, those regulations only apply to publicly traded companies. And the Federal Information Security Management Act (FISMA) does not apply to you because it only applies to US government federal agencies. You are, however, covered by state privacy law, PCI Data Security Standards (if you accept credit or debit cards), HIPAA if you are a Covered Entity in the medical segment or if you process patient data for a Covered Entity, and the Federal Trade Commission (FTC).

We are Not Under FTC Rules About Data Privacy
The Federal Trade Commission has a broad charter to protect consumers and this includes enforcement for consumer privacy. From large companies like Google, Facebook and Twitter to small companies like an auto dealership, the FTC has taken enforcement actions that include private companies. The enforcement actions can include fines, mandatory audits that last for many years, and other penalties. Private companies do fall under FTC jurisdiction. You can read more about the FTC and data privacy here.

In summary, smaller privately held companies are the target of cybercriminals, are less prepared to deal with an attack, and have fewer resources to recover from an attack. No competent executive in a privately held company would forgo general liability insurance for their business, but are much more likely to suffer a loss from a cyber attack. It is not good business sense to ignore real threats.

Some last thoughts from the FBI:

The criminal then either creates another account or directly initiates a funds transfer masquerading as the legitimate user. The stolen funds are often then transferred overseas. Victims of this type of scheme have included small and medium-sized business, local governments, school districts, and health care service providers.

The potential economic consequences are severe. The sting of a cyber crime is not felt equally across the board. A small company may not be able to survive even one significant cyber attack.

From a Washington Post interview with the FBI:

Federal agents notified more than 3,000 U.S. companies last year that their computer systems had been hacked, White House officials have told industry executives, marking the first time the government has revealed how often it tipped off the private sector to cyberintrusions.

The alerts went to firms large and small, from local banks to major defense contractors to national retailers such as Target, which suffered a breach last fall that led to the theft of tens of millions of Americans’ credit card and personal data, according to government and industry officials.

“Three thousand companies is astounding,” said James A. Lewis, a senior fellow and cyberpolicy expert at the Center for Strategic and International Studies. “The problem is as big or bigger than we thought.”

Others notified by the Secret Service last year included a major U.S. media organization, a large U.S. bank, a major software provider, and numerous small and medium-size retailers, restaurants and hotels, officials said.

“Within hours of us coming up with information that we can provide, we would go to a victim,’’ said Edward Lowery, Secret Service special agent in charge of the criminal investigative division. “The reaction would be just like when you’re told you’re the victim of any crime. There’s disbelief, there’s anger, all those stages, because there’s a lot at stake here.”

Yes, Indeed. There is a lot at stake.

download the Whitepaper: Meet the Challenges of PCI Compliance

Tags: Compliance, PCI DSS

Related Posts Plugin for WordPress, Blogger...

How Do I Find and Start Alliance Key Manager for Encryption Key Management in AWS?

Posted by Patrick Townsend

For Amazon Web Services (AWS) users, encryption and key management has never been easier.  Townsend Security's Alliance Key Manager uses the same FIPS 140-2 compliant key management technology found in the company's HSM and in use by over 3,000 customers worldwide. In the AWS Marketplace, there are two entries for Alliance Key Manager – one is for the fee-based implementation and one is for the Bring Your Own License (BYOL) implementation. Both are identical in their key management functionality. If you only need one or two instances of Alliance Key Manager you can use the fee-based entry in the marketplace. If you are going to use more than a couple of instances of the key manager you may want to use the Bring Your Own License entry to launch the key manager. There are discounts available for multiple instances of Alliance Key Manager and the BYOL version may be less expensive.

How to Meet Best Practices for Protecting Information in AWS by Stephen Wynkoop If you are logged into your AWS account you can directly launch Alliance Key Manager from the marketplace. Both licensing models support a free 30-day license to use the key manager. 

Before launching, you should determine if you want to run the key manager in the public AWS cloud, or if you want to run the key manager in a virtual private cloud (VPC).  The AWS virtual private cloud platform provides more isolation from other cloud customers and therefore a bit more security, if that is desired.

As you launch Alliance Key Manager in the AWS cloud you will need to select a region in which to run the key manager. Alliance Key Manager supports all of the AWS regions and you can run it anywhere. Your choice of regions may reflect your estimate of where you will have the greatest demand, or where you want critical key material to reside.

Once your AWS instance of Alliance Key Manager has been launched you can open an SSH session to the key manager to perform initial set up. You will change your password, create a set of server and client PKI certificates, indicate whether this instance of the key server is a primary or secondary mirror server, and create some initial unique encryption keys. After answering these questions you will have a fully functional, dedicated EC2 instance of Alliance Key Manager ready to use.

Alliance Key Manager comes with a full suite of software development kits (SDKs) and documentation, but the marketplace is limited to three documents. After you launch your AWS instance of the key manager please contact Townsend Security to register and get access to the AKM Supplemental documentation.  Unless you register at the Townsend Security web site it will not be possible to contact you and send you the documentation. There is no charge for access to the documentation.

The AWS license comes with customer support at the Basic level. This provides technical support and software updates via email during business hours. A Premium Support options is available that provides telephone and web support and includes 24/7/365 support for business interruption issues. Please visit the Townsend Security web site for more information about the Premium Support option and to register your instance of Alliance Key Manager for AWS.

At Townsend Security we want to provide you with a positive experience with our key management products and provide you the support you deserve. When you run our Alliance Key Manager in AWS we won’t know who you are because Amazon does not report that information. By registering at the Townsend Security web site you get access to documentation, SDKs and free support. And we can keep you up to date on the latest security patches and enhancements!

You can find more information about Alliance Key Manager in AWS here.

How to Meet Best Practices for Protecting Information in AWS by Stephen Wynkoop


Tags: Alliance Key Manager, Amazon Web Services (AWS)

Related Posts Plugin for WordPress, Blogger...

Encrypted Indexes - Overcoming Limitation with FieldProc Encryption on the IBM i

Posted by Luke Probasco

Excerpt from the eBook "IBM i Encryption with FieldProc - Protecting Data at Rest."

Encrypted Indexes

The DB2 FieldProc implementation fully supports the encryption of columns which are indexes (keys) to the data in a native SQL context, and this includes RPGSQL applications. However, there are some severe limitations with legacy RPG and COBOL applications around encrypted index order. It is important to understand these limitations if you are approaching FieldProc with a large inventory of legacy applications.

IBM i Encryption with FieldProc Legacy RPG applications use record-oriented operations and not set-oriented operations that are typical of SQL. Many record oriented operations in RPG will work as expected. For example, a CHAIN operation on an encrypted index to retrieve a record from a DB2 table will work. If the record exists it will be retrieved and FieldProc will decrypt the value. However, many range and data ordering operations will not work as expected with legacy RPG programs. Consider the following logic:

SETLL (position to an particular location in the index for a file)
WHILE (some condition)
READ (Read the next record by the index) END WHILE

The SETLL (Set lower limit) operation will probably work if the particular index value exists. However, the program logic will then read the next records based on that position in the file. IBM i developers are surprised to learn that they will be reading the next record based on the ENCRYPTED value, and not on the decrypted value which is what they might expect. The result is often empty subfiles and printed reports. This is very common logic in applications where indexes are encrypted. Note that your RPG program will not get a file I/O error, it just won’t produce the results you expect.

In simpler applications this side-effect of encrypted indexes is not significant, or easily programmed around. However, in some applications where sensitive data is encrypted across a large number of tables (think social security number in banking applications) this can be a significant limitation.

Don’t despair, keep reading.

Overcoming Encrypted Index Limitations in RPG

The limitations of encrypted indexes in legacy RPG applications often lead IBM i customers to abandon their encryption projects. The prospect of converting a large number of legacy RPG applications to newer SQL interfaces can be daunting. Their legacy RPG applications contain a lot of valuable business logic, and the effort to make the conversion can be quite large.

Wouldn’t it be great if you could wave a magic wand and make legacy RPG applications use SQL without any changes?

IBM opened a path to this type of solution with Open Access for RPG, or OAR. OAR allows for the substitution of traditional file I/O operations with user- written “Handlers”. In essence, you can replace the native file I/O operations of RPG with your own code. No change to program file handling or business logic! The OAR capability spawned a number of user interface modernization products, and other solutions that take advantage of this. Imagine if your RPG screen handling I/O with Execute Format (EXFMT) could be replaced with a web-based GUI library. Instant modernization of the UI! There are now many solutions that leverage OAR for UI modernization.

Join Logical Files with DDS

One limitation of logical files created with DDS specifications involves join logical files. You will not be able to create DDS join logical file where the join involves an encrypted  eld with FieldProc. You will get an error about invalid data type usage. This is an IBM limitation and there is no known workaround for this issue. Note that this limitation only applies to DDS join logical  les and does not apply to SQL joins using encrypted indexes. Most IBM i customers will need to change their RPG or COBOL program logic to avoid the use of DDS join logical  les which use encrypted indexes.

Application Changes

Legacy RPG applications that use encrypted indexes often need re-design and re-programming to avoid the problems of encrypted indexes. You can avoid these issues if you are using an Open Access for RPG (OAR) solution that maps the legacy RPG record-based file operations to native SQL and the SQL Query Engine (See the note above about Townsend Security’s OAR/SQL offering).

If you need to re-design your RPG applications to avoid encrypted indexes consider putting all of your sensitive data in a table that is indexed by some non-sensitive value such as a sequence number or customer number, and use FieldProc to encrypt that table. There are many approaches to application re- design and you should be able to find a method that works for you.

Change Management

IBM i customers who have deployed change management solutions can encounter challenges with FieldProc implementations. While most of these challenges are surmountable, it will take effort on the part of the systems management team to integrate FieldProc controls into their change management strategy. Unfortunately the implementation of FieldProc does not provide much in the way of support for change management systems. The activation of FieldProc changes an attribute on the column in the table, but change management systems generally are not aware of this attribute. It can be challenging to promote table and column level changes and properly retain the FieldProc attribute of the data. Look for a FieldProc implementation that provides a command-level interface to stop, start, and change FieldProc definitions. These commands can help you integrate FieldProc encryption into your change management strategy.

IBM i Encryption with FieldProc


Related Posts Plugin for WordPress, Blogger...

How Do I Encrypt Data and Manage Encryption Keys Using Java in Amazon Web Services (AWS)?

Posted by Patrick Townsend

If you are a Java developer you probably know that the Java language has full native support for AES encryption. You don’t need any third-party SDKs or add-ins to Java to use industry-standard, strong encryption. The standard Java APIs are based on industry standards and are very efficient. Don’t hesitate to use that built-in facility. You include it in your Java application like this:

import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;

Protecting Encryption Keys in AWS Encryption key management is another story. To implement good encryption key management you will need to turn to an enterprise key management solution and their Java library to make this happen. Our Alliance Key Manager for AWS solution provides a Java SDK to help you with encryption key use. The Alliance Key Manager Java SDK lets you easily retrieve an encryption key for use in your application, or alternatively to send data to Alliance Key Manager on a secure connection where the encryption or decryption task can be performed directly on the key server. This encryption service is helpful in situations where you don’t want to expose the encryption key in your application or server environment.

Many developers use the Java Keystore (JKS/JCEKS) facility for storing encryption keys. The Java key store is more a key storage facility rather than a key management facility and rarely meets compliance regulations for separating keys from the data they protect, providing for separation of duties, and dual control. If you are currently storing encryption keys in a JKS repository you may want to consider moving them to true key management solution like Alliance Key Manager.

One of the advantages of the Alliance Key Manager SDK is the built-in high availability failover facility. By using the Alliance Key Manager SDK in the event of a network or other failure you automatically fail over to a secondary HA key server in real-time. This means your application keeps running even though a network or system error prevents access to the primary key server.

The Java SDK for Alliance Key Manager includes all of the support needed to make a secure connection to the key server, retrieve an encryption key, access the encryption and decryption services on Alliance Key Manager, and perform other common functions. By using the SDK the Java developer can avoid writing all of the code needed to perform these tasks – the work needed to retrieve an encryption key is reduced to a few lines of code.  We think this is a big bonus for the Java developer and helps make their lives easier. And sample source code will really speed along the process.

Here is an extract of the sample source code showing the retrieval of an encryption key from Alliance Key Manager, an encryption of some plaintext, and the decryption of that ciphertext:

// Note: Full sample source available (this is just an extract)

import javax.crypto.Cipher;

import javax.crypto.spec.IvParameterSpec;

import javax.crypto.spec.SecretKeySpec;

import com.townsendsecurity.akmcore.AkmException;

import com.townsendsecurity.akmcore.AkmUtil;

import com.townsendsecurity.akmcore.AkmRequest;

import com.townsendsecurity.akmkeys.AkmKeyRequest;

import com.townsendsecurity.akmkeys.AkmSymKey;

// The AKM configuration file

String sCfgFile = "/path/jakmcfg.xml"

// Create a key request object initialized from the configuration file

AkmKeyRequest keyRQ = null;

keyRQ = AkmKeyRequest.getInstance(sCfgFile);

// Define the key instance (version) name

String sInstance = "some-name"

// Retrieve the encryption key from Alliance Key Manager

AkmSymKey symkey = null;

symkey = keyRQ.retrieveSymKey(sKey, sInstance);

// Create a context

EncryptDecryptCBC cryptor = new EncryptDecryptCBC(symkey.getKeyBytes());

// Let’s encrypt some plaintext

byte[] ciphertext = null;

ciphertext = cryptor.encryptSymmetric(plaintext.getBytes());

// Let’s decrypt the ciphertext

byte[] plainbuf = null;

plainbuf = cryptor.decryptSymmetric(ciphertext);

There is no charge for the Java SDK and all Alliance Key Manager customers have access to the Java SDK and sample code. AWS customers must register on the Townsend Security web site to get access to the Java code. You can do that here.

Protecting Encryption Keys in AWS

Tags: Alliance Key Manager, Amazon Web Services (AWS), Encryption Key Management, Enryption

Related Posts Plugin for WordPress, Blogger...