Townsend Security Data Privacy Blog

Data security in Drupal is a top concern. Townsend Security recently launched our Drupal Developer Program to engage Drupal developers in building stronger, more secure websites, and to give back to the Drupal community by creating a collaborative network of Drupal developers concerned with data security and compliance regulations. Members of the Drupal Developer Program gain free access to Alliance Key Manager, our FIPS 140-2 compliant cloud key manager, as well as NIST-validated AES onboard encryption, for non-production testing and development.

Many Drupal developers today run up against tricky situations when developing websites that collect sensitive data such as payment card information, personally identifiable information (PII), and user passwords--not just commerce information. Developers are asking themselves, “what compliance regulations do I face”, “which data needs to be encrypted”, and “how do I do encryption and key management right to meet compliance?”

With Key Connection for Drupal, an API designed to offboard encryption keys to a secure key server, encryption and key management is made easier than ever.  Now Drupal developers can join the Drupal Developer Program and learn how to do encryption and key management right.

Here are the top reasons to consider joining the Drupal Developer Program:

1. Encryption and key management is critical to effective data security in Drupal website development.
Today, Drupal is a top CMS for all kinds of websites. Some of these websites, such as commerce, health, and government websites collect sensitive data from users that must be encrypted under compliance regulations such as PCI, HIPAA and FISMA. These compliance regulations also have clear language strongly recommending, if not requiring, encryption and key management.
As Drupal developers take on larger clients, these compliance regulations become a greater concern. Historically, the Encrypt module could be used to encrypt any sensitive data collected; however, there was no adequate means to protect encryption keys. Today, with Key Connection for Drupal, developers can help their clients manage encryption keys away from encrypted data on a secure key server and create websites that effectively protect sensitive data.

2. Learn how to encrypt sensitive data and properly manage encryption keys
In the last year, many of the largest data breaches could have been avoided if proper encryption and key management was implemented. Within the Drupal Developer Program, Drupal developers can learn how to implement encryption and key management into their projects from the ground up. Encrypting and management encryption keys is actually quite easy now in Drupal, and learning how to use these tools will prepare Drupal developers for larger projects that require strong data security.

3. Implement strong data security in your web development projects from the ground up
Adding data security after-the-fact is difficult. Building your websites and applications using strong encryption and key management from the ground up prevents data security projects from turning into a massive headache. The Drupal Developer Program allows developers to test encryption and key management in their projects from the start to avoid a complicated project down the road.

4. Build your knowledge of compliance requirements and help to educate your colleagues
Our Drupal Developer Program is designed to educate developers on encryption and key management best practices as well as any compliance regulations you may face. We continuously offer resources to help you learn what you need to know to meet PCI DSS, HIPAA, GLBA/FFIEC, FISMA, and other compliance regulations, as well as state privacy law requirements.

5. It’s free!
There’s no charge to join our Drupal Developer Program. With free access, we hope to give Drupal Developers the freedom to learn about, test, and implement strong encryption and key management so that you will become a security thought leader in your own organization!

Amazon Web Services is a deep and rich cloud platform supporting a wide variety of operating systems, AWS services, and third party applications and services. It is a bewildering array of capabilities with lots of places to store sensitive data. Let’s explore some of the ways that our Alliance Key Manager solution helps AWS customers and partners protect this data. This is a bird’s eye view, and we’ll dive into this in more depth in future blogs:

Amazon AWS Services

Amazon Relational Database Service (RDS)
Alliance Key Manager provides encryption key retrieval and an on-device encryption service to make it easy for your applications to encrypt data in RDS. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon Simple Storage Service (S3)
Alliance Key Manager lets you retrieve 256-bit AES keys in Base64 encoded format ready for use with RDS customer supplied encryption key services. You can easily deploy an AKM dedicated key management service to support encrypting and decrypting files in S3 storage.

Amazon Elastic Block Storage
Amazon Machine Instances (AMIs) provide access to EBS for simple unstructured storage requirements. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon DynamoDB (NoSQL)
The AWS NoSQL implementation does not provide encryption services, but you can easily implement encryption at the application layer using the Townsend Security SDKs. With support for many programming languages you can implement the encryption and key management services you need to meet compliance regulations.

Application Databases:

Microsoft SQL Server
Alliance Key Manager includes a license for Townsend Security’s Key Connection for SQL Server application that supports Transparent Data Encryption (TDE) and Cell Level Encryption for Enterprise edition. This EKM provider installs in your Windows SQL Server environment and enables encryption without any programming. For SQL Server Standard and Web Editions Alliance Key Manager includes a license for the Townsend Security Windows Client for snap-in encryption support.

Oracle Database
Oracle Database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in Oracle environments. Sample PL/SQL code is also available for Oracle Linux platforms.

MySQL, SQLite, PostgreSQL, etc.
Open source database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in these environments.

Software SDKs for Amazon Web Services:

A rich set of application SDKs are available for many programming languages. These SDKs provide support for Java, Microsoft .NET languages (C#, VB.NET, etc.), Perl, Ruby, Python, PHP, and others. These SDKs are provided at no charge to Alliance Key Manager customers.

Application Plugins for Amazon Web Services:

Drupal Encryption and Key Management
Alliance Key Manager integrates naturally with the Drupal web CMS using the Drupal Encrypt module and Townsend Security’s Key Connection for Drupal module available on Drupal.org. Drupal users can retrieve encryption keys for use with local encryption, or use the Alliance Key Manager Encryption Service to encrypt and decrypt data in the key manager with NIST-validated AES encryption.

SQL Server Transparent Data Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Transparent Data Encryption (TDE) support using the Townsend Security Key Connection for SQL Server application.

SQL Server Cell Level Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Cell Level Encryption support using the Townsend Security Key Connection for SQL Server application.

Encrypting data in Microsoft SQL Server is easy to do, yet often difficult to understand because of the different encryption options offered in various versions.

It used to be said that “encryption is the hardest part of data security, and key management is the hardest part of encryption”. While that may have been true a few years ago, we are constantly working to make affordable, easy-to-use, defensible solutions that meet security best practices and industry compliance regulations. Separating and managing the encryption keys from the data they protect is still one of the biggest challenges in terms of doing an encryption project right, so let’s take a look at what encryption & key management options are available for SQL Server users.

If you are running the Enterprise Edition of SQL Server, version 2008 or newer, you have access to Microsoft’s architecture for encryption called Extensible Key Management (EKM). This provider interface allows for third-party key management systems to be easily incorporated in order to separate encryption keys from the encrypted data they protect. A key management solution should provide Windows client libraries, guidance, and sample code within the solution.

The SQL Server EKM architecture supports:

Transparent Data Encryption (TDE)
With TDE, the entire database table (including the logs you are collecting) is encrypted.  It is a very easy mechanism to use for encryption and since it is transparent, no application level changes are needed, it only takes a few commands to implement. TDE protects data at rest, including backups and log files.

Cell Level Encryption
Also known as column-level encryption, this allows for you to selectively encrypt certain columns of information in your database. This option makes sense if you have large databases of information, and only access encrypted columns periodically.

If you are running older versions of SQL Server (pre-2008), or using non-enterprise editions such as standard, web, or express; you do not have access to TDE or EKM. You still have good options for protecting your data with encryption, just remember the encryption key needs to be separated from the encrypted data it protects.

When you don’t have the EKM architecture, another option for encrypting data in your SQL Server database is to perform encryption and decryption at the application layer using .NET-based encryption. All editions of SQL Server support the ability to perform encryption from within the .NET framework with very straightforward code functions.

C# and VB.NET Application Encryption
If you are developing in .NET you only need to plug in the client side application and implement a few lines of code for your encryption and decryption calls.

Column Level Encryption
Another approach would be to combine User Described Functions (UDFs) with triggers and views to help automate the encryption and decryption at the column level.

Moving SQL Server Data to the Cloud

As more companies migrate their applications and data to the cloud, there are security issues to consider before making that move. Microsoft Azure SQL Database (MASD) -which has also been called SQL Azure, SQL Server Data Services, SQL Services, Windows Azure SQL Database- is a cloud-based service from Microsoft offering database capabilities as a part of the Azure Services Platform. The service is easy to use and readily available, just know that there are some constraints and some features of EKM that are not available when using MASD.  

Most businesses migrating to the cloud will choose to run virtual machines that contain the Windows OS and a full implementation of the SQL Server database. By using a virtual machine, encryption and key management, including EKM with TDE, can be fully supported and provide the level of security you expect and compliance regulations require!  

You have many options still available for your key management solution when your data has been moved to the cloud. Our NIST validated, FIPS 140-2 compliant Alliance Key Manager solutions are available as:

• Hardware Security Module (HSM) - a hardened appliance that you can rack up in your own data center
• Cloud HSM - dedicated hardware device in our hosted cloud environment
• VMware - deploy as a virtual appliance
• Cloud - deploy in Windows Azure, Amazon Web Services, or IBM Cloud as a standard cloud instance or virtual private cloud

To learn more about encrypting data on SQL Server, managing encryption keys, and how we are helping companies protect their data with Alliance Key Manager, download the podcast on Encryption Options on SQL Server.  

Security is the biggest barrier to cloud adoption, and encryption of sensitive data is the hardest part of security. Once you decide to encrypt your sensitive data, getting encryption key management right is the biggest challenge. Storing an encryption key in the same cloud instance with the protected data is faux security, and won’t pass the sniff test in any audit or review of security best practices. So, where do you store the encryption keys?

In Amazon Web Services (AWS), you now have a new key management option that perfectly fits the AWS architecture and usage model, enables security best practices such as Separation of Duties and Dual Control, and provably meets industry standards such as FIPS 140-2.

Alliance Key Manager for AWS extends our Cloud Service Provider support to the popular Amazon platform alongside our existing cloud support for Microsoft Azure, IBM Cloud, and VMware vSphere cloud platforms. For cloud users who need dedicated key management HSMs, our existing Alliance Key Manager Cloud HSM solution will serve AWS customers.

Alliance Key Manager for AWS uses the same FIPS 140-2 compliant technology as our network-attached hardware security module (HSM) solution. You can deploy the Alliance Key Manager AMI directly from the AWS Marketplace, and have a functional encryption key management solution dedicated to you and ready to use in SECONDS with an automatic 30-day evaluation license. You do not share any part of your key management with anyone else, and you have exclusive management of encryption keys. There is no aspect of key management administration that is under the control of Townsend Security, the cloud provider, or anyone else. There is no part of your encryption key that is shared with Townsend Security, and no dependence on any encryption service outside of your key management AMI.

Customers who register with Townsend Security get access to our encryption applications, SDKs, customer support, extended documentation, developer program, and optional Premium support. It’s the perfect AWS key management solution for both small organizations and large enterprises who want to deploy an affordable key management solution based on industry standards and certifications.

In addition to traditional key management, Alliance Key Manager for AWS implements Encryption-as-a-Service. You don’t have to retrieve an encryption key, perform encryption in your application, and then zero the encryption key. To minimize the chance of exposing the encryption key to loss, you can directly send data to the key manager and have it encrypted and returned to your applications. You leverage Alliance Key Manager’s NIST-validated AES encryption and the key never leaves the key manager.

Until now Amazon Web Service customers had no access to simple, affordable, and compliant encryption key management solutions. All of that has changed with Alliance Key Manager for AWS.

Enjoy.

Patrick

Implementing strong data security to protect sensitive data is a top priority for many businesses. Not only does processing and storing sensitive data put you at risk for data loss or breach, it also means that you must meet certain industry regulations and possibly undergo periodic data security audits. Encryption and key management is required if not strongly recommended by many industry regulators such as the Payment Card Industry (PCI) and HIPAA; however, these technologies have a reputation for being difficult, costly, and causing severe impact on server or application performance.

Today this reputation doesn’t holds true, and these common fears can, in fact, get in the way of implementing a strong security solution.

Fear #1 : Encryption & Key Management Will Affect Performance On My System and Applications
One of the most common fears about encryption and encryption key management is that encrypting data will severely impact system performance. It’s true that encryption will have some impact on performance, but if done right, encryption should should never impact your performance more than 2-4%. Performance impacts can also vary based on the amount of data you’re encryption and whether you’re doing whole disk, column and field level, or application level encryption. Because encrypting data at any level is difficult to get right, many organizations who attempt “do-it-yourself” encryption solutions see a much higher performance impact.

Application level encryption is considered the best way to encrypt sensitive data as well as the most difficult. Within an application, an administrator can be selective about which types of data should be encrypted, and which data can be stored in the clear. Therefor the encryption is targeted and only performed on necessary data, which reduces overall performance impact. If done properly, application level encryption will not interfere with your applications.

Fear #2: What if I Lose an Encryption Key?
While the fear of losing a key is legitimate, the keystone of a successful encryption solution is encryption key management, which is the primary solution for managing, storing, and most importantly, protecting encryption keys. Unlike a “key storage” solution, a cryptographic encryption key manager is typically a NIST FIPS 140-2 compliant hardware security module (HSM) or virtual machine in the cloud that manages key storage, creation, deletion, retrieval, rotation, and archival. Many key management solutions are also produced in pairs, with one located in a different geographical location for high availability. If doing encryption key management right, you will never lose an encryption key.

Fear #3: Encryption Key Management Is Too Expensive
Perceived cost is a common barrier for many organizations. However, cutting corners and choosing a third-rate solution is a lot like choosing the cheapest and least reputable car insurance policy: it might get you through the day, but should you ever have an accident, you’ll deeply regret it. Data breaches are no longer a matter of “if,” but “when,” and when a breach happens, it might be the kind that costs you your entire business. Luckily, strong, certified encryption key management solutions are becoming less costly as demand rises and data moves to the cloud. Cost should never be a barrier to good security, and choosing a subscription-based cloud key management solution might be your best way to overcome any cost barriers.

Fear #4: My IT Staff is Too Small
Another common fear is that an organization’s IT department is too small to handle a project like implementing encryption and encryption key management. Encryption key management has a reputation for being incredibly difficult to implement, and many administrators assume that the time and manpower that must be diverted to complete an encryption key management project isn’t worth doing the project at all.

Although this reputation held true ten years ago, encryption key management today has become so simple that in many scenarios can be implemented in less than ten minutes. Of course, ease of implementation always varies depending on your IT infrastructure, platforms, and applications; however, a reputable encryption key management vendor knows that IT departments vary and can work with a variety of platforms in multi-platform environments.

To learn more about encryption key management, download the eBook, Encryption Key Management Simplified.

Understanding Options and Responsibilities for Managing Encryption in the Microsoft Azure Cloud

In this latest white paper, authored by Stephen Wynkoop (SQL Server MVP, Founder & Editor at SSWUG.ORG), Stephen will address how “data at rest is data at risk”, specifically looking at the Microsoft Azure Cloud as a selected platform.  The author covers a wide array of information, and discusses in detail how critical it is to do the important work of protecting information in a way that works both with your applications and with the compliance regulations & requirements that impact your company and industry.

Each of the key topic areas below are addressed in detail in the white paper:

Architecture Decisions Drive Technology Approach

The options range from fully-managed data storage and access (Windows Azure SQL Database, WASD) to setting up a SQL Server with a Virtual Machine instance. Each certainly has its place, but there are big differences in options they support.

• Virtual Machines
• Key Decision Points, VMs
• Windows Azure SQL Database  (WASD)
• SQL Server and Data Encryption Choices

Impact of Encryption

Encryption, and the impact of encryption on your systems, is a big area of concern for those deploying it. Three different areas are important to consider when impact on systems is considered.

• Performance
• Backup and Restore Operations
• High Availability

Key Management Fundamentals

There are core best practices to consider while you’re deploying your selected solution. Some are procedural while others are software/hardware implementations. Keep in mind that the key is to protect your most important secret: the encryption keys. You must provide for protection of the encryption keys, while still providing for access, updates and rotation (key management) of those encryption keys throughout their lifecycle.

• Segregation of Duties
• Dual Control & Split Knowledge
• Key Rotation
• Protection of Keys
• Access Controls and Audits, Logging

The author also covers how Townsend Security’s Alliance Key Manager provides answers to these challenges of working with the Microsoft Azure Cloud, securing information with encryption, and the critical need to manage the keys. For more information on Alliance Key Manager for Windows Azure, download our solution brief or get started with a complimentary 30-day evaluation

Author Bio: Stephen Wynkoop

Stephen Wynkoop is the founder and editor for SSWUG. ORG – the SQL Server Worldwide User’s Group where he writes a column and maintains the site overall. SSWUG features a weekly video programs about the database and IT world, webcasts, articles, online virtual community events and virtual conferences several times a year. Stephen is a Microsoft SQL Server MVP and the author of more than 10 books, translated into at least 7 languages. Stephen has been working with SQL Server since the very first version, with a prior experience in database platforms that included dBase and Btrieve. Stephen can be contacted at swynk@sswug.org.

Is there more to encryption key management than just storing my encryption keys?

There is far more to encryption key management than just storing the encryption key somewhere… as it turns out, there is a whole encryption key lifecycle that is (or should be) handled by a certified encryption key management solution. Generally, a key storage device only provides storage of the encryption key, and you need to create the key elsewhere. Also, just storing your encryption keys “somewhere” doesn’t work very well for compliance regulations. With an encryption key manager, there is a whole set of management capabilities and a suite of functions that provide dual control, create separation of duties, implement two factor authentication, generate system logs, and perform audit activities, along with managing the key life cycle (including storage). There is a very real need, and very specific guidelines that require you to store and manage your encryption keys away from the data that they protect.

The Encryption Key Life Cycle

Beyond storing the encryption key, a cryptographic key manager manages the entire key life cycle. Some of the most important functions the key management administrator performs are the actual creation and management of the encryption keys. The keys are generated and stored securely and then go through the full cycle to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase). Let’s take a closer look at the phases of a key life cycle and what a key management solution should do during these phases:

Key Generation & Pre-Activation:
First, the encryption key is created and stored on the key management server (which can be a hardware security module (HSM), virtual environment (VMware) or a true cloud instance). The key can be created by a sole administrator or through dual control by two administrators. The key manager produces the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key storage database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. The key manager should also be able to create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager should also track current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Your key manager should allow the administrator to change many of the key’s attributes at any time.

Key Activation through Post-Activation:
The key manager should allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It should also seamlessly manage current and past instances of the encryption key. For example, if a key is rolled every year and the version is updated, then the key manager should retain previous versions of the key but dispense only the current instance for encryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. The key manager should use transport layer security (TLS) connections to securely deliver the encryption key to the system and user requesting it, which prevents the key from being compromised. The encryption key manager will also expire the key either through a previously established schedule or manually by an administrator.

Key Expiration & Revocation (Escrow):
An administrator should be able to use the key manager to revoke or deactivate a key so that it is no longer used for encryption requests. In certain cases the key can continue to be used to decrypt data previously encrypted with it, like old backups, but even that can be restricted. A revoked key can, if needed, be reactivated by an administrator, although this would be more an exception to the rule than common practice.

Key Destruction:
If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key storage database of the encryption key manager. The key manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a restore from a backup image). This should be available as an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure since it would be impossible to recreate the encryption key for that data.

Crypto Period:
This encryption key life cycle, which is defined by the National Institute of Standards and Technology (NIST), also requires that a crypto period be defined for each key.  A crypto period is the length of time that a key should be used and is determined by a number of factors based on how much data is being protected and how sensitive that data is. While NIST has defined and provided some parameters on how to establish crypto periods (see special publications 800-57 - there are 3 parts) and provided guidance on best practices. Each key management administrator needs to determine how long a particular encryption key should be actively used before it is rotated or retired.

These are a few of the factors that go into establishing the crypto period for a key (which maybe a few days or weeks or longer up to one or two years it really depends on the data that you're trying to protect):

• How is the data being used
• How much data is there
• How sensitive is the data
• How much damage will be done when the data is exposed or the keys are lost

You can see that there is a significant difference between a key storage device and an encryption key management solution. Remember to always look for NIST validated and FIPS 140-2 compliant solutions to meet compliance requirements and follow security best practices!

To learn more about encryption key management download our ebook on Encryption Key Management Simplified.

 

Security can be hard, expensive, complicated, aggravating, confusing, and did I mention expensive?

As a security company, we hear this perception from new customers all the time. But there is one thing you can do for your IBM i that breaks all of these stereotypes. You can get an immediate boost in system security without much expense and without a big headache. And your users are already using this security technique on their favorite web sites.

Increase Security with Two Factor Authentication (2FA)

Almost every day a phishing email gets through our spam filters and lands in my inbox. Some of these emails are very nicely crafted and look like the real thing. The graphics are professional, the English is excellent and matches my expectations. The terminology is appropriate. Really nice work. And the links in the email are pure poison. Just waiting for that unsuspecting click to start installing malware on my PC to capture my IBM i user profile and password information.

Yup, that’s how it started at Target.

The great thing about Two Factor Authentication is that it gives businesses a lot of additional security for very little upfront cost. The aggravation factor has almost gone away. You no longer need large, expensive servers and tokens that always seem to get lost at just the wrong time. Your IBM i can do exactly what Google, Yahoo, Facebook, your bank, and many other Internet companies are doing to make security better. And your users already have the device they need - their mobile phone!

Alliance Two Factor Authentication uses the same network services and infrastructure that the big boys use for 2FA. This security solution leverages the Telesign global network to deliver PIN codes right to your mobile phone. No servers to rack up and maintain. No lost tokens.

I know, you have some reservations:

I don’t always have signal to my cell phone.

That’s OK, just send the PIN code to your voice phone. A nice lady will read you the code.

I’m in a hurry, I can’t wait for a PIN code.

PIN codes are often delivered in under a second. If you’ve got a mobile provider with a slow network, just have the PIN code delivered to your mobile phone as a voice call.

I left my cell phone home!

Right, just use one of your One Time Codes. No phone of any kind needed!

My IBM i is in Restricted State, it won’t work for me.

Alliance Two Factor Authentication does work in restricted state with a couple of steps.

I don’t want to have to enter a PIN code every time I log on, that’s just way too much work.

Don’t worry, your security administrator can configure Alliance Two Factor Authentication to only ask you once a day to authenticate, or at a user-defined interval. And if an attacker tries to access the IBM i from another device or IP address, they will have to authenticate. And that’s going to be hard to do when you have your mobile phone in your possession.

We’ve made Alliance Two Factor Authentication easy to evaluate and deploy on your IBM i. You can request a free 30-day evaluation from our web site and be up and running within an hour. You can start slowly with a few users, and then roll it out to everyone in your organization. They’ll get it right away.

You don’t have to be the next Target. Get cracking (so to speak).

Patrick

Encryption and key management continue to be perceived as challenges for .NET developers as more compliance regulations and state laws require the physical separation of encryption keys from the data they protect.

In the past, .NET developers might have used the Windows DPAPI to store encryption keys, or might have stored them in a SQL Server database. That approach does not meet the requirements for dual control, separation of duties, and split knowledge required by security best practices and compliance regulations such as PCI DSS, HIPAA/HITECH, GLBA/FFIEC, and others.

Historically, Microsoft .NET developers expected to experience some heartburn with an encryption key manager because:

• Key management vendors were historically not responsive to the needs of a .NET developer and failed to provide interfaces that work naturally in this environment
• Complex DLL implementations required special .NET wrapper code
• Poor integration with the existing .NET encryption APIs
• The absence of quality sample code which made life difficult for the Microsoft  .NET developer or slowed down application development

There have been a lot of changes that now make it easier on Microsoft .NET developers to approach encryption and key management. A key manager solution should:

• Provide a .NET assembly key retrieval library that integrates naturally in all of the Microsoft development languages.
• Provide for key retrieval directly into .NET applications so that developers can use the native .NET encryption libraries.
• By not forcing server-based encryption or the use of special encryption libraries, you decide the best approach to encryption once an encryption key is retrieved to the application (this approach also supports Microsoft’s Managed Code architecture)
• Offer vetted sample code to help speed development! You can install a working .NET GUI application that retrieves encryption keys from the server, and the install includes the Visual Studio project and source code
• Integration of encryption key retrieval routines with the Windows certificate store and native Windows communications facility.
• When a Windows application authenticates, the certificates used for the secure TLS connection are under Windows security and control. The TLS communications is done with native Windows communications APIs. This reduces the chance of loss of certificates and private keys, supports the MMC management of certificates, and integrates with Microsoft’s patch update strategy.

As a developer, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data. These technical hurdles should not stop you from using an encryption key manager to meet compliance requirements for protecting encryption keys.

• Look for a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# or VB.NET code and you are retrieving the encryption key from the HSM.
• Make sure sample code is provided on the product CD to get you up and running quickly. There should be sample applications with source code that you can use as a starting point in your projects.
• The .NET Assembly should work with any .NET language. It should also work with the Common Language Runtime (CLR) environment, and with Stored Procedures. Make sure you can mix and match your .NET languages, databases, and OS platforms.

The combination of NIST validated encryption and an affordable FIPS 140-2 compliant key management solution with solid support for the Microsoft .NET developer makes our Alliance Key Manager a great option for users who need to meet security best practices and compliance regulations for key management. It is time to change your encryption strategy to incorporate solid encryption and an external key manager, whether that is an HSM, Cloud HSM, or virtual environment.

Download our white paper, Key Management in the Multi-Platform Environment, for more information on securing your encryption keys.

Because passwords can easily be compromised, they are considered to be a weak layer of security if used alone.

The use of two factor authentication (2FA) provides an added layer of security beyond just standard username and password credentials. Almost all connections to the IBM i platform are over a network (LAN or WAN), and they are rarely hardwired connections. Because networks are so susceptible to snooping attacks, even LAN connections should be treated like remote access. Remote access to networks containing critical payment, patient information, or financial records can be protected with two factor authentication using your mobile phone to receive SMS and voice verification authentication codes with an easy to deploy, cost effective 2FA solution for the IBM i platform!

Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in industries covered by PCI DSS, HIPAA/HITECH, and GLBA/FFIEC compliance regulations.

• PCI DSS section 8.3 requires two factor authentication for remote access to systems containing credit card information.

• HIPAA/HITECH act recommends two factor authentication to mitigate the risk of lost or stolen personal health information.

• FFIEC guidance also calls for the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against a financial fraud.

Although there are varying levels of enforcement, it is clear that two factor authentication plays a growing and critical security role in both compliance and following best practices.

Since launching Alliance Two Factor Authentication in January, we have had a number of questions about the product and thought we would share them here (along with the answers!)

Q: Does Two Factor Authentication integrate into my already existing Single Sign On (SSO) environment?
A: Yes!  Because the authentication process takes place after the login is complete, it will help strengthen the security around SSO.

Q: In which countries is 2FA available?
A: Two Factor Authentication is a global product. We are partnered with Telesign, which has a network of over 120 countries and the ability to work with 90+ languages to support generation of SMS messages.

Q: What profile security is required to run 2FA?
A: As a native IBM i solution, you assign normal security controls during installation.  End-users have to have use-authority to the library to use the services.

Q: Does your 2FA solution require a mobile app (like Google does) to generate the authentication codes?
A: Since our solution is fully self-contained and installed on the IBM i platform, it does not require a mobile application. The 2FA solution talks over a secure connection to the Telesign service, resulting in a pincode delivered to your mobile device as a SMS text message, or to your standard phone as a voice message.

Q: What if I don’t have access to a phone?
A: In case you don't have a mobile phone, or are in a location where you can't get cell service, your IBM i system administrator can record up to four additional voice phone numbers per user. This gives you a lot of flexibility for putting in phone numbers for home, work, cell with either the text or voice option. In the rare chance you may be someplace without access to any type of phone, Alliance 2FA provides up to 5 one-time codes for use when the phone services are not available. These are randomly generated numeric PIN codes a user has access to, that gives them the ability to authenticate even if they don't have a phone with them at the time.

Developers are also able to improve the security posture of IBM i platforms at the application level as well as during the log-in process with Application Program Interfaces (API). Alliance Two Factor Authentication does full logging of authentication and configuration changes into the IBM security audit journal QAUDJRN. For anyone running our Alliance LogAgent solution to capture information from QAUDJRN into your SIEM solution or your log collection server, this will automatically integrate 2FA in that environment. Developers can use two factor authentication for certain critical functions in the application environment such as sensitive operations about patient information, specific financial transactions, critical system functions (like powering down the system or doing a restore) that you might want to protect with 2FA. We provide a complete API set to our IBM i customers so that they can use a simple structure to initiate a two factor authentication sequence within the application. IBM i web applications can use Java, RPG, or other web languages to call the APIs and fully implement web-based 2FA within the context of the IBM i system where our two factor authentication application is running. The APIs then return to the program the result of the two factor authentication request as either succeeded or failed, and you can take actions at the level of the application to record the event or to deny or allow a particular operation.  

For more information, request our 2FA Resource Kit!

If you have additional questions about 2FA, add a comment below… we would like to hear from you!