Data Privacy Blog

Key Management Kit




Facebook Google+ Twitter LinkedIn

Our Blog to Your Inbox

Your email:

Posts by category

Townsend Security Data Privacy Blog

Current Articles | RSS Feed RSS Feed

Encryption Options for Microsoft SQL Server


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.

SQL Server Encryption Options Podcast 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.  

SQL Server Encryption Options Podcast Related Posts Plugin for WordPress, Blogger...

Encryption & Key Management for Amazon Web Services (AWS)


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?

Encrypting data in AWS 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.



Related Posts Plugin for WordPress, Blogger...

Overcoming the Top 4 Fears of Encryption and Key Management


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.

eBook - Encryption Key Management Simplified 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.

Encryption Key Management Simplified eBook

Related Posts Plugin for WordPress, Blogger...

Critical Steps to Encryption & Key Management in the Azure Cloud [White Paper]


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

Encryption & Key Management in Microsoft Azure 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

Encryption & Key Management in Microsoft Azure

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

Related Posts Plugin for WordPress, Blogger...

Encryption: Do I Need Key Storage or Key Management?


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

key lifecycle

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.

Encryption Key Management Simplified eBook  

Related Posts Plugin for WordPress, Blogger...

Two Factor Authentication: A Step to Take for Better IBM i Security


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

Two Factor Authentication IBM i White Paper

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).


White Paper Two Factor Authentication on the IBM i

Related Posts Plugin for WordPress, Blogger...

Encrypting Data with .NET Libraries


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.

White Paper: Key Management in a Multi-Platform Environment 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 C# and VB.NET 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 including C#, VB.NET, J#, C, and C++. 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.

White P

Related Posts Plugin for WordPress, Blogger...

Two Factor Authentication: Secure and Strengthen Access to your IBM i


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

Request the Two Factor Authentication Resource Kit Now! 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!

Request the Resource Kit on Two Factor Authentication

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

Related Posts Plugin for WordPress, Blogger...

What Data Needs To Be Encrypted In Drupal?


"I am collecting data in Drupal. What data do I need to encrypt?"

What Data Needs To Be Encrypted In Drupal? Organizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.

Federal/State Laws and Personally Identifiable Information (PII)

Federal and State laws vary in terms of what they consider Personally Identifiable Information (PII), but there is a lot of commonality between them. PII is any information which either alone or when combined with other information, which can identify an individual person. Examples include email addresses, first name, last name and birth date.
[Download white paper for complete list]

Educational Information Covered by FERPA

Educational institutions who fall under the FERPA regulation must protect PII as well as information like student names, student ID numbers, and family member names.
[Download white paper for complete list]

Federal Agencies and FISMA

Federal Agencies must evaluate their systems for the presence of sensitive data and provide mechanisms to insure the confidentiality, integrity, and availability of the information.  Sensitive information is broadly defined, and includes PII, as well as other information classified as sensitive by the Federal agency.  Sensitive information might be defined in the following categories: medical, financial, proprietary, contractor sensitive, or security management.[Download white paper for complete list]

Medical Information for Covered Entities and HIPAA/HITECH

The HIPAA/HITECH Act defines Protected Health Information (PHI) to include PII in addition to the following PHI: Patient diagnostic information, payment information, health plan beneficiary numbers, full facial photographs, etc.
[Download white paper for complete list

Payment Card Data Security Standard (PCI DSS)

The Payment Card Industry Data Security Standards (PCI DSS) require that merchants protect sensitive cardholder information from loss and use good security practices to detect and protect against security breaches.  If you accept or process credit card or other payment cards, you must encrypt the Primary Account Number (PAN).

Financial Data for FFIEC

Banks, credit unions, and other financial institutions must protect Non-public Personal Information (NPI) which includes personally identifying financial information.  In addition, you should protect income, credit score, etc.
[Download white paper for complete list]

Encrypting Data in Drupal

Townsend Security is helping the Drupal community encrypt sensitive data and properly manage encryption keys. Developers who need to protect sensitive data know that storing their encryption keys within the content management system (CMS) puts their data at risk for a breach. With Key Connection for Drupal and Alliance Key Manager, administrators are now able to keep their encryption keys secure by storing them remotely and only accessing them when the encryption/decryption happens.

The Key Connection for Drupal module is a plugin for the Encrypt project that allows you to easily encrypt sensitive data with NIST-validated AES encryption and securely retrieve and manage encryption keys from Townsend Security’s FIPS 140-2 compliant Alliance Key Manager. With an easy to use interface and certifications to meet compliance requirements, you can rest assured knowing your data is secure.

What Data Needs Encrypted In Drupal?

Related Posts Plugin for WordPress, Blogger...

Nine Guidelines for Choosing a Secure Cloud Provider


Public and private organizations want to take advantage of cloud-based solutions to reduce costs and improve business performance. Organizations understand that the ultimate responsibility for the security of their data remains with them. Justifiable concerns about the security of cloud-based applications continue to worry security professionals and business executives.

eBook The Encryption Guide The following list of nine guidelines is intended to serve as a baseline indicator of the maturity and adequacy of the security of a cloud platform and cloud application offering. They are not intended to be exhaustive, but only serve as a set of key indicators. Additional security review of any cloud provider and cloud application should be performed before deployment or migration.

Security professionals (CIOs, CISOs, compliance officers, auditors, etc.) and business executives can use the following set of key indicators as a way to quickly assess the security posture of a prospective cloud provider and cloud-based application or service. Significant failures or gaps in these nine areas should be a cause for concern and suggest the need for a more extensive security review.

The sources for these guidelines include the Cloud Security Alliance, Payment Card Industry Data Security Standards (PCI DSS), the National Institute of Standards and Technology (NIST), the SANS Institute, and others.

The nine key indicators:

1) Inventory of Sensitive Data

All sensitive data processed and stored by the cloud application and service should be properly inventoried and published to stakeholders. Data retention policies should be published for all sensitive data.

2) Data Protection

The use of industry standard encryption for data at rest should be implemented for all sensitive information such social security numbers, credit card numbers, email addresses, and all other personally identifiable information. Encryption keys used to encrypt sensitive data should be protected by appropriately strong key encryption keys, and encryption keys should be stored away from the sensitive data and managed according to industry best practices (separation of duties, dual control, split knowledge, key rotation, etc.). Minimally, encryption key management systems should be validated to the FIPS 140-2 standard.

3) Business Continuity Plan

The cloud and application providers should have a published business continuity plan (BCP) that meets the minimum baseline needs of your organization. The business continuity plan should address backup and recovery, geographic redundancy, network resilience, storage redundancy and resilience, and other common components of a BCP.

4) Incident Response Plan

Both the cloud provider and the application provider should have a current incident response plan available to stakeholders. The plan should cover how incidents are discovered, the response plan for breaches, staff training, and management. All stakeholders should understand that security events are a matter of “when”, not “if”.

5) Active Monitoring

Actively monitoring of all aspects of the cloud and application environment is a core security principal. Real time log collection and monitoring is a minimum component of active monitoring. Additionally application and operating system configuration changes and access to decrypted sensitive data should be monitored (File Integrity Monitoring). Cloud provider infrastructure monitoring should be in place as well as stakeholder access to critical event information.

6) Multi-tenancy Data Isolation

Cloud-based applications and services inherently share computing resources across multiple customers. Proper segregation of your data from other customers using the application is crucial for your security posture. The cloud and application provider should provide credible assurance that there is adequate logical or physical separation of your data from all others sharing computing resources.

7) Vulnerability Assessment and Penetration Testing

Periodic vulnerability and penetration testing should be performed on the cloud provider infrastructure as well as the application environment. Any identified weaknesses should be addressed in a timely manner and disclosed to you and other stakeholders.

8) Independent Security Assessment

The cloud provider’s infrastructure used to host the application should be independently assessed for security compliance and best practices on a periodic basis, and no less than annually. The results should be available to you and other stakeholders. Examples would include SOC 2, SOC 3, SSAE 16, PCI assessment and letter of attestation, etc.

9) Contractual and Legal

Cloud and application providers should provide you with proper legal agreements including a Service Level Agreement (SLA) that defines mutual obligations. Be sure that you understand where you data will be stored and processed and that you understand geographic boundary controls. Additionally, be sure that the agreement between you and your cloud and application provider apply to any third parties who may have access to your data, or who may take possession of your data. Lastly, be sure that you receive prior notification before your data is released to law enforcement or any other governmental agency.

The Encryption Guide eBook

Related Posts Plugin for WordPress, Blogger...
All Posts