One of the big fears that companies have as they deploy encryption of sensitive data is that they might lose their encryption key and never be able to decrypt and recover their data. Having spent some of my career in IT management I certainly understand where this comes from. There is nothing like a corrupted backup to turn a good day into a bad one. The same is true if you lose your encryption key.
So how do we help make sure that our Alliance Key Manager solution running in Windows Azure protects you from this potential problem? Let’s look at all of the things we do in our key management solution, and the things you can do in Windows Azure:
Backup / Restore
The first line of defense is always to have a backup of your encryption keys and key access policies. Alliance Key Manager provides you with an option to securely back up your encryption keys, security policies, and server settings and to move this backup out of Windows Azure to your own secure storage. You can do a manual backup at any time, and you can automate the backups on a schedule that you define. You can even automate the transfer of the backups to an external FTP server using secure, encrypted transfer methods. Don’t have an FTP server to receive your backups? Don’t worry, we can provide you with one in our secure cloud facility.
Key and Policy Mirroring
The next line of defense is to implement real-time key and security policy mirroring from your primary Alliance Key Manager cloud instance to a failover key manager instance running in Windows Azure or to a key manager running outside of Windows Azure. Alliance Key Manager fully implements key mirroring over a secure, encrypted connection to one or more secondary key servers. The secondary key servers will contain exact copies of the encryption keys and their access policies, and will always be ready in the event your primary key server stops working. Alliance Key Manager supports Active-Active mirroring so that you will always have a full set of your encryption keys available to you even after a failover.
Windows Azure Availability Sets
Do you know about Windows Azure Availability Sets? This is a feature of Windows Azure to help you avoid unplanned outages due to failures of the cloud infrastructure or planned Windows Azure maintenance activities. We encourage our Windows Azure users to take advantage of Availability Sets when deploying a second Alliance Key Manager instance. It provides one more way to get the best reliability for your key management infrastructure in the Windows Azure cloud.
Mirroring Outside the Windows Azure Cloud
Lastly, if you are still worried about losing your encryption keys, you can always mirror the keys to a key manager located outside the Windows Azure cloud. You could mirror your keys to a physical key manager HSM located in your data center or the hosting provider of your choice. Or, you could mirror your encryption keys to a dedicated key manager in our cloud data center (see Alliance Key Manager Cloud HSM). Or, you can mirror your keys to a VMware or Hyper-V instance of Alliance Key Manager in your data center or the hosting provider of your choice.
Alliance Key Manager in Windows Azure goes the distance to help ensure that you never lose an encryption key. You might be losing sleep over your move to the cloud, but you shouldn’t lose sleep over your encryption strategy.
With V7R1 IBM introduced FIELDPROC (field procedure) exit points which Alliance AES400 for IBM i uses to encrypt database files at a field level. Since the cryptographic process is called by the database directly upon access, rather than by the application, this means that the process will work regardless of what type of application uses it. No application changes are needed, which is something our customers really like to hear.
These are five frequently asked questions we get around FIELDPROC encryption.
1. What type of fields are supported with FIELDPROC?
Surprisingly, virtually every field type is supported, whether it is character (even binary character), numeric (zoned, packed or binary) date, time, timestamp, Double Byte Character Set (DBCS), and hex. Some fields have certain restrictions, for example in order to implement fieldproc encryption on date, time, and timestamp fields you must specify a default value that is not ‘current date and time’. You can define this in DDS or structured query language (SQL), and there is an option in the DB2/400 FIELDPROC encryption menu that will do this for you.
FIELDPROC will also handle blank fields by not encrypting them at all. This helps us achieve better results from certain SQL operations. FIELDPROC encryption however does not support fields with NULL values and they should be avoided or changed if necessary.
2. Will I need to make any changes to my applications?
As I mentioned above, it is not necessary to make application changes, but here is more detail as to why: In V7R1, AES/400 can create FIELDPROC exit points that tie to individual fields in a DB/2 file. When a file is opened for any operation, read, update, insert, or delete, the exit point calls one of our FIELDPROC applications, which calls our encryption or decryption APIs. It does this regardless of which application is accessing the file, thus creating application independent encryption.
A few things to consider are: when you backup your file you will need to also backup the FIELDPROC applications, and make sure you restore them at the same time as well. It is also important to remember that if the file is accessed through FTP it will be transferred in the clear.
3. Can I encrypt index fields?
In short, yes. However, encrypting index fields will affect the performance of your SQL operations, and the more indexes you encrypt, the more your performance will be affected. This happens primarily for the following reason: For faster performance DB/2 looks up records based on their encrypted values. This means that when you tell DB/2 you are looking for the record with social security number 111223333, and that field is encrypted, it will encrypt the search string and then retrieve the matching record for you. This is done as a performance enhancement especially when working with logical files on the IBM i. However for some SQL operations it decrypts all the records in order to read the index fields, so rather than encrypting single values to look up, it needs to decrypt a multitude of records.
4. What kind of performance can I expect?
In our test environment, which consists of a single processor IBM i platform, model 515, approximately 3500 CPW, V7R1 of the operating system with TR5 installed, we can process about 16,000 records per second. Systems with higher processing power should see better performance. This means that if we have a file with one million records and one field encrypted we can read the entire file in about 60 seconds. If they are 2 fields encrypted it will take us about 120 seconds because we are handling two million decryption calls.
5. Does using external key management affect performance?
In short, no. The time it takes AES/400 to retrieve a symmetric encryption key from our Alliance Key Manager server is approximately 0.0116 seconds. And this is through a secure TLS connection. There are network infrastructures in which this time may be slightly affected, firewalls, routers, switches, distance, however it should never create a noticeable difference in performance.
To learn more about automatic encryption on IBM i V7R1 using FIELDPROC, download the podcast "FIELDPROC Encryption on the IBM i" to hear IBM i security experts Patrick Botz and Patrick Townsend discuss encryption, key management, and meeting compliance regulations on the IBM i.
Alliance LogAgent is a product designed with the intent of reading your security audit journal event entries, then formatting and forwarding those events to any SIEM or LEM device, but LogAgent provides several significant features and functions that you may not be aware of. In this article I will discuss five of these highly valuable features of the Alliance LogAgent product that you may not know about.
Exclude trusted users to reduce volume. In addition to allowing system administrators to filter out various event types from reporting, Alliance LogAgent will also allow you to filter out all events created by specified user profiles through the use of an “Excluded Users” list. System admins may occasionally find it necessary to filter out all audit events created by implicitly trusted system user profiles. Alliance LogAgent allows you to configure this ability at the IBM i level so that you can block those events from reaching your SIEM, thus reducing the volume of events that the SIEM must filter from reports.
- Secure communications between agent and SIEM. While most SIEM solutions provide support for TCP and/or UDP connections to agents, Alliance LogAgent also supports the use of SSL/TLS secure connection for customers who need to protect the privacy of the communications between the agent and the SIEM. With the simple addition of certificates to the IBM i Digital Certificate Manager and configuration of an Application ID tied to the certificate, Alliance LogAgent can be quickly configured to use SSL/TLS communications to protect your communications with the SIEM.
- Exit Point monitoring. In the IBM i environment many IBM applications provide Exit Points that can be used to trigger flags for reporting or launching other processes. Alliance LogAgent has the ability to monitor these Exit Points and create audit events that get reported to the SIEM so that system administrators can use the SIEM to monitor many of those functions. Providing Exit Point monitoring within Alliance LogAgent allows the SIEM to provide administrators with valuable reporting of the use of many of these systems within the IBM i.
- File Integrity Monitoring. File integrity monitoring is recommended under PCI DSS and other regulations. Even in other environments it is often highly desirable to be able to verify and monitor the integrity of data within database files. Alliance LogAgent has an add-on module that provides this highly valuable File Integrity Monitoring (FIM) function. Database Monitor allows the admin to determine which files and which fields within those files need to monitored for access and integrity. Database Monitor will record the original field data and also the new values recorded in the field, as well as application and user information for how and when the data was changed. This integrity monitoring allows you to also set alerts to administrators if unauthorized users, or applications alter data, or if data changes violate configurable thresholds.
- Simplified formatting for event reporting. In the world of event management there are many possible SIEM and LEM systems and services available. Some of these SIEM and LEM systems use Common Event Format (CEF) for handling event data, while others use the Syslog (RFC3164) format. Alliance LogAgent provides configuration options to support either of these two formats and is compatible with a wide range of SIEM and LEM devices and services without any need for additional IBM i support or programming. Simply select a couple of collector and formatting options in the product configuration panels, specify the destination address of the SIEM device, and start the system. You can begin seeing your IBM i audit events at the SIEM in a matter of minutes from initial installation of the product.
With the importance of event monitoring becoming more critical for system administrators, it is important to choose a logging solution that will meet your needs. Alliance LogAgent’s wide range of features, combined with the ease of setup and configuration, allows system administrators great flexibility while still allowing for rapid deployment with nearly zero impact on daily operations.
On February 19th the University of Maryland disclosed to the public a data breach exposing over 300,000 records of students, faculty, and alumni including names, social security numbers, and dates of birth.
Universities and colleges using their website to communicate with students are aware of the fact that their website is a massive portal for student data. From the moment a potential student applies to a university through its website, up through each time a student submits financial and health information, thousands of personal records are being collected by the website and stored for internal use in databases.
Why is this data not being protected? That’s the big question asked by data security experts and concerned students alike, who are aware of the massive number of data breaches that occur yearly through websites. The information submitted on higher education websites includes nearly everything a hacker or malicious user wants including: home addresses, social security numbers, phone numbers, email addresses, passwords, parent names, credit card, and financial data. Many universities run teaching hospitals, not to mention their own student health services. Protected health information (PHI) entered through patient portals also poses a huge risk if the data isn’t protected.
This information should not only be encrypted to protect students, faculty, and patients alike, but it should be encrypted because the collection of financial data, credit card data, and PHI fall under industry regulations such as HIPAA/HITECH and PCI-DSS which require the encryption of this data.
Here’s the good news: Many college and university websites are built using the common content management system (CMS) Drupal. Drupal is one of the most widely used CMS platforms, and is used by both small start-ups and Fortune 100 enterprises. It is very commonly used for higher education sites. Drupal has a long history with addressing security in its modules, and in fact has even supported an Encrypt module to encrypt sensitive data. Although the Encrypt module made encrypting data easy for Drupal users, it lacked a very important component of successful encryption: encryption key management.
Encryption key management is the foundation of a successful encryption strategy. If the encryption key is stored locally with the encrypted data, then a hacker who gains access to the data can immediately decrypt the data, making the encryption useless. If the key is protected, away from the encrypted data, then the data remains safe, even if accessed by an attacker.
Ok, here’s the actual good news: Stronger encryption and encryption key management is now available for Drupal users. Chris Teitzel and Rick Hawkins, Drupal developers and owners of Cellar Door Media have recently teamed up with Townsend Security to create Key Connection for Drupal--a module that enables NIST-validated AES encryption and FIPS 140-2 compliant key management for data in Drupal.
Key Connection for Drupal offers these important features:
- Encryption anywhere you want it - The Key Connection for Drupal APIs allow developers to encrypt data and protect encryption keys anywhere data is collected in a website from student enrollment applications to student health service portals.
- Onboard encryption - While Drupal developers can still use the encrypt module to encrypt sensitive data, and protect the encryption keys to a cloud or physical key management module, they also have the option to do “onboard” encryption within the key manager using NIST validated AES encryption. This is a critical new feature for business who need to meet PCI-DSS compliance requirements.
- Multiple key management options - Developers can choose from multiple key management options from key management in the cloud to a physical hardware security module (HSM) that they can rack up in their own IT infrastructure. Townsend Security also offers virtual and hosted options.
To learn more about Key Connection for Drupal and how you can encrypt sensitive data in Drupal using NIST validated AES encryption and protection of encryption keys using FIPS 140-2 compliant key management, listen to the podcast featuring the Key Connection for Drupal developers.
Securing Sensitive Data in Drupal made possible through partnerships!
The Drupal content management system may have started-out in a dorm room, but it has become a very successful open source platform that is being adopted at the Enterprise level. Drupal is running everything from small business websites, universities, robust e-commerce environments, Fortune 100 sites, to projects like WhiteHouse.gov! As Drupal developers build out these large-scale installations, the need to keep them secure becomes more apparent due to the volume of information being collected. Sensitive data such as credit card numbers and protected health information (PHI) fall under industry data security regulations such as PCI-DSS and HIPAA/HITECH and must be encrypted. Requirements for protecting information go beyond just credit card numbers & expiration dates, but includes names, email addresses, ZIP codes, usernames, passwords… any stored data that can personally identify an individual.
Drupal developers and users who need to protect sensitive data know that storing encryption keys within the content management system puts data at risk for a breach, yet storing encryption keys locally in either a file protected on the server, in the database, or in the Drupal settings file has been the norm. None of these methods meet data security best practices or compliance regulations such as PCI DSS, HIPAA/HITECH, or state privacy laws.
While additional compliance regulations may apply depending on industry, this is a basic list of good practical guidance around web-based and virtual environments:
- PCI Security Standards Council (PCI SSC) has issued Cloud Computing Guidelines as well as guidance around virtualization of data protection solutions, so you can be PCI compliant with a cloud-based key management and encryption solution.
- The Cloud Security Alliance (CSA) has also issued good guidance around security in cloud environments in version 3 of their documentation (domain 11 applies to encryption and key management).
- National Institute for Standards and Technology (NIST) also has produced a guidance for security in cloud environments(NIST Special Publication 800-144) which provides excellent guidance for people looking to move into cloud platforms and protect data there.
The Drupal community collaborates to develop modules for the platform, sharing knowledge, experience, and creativity. The developers try to avoid duplicate functionality, so the existing Drupal Encrypt module was used as the first step to protecting sensitive data, however the plug-ins for the Encrypt module did not provide secure key retrieval options as the encryption keys were all still found within that same server. Security best practices tell us that personally identifiable information needs to be protected with industry standard AES encryption and that protecting the encryption key away from the data is critical. It became apparent that a key management system that was outside of the Drupal installation was required.
Working together to solve the Drupal data security problem, the security experts at Townsend Security and Drupal developers at Cellar Door Media have released the Key Connection for Drupal solution, which addresses the need for strong encryption and encryption key management within the Drupal framework. Now personally identifiable information collected during e-commerce checkouts and user account that contain names and e-mail addresses can be easily encrypted, and the encryption keys properly managed, by organizations that collect and store that sensitive information.
Drupal developers and Drupal users share a concern about multiple compliance requirements and the liability that goes along with being audited for correctly protecting personally identifiable information. When designing an environment, there is a need to know what methods of encryption you are using, that the encryption key management is implemented correctly, and how secure will the data collection and storage processes be. The Key Connection for Drupal module allows designers to either retrieve a key and encrypt locally, or send the data to Alliance Key Manager (AKM) to perform on board encryption. They have the choice to use the Alliance Key Manager strictly as a key manager, or they can use it as an encryption service as well.
A few benefits of this new Key Connection for Drupal module are:
- Access to remote key retrieval
- NIST validated on-board encryption
- Encrypting data locally in your database
- Using a built-in function to allow for PCI compliant encryption to be done off the web server
To learn more, I encourage you to listen to this special podcast to hear Chris Teitzel; CEO of Cellar Door Media, Rick Hawkins; owner of Alchemy Web Solutions, and Patrick Townsend; CEO of Townsend Security, talk about encrypting sensitive data in Drupal. They will also discuss how a Drupal site builder or developer gets access to Key Connection for Drupal, the Alliance Key Manager, and what options are available.
Education is what remains after one has forgotten what one has learned in school.
One important aspect of our work is supporting our customers and answering their questions. There is a lot to learn, and there are a lot of sources of information, and it can be difficult at times to decide what information to take in and what to let pass by.
Beyond answering their questions about broader topics such as security and compliance, we also end up discussing some very technical issues that they have questions about as well. It’s not usually until after someone begins working with our products that we step in to answer questions about the technical aspects, the nitty gritty, of how a product addresses their security and compliance needs. In this article I will cover in greater technical detail five frequently asked questions about working with PGP encryption, as well as some tips and tricks on how to get the most out of it.
1. I have encrypted a file for my trading partner, and I want to verify it, but when I try to decrypt it, why do I get an error?
If you are encrypting a file for a trading partner you are most likely using their public key. Because a public key can be given out to anybody, it becomes important to prevent just anyone from decrypting it. Thus the file can only be decrypted with your trading partner’s private key, which only they should have. Based on the principles of asymmetric encryption, it is impossible to encrypt and decrypt with the same key.
There is however a way to encrypt the file for both your trading partner and for yourself to decrypt. You can encrypt the file with multiple public keys, in this case your trading partner’s and yours. Our PGPENCRYPT command does this through the use of the ‘Additional user IDs’ parameter, in which you would define a public key for encryption to which you had a matching private key for. That way you would be able to decrypt it using your private key to verify the contents of the file.
2. How do I provide my trading partner with my key?
When you are exporting keys from the keyring there is one important question to ask, will the key be used for encryption or decryption? When you are exchanging files with a trading partner you have to remember that you will be encrypting with their public key and they will be encrypting with your public key. But decryption, again, can only happen with a private key.
So if you need to export a key for encryption it needs to be the public key, if it’s for decryption you should export the key pair.
Our PGPKEYEXP command can accomplish both for you. You would define the key to export with the ‘Export type’ parameter, where *PUBLIC exports the public key and *KEYPAIR exports both the public and private keys in one file. You can verify what was exported by viewing the file. Even though they keys themselves are unreadable the title is. An exported key pair would list the private key first.
It is important to note that under no circumstances should you provide your private key or the entire key pair to your trading partners or vendors. The option to export the key pair is built into the application to allow you to move individual key pairs between your company’s own servers.
3. My trading partner’s key has expired, can I update its expiration date using PGP commands?
There is a way to update the expiration date on a public key, but not one you received from a trading partner. The public key can be updated only if you have the matching private key and the private key’s password. Because your trading partner should not ever share neither their private key nor their password, you cannot update the expiration date on that public key.
You will need to attain the new public key from your trading partner. The good thing is that most trading partners have a system in place that should inform you ahead of time of the impending expiration of their public key and either provide the new key with that notice or provide instructions on how you can obtain it.
4. I have received a key from a trading partner and I have added it to the keyring but I can’t encrypt with it (or I am being asked if I want to trust the key every time I try to encrypt with it), how do I trust it?
When you first import a public key PGP will not ‘trust’ it, since information encrypted with it can’t normally be recovered (see Question 1 for options). When you try to encrypt with it, PGP will error out, although when you are encrypting interactively, it will prompt you. To trust the key you need to do the following 2 steps:
- Sign the new key with your private key to validate the key using the PGPKEYSIGN command. Because you are using your private key to do this you will need its password as well.
- Then you need to set its trust level using the PGPKEYCHG command. Once you have done this PGP will accept the key for encryption.
5. My trading partner wants me to sign the file. What does signing a file do?
Signing a file is a way that you can help your trading partner make sure the file they received really came from you. You can encrypt and sign a file or just sign it, on the latter the contents of the file remain visible but an encrypted string is added to the bottom containing your signature. A signature can only be created with a private key, so your trading partner can be pretty certain that the file could only have come from you. The signature is verified by PGP by using your public key to decrypt and read that encrypted string. The string is never stored in the clear but it is read and PGP returns a message that it has verified it. This does mean that anyone with your public key can verify your signature, but then again that is what you want. If a file is both encrypted and signed, the signature would be read by your public key and the contents decrypted by your trading partner’s private key. You can define the signing key in our PGPENCRYPT command with the ‘Signing user ID’ parameter and by providing the command with its password. You can also sign a clear text file or an already encrypted file with the PGPSIGN command.
For more information on encrypting data in transit with PGP, download the podcast, “PGP Encryption on the IBM i,” featuring data security expert Patrick Townsend.
Providing Data Security IN the Cloud
The excitement level has been palpable around our office this week as we released the first encryption key manager to run in Microsoft Windows Azure, solving the data security problem that has held many companies back from adopting Microsoft's cloud. In preparation for this new product, we have had a number of questions to answer, so I thought we should recap a few of them and share an excellent podcast resource with our readers!
What is the main issue that Microsoft Windows Azure customers are experiencing?
The number one concern reported by companies or organizations when they think about moving to any cloud environment is security. The studies show that their biggest concerns revolve around exposure of personally identifiable information and preventing data loss. It is a big enough concern that many companies have held back from migrating mission-critical applications with sensitive data from their traditional data centers into the cloud.
A few things that are common across many industries and compliance regulations can really help with protecting data in cloud platforms like Windows Azure:
- Use industry-standard AES encryption.
- Keep your encryption keys are separate from the data that's being protected.
- Use dual control and separation of duties to protect your encryption keys.
- Follow best practices in terms of protecting data-at-rest and data-in-motion.
What strategy do you use for deploying a key manager in Windows Azure?
When you are running AKM as a Windows Azure virtual instance it is in a standard or virtual private cloud environment (VPC) allowing for better segmentation and isolation of your key management implementation. You definitely do not want to store encryption keys in the same virtual machine or instance of Windows Azure where sensitive data is stored. That would be like taping your house key to the front door when you leave home! In fact, the core concept for key management is to always separate the encryption keys from the data they protect.
We know key management is critical to meeting compliance regulations, but is there any guidance about securing data in the cloud?
It is very important for cloud users to protect data using good practical guidance from PCI Security Standards Council (PCI SSC) even if not storing credit card information. PCI SSC has issued Cloud Computing Guidelines as well as guidance around virtualization of data protection solutions, so you can be PCI compliant with a cloud-based key management and encryption solution.
The Cloud Security Alliance (CSA) has also issued good guidance around security in cloud environments in version 3 of their documentation (domain 11 applies to encryption and key management).
National Institute for Standards and Technology (NIST) also has produced a guidance for security in cloud environments (NIST Special Publication 800-144) which provides excellent guidance for people looking to move into cloud platforms and protect data there.
How does your Alliance Key Manager help protect data in Windows Azure?
Our founder and CEO Patrick Townsend says, “I'm rather proud of the fact that we have the first fully cloud-based key management solution in Windows Azure. Our Alliance Key Manager for Windows Azure solution is a cloud instance that you can deploy directly into Windows Azure to manage encryption keys and protect data. It can be deployed in standard Windows Azure Infrastructure-as-a-Service (IaaS) environment and you can deploy it directly into a virtual private cloud. It's the same binary code that is in our HSM which is FIPS 140-2 validated and it's running purely within that Windows Azure environment. I am proud of our development team for bringing forth our Alliance Key Manager for Microsoft Windows Azure users as an affordable solution.”
Along with Alliance Key Manager comes applications that deploy, such as our EKM provider, which gives you full protection of Microsoft SQL Server databases and the Microsoft solution applications that run on top of SQL Server. This includes:
- Custom-built SQL Server applications
- Applications in SharePoint using SQL Server as its content database platform
- Microsoft dynamics applications such as CRM and AX and GP that run on top of SQL Server
For custom applications we provide a .NET assembly that you can use to add to your applications to perform encryption either on versions of SQL Server that don't support transparent data encryption (TDE) or on unstructured data that you may be storing in the Windows Azure platform. You are also able to encrypt data going into SQL Azure as well as MySQL or Oracle or any other database that you might be running. Alliance Key Manager comes with a complete library of SDKs and sample code for developers, along with purpose built applications that are ready to plug in and perform encryption, which will get encryption projects up and running very quickly.
“The recent data breaches experienced by so many retailers just highlight the need to protect data with encryption and properly manage the encryption keys. We really help answer the challenge of protecting data in cloud environments like Microsoft Windows Azure and we are helping people achieve that data protection that they need to feel comfortable moving to cloud platforms.”
Please download this podcast to learn more about securing data in the Microsoft Windows Azure platform:
The primary concern of cloud customers is the security of their sensitive data. Security remains one of the major barriers to cloud adoption. And that makes sense. Cloud platforms like Microsoft Windows Azure are by their nature shared environments. The computational resources are shared, the network resources are shared, and the responsibility for physical security is ceded to a third party. That would make anyone nervous.
There are also some additional practical issues. Where, for example, do you actually store your encryption keys that protect your data? For customers and software providers who are fully in the cloud, this is a difficult practical question. You just don’t have a convenient place to securely store encryption keys away from the data that they protect.
Today we announced the availability of our latest encryption key management solution, Alliance Key Manager for Windows Azure. The same key management solution that we ship in our FIPS 140-2 compliant key management hardware security module (HSM) is now available as a virtual machine in Windows Azure. With a few clicks in the Windows Azure portal you can launch Alliance Key Manager for Windows Azure and start protecting encryption keys the right way.
All of the features that make a hardware HSM desirable - key management and encryption dedicated to you, exclusive administrative access to only you (sorry cloud provider), encryption and key management provably based on industry standards, and high availability now run as your dedicated virtual machine.
Alliance Key Manager for Windows Azure is deployed in just the way you would hope. An affordable, usage based pricing model, and managed through the same Windows Azure facility that you manage all of your other virtual machines. For added security, you can launch your virtual machine in a Windows Azure Virtual Private Cloud (VPC), and you can deploy two VMs in a Windows Azure Availability Set for better redundancy.
As is the case for our hardware key management solutions, our Windows Azure cloud offering supports encryption within the key management virtual machine. This means that you don’t even need to expose the encryption key in your Windows Azure web application. Just send the data to the key management virtual machine and encryption or decryption takes place there.
In conjunction with our launch into the Windows Azure platform, we’ve also added a great new feature we call “Ready-To-Use”. When you start your key management virtual machine for the first time it will automatically install a 30-day evaluation license, generate the certificates you need for authentication, and generate some encryption keys that are unique to you and ready to use with SQL Server, SharePoint, and your Windows .NET applications. You are ready to start encrypting in seconds.
There are many challenges to meeting compliance regulations, and you should be aware of the recommendations of the Cloud Security Alliance and of the PCI Security Standards Council for encryption and key management. You don’t need to compromise with poor key management, or a key management solution that has never seen the daylight of a FIPS 140-2 validation.
Happy cloud computing!
Two Factor Authentication (2FA) adds a critical layer of security to protect user accounts and prevent fraudulent access that goes beyond password logins.
Have you made time to watch our most recent webinar on Two Factor Authentication? If not, click here to learn more about how 2FA enables companies to increase their security without the high cost of hardware & software integration by using a technology that is already a part of every user’s life, offering a better user experience with little-to-no training required. Also by leveraging your mobile phone as an authentication device, Alliance Two Factor Authentication improves the security of user account access while reducing operating costs typically associated with traditional multi factor authentication methods.
Here is a summary of the questions asked after the 2FA webinar:
Q: Does two factor authentication integrate into an already existing single sign-on environment?
A: Yes, you can deploy two factor authentication in a single sign-on environment. Alliance Two Factor Authentication runs natively on the IBM i platform, which allows you to use a SSO solution in the IBM i environment and still deploy two factor authentication to the end-user. We implement the second factor authentication on the IBM i platform, which means that we’re not linked to the actual SSO application that might be running on Windows or using an LDAP or active directory implementation. This provides you with better security for those users who are accessing your IBM i platform as it is not possible to then hijack the authentication requests in a PC environment.
Q: What company did you partner with to deliver 2FA messages?
A: Having customers all over the globe, we were very selective in choosing to partner with another company familiar with terms of network availability of two factor authentication. We chose the TeleSign Corporation. Their infrastructure has the ability to detect when SMS text messages may not be delivered, and they will fail-over to other options and take action in other routes. With guaranteed enterprise-level uptime and industry-leading deliverability rates, TeleSign has conducted more than 2.5 billion phone-based authentications and voice verifications around the globe.
Q: In which countries is two factor authentication available?
A: Our partner TeleSign has a strong, mature infrastructure in the European zone, Latin America, Asia, and delivers authentication codes to over 200 countries and that supports 87 languages. They are constantly testing network connections and performance and they've had time to build this very powerful global infrastructure for our Alliance Two Factor Authentication solution.
Q: How long does it take to deploy Alliance Two Factor Authentication?
A: We suggest you test drive our Alliance Two Factor Authentication solution which is available to download from our website. We typically turn around requests for an evaluation license very quickly and can have you up and running the same day. With our complimentary trial, we also provide TeleSign credentials so that customers can actually evaluate two factor authentication on their own systems. We provide you a fully functional 30-day evaluation, yet proof of concept for this application can be done very quickly.
Request your complimentary 30-day evaluation here
We look forward to hearing about how our 2FA solution works for you!
Defend your data by adding another step to your security process!
With increased losses of sensitive data from websites, retailers, and covered entities in the medical segment, we are hearing about data breaches on an almost daily basis now. Are we as concerned as we should be, or are we getting jaded to the inevitability of data loss? When it seems like everyone is getting hacked, what kind of things can we do to help prevent access to our sensitive data?
After the recent Target data breach (and a number of other ‘holiday’ breaches), more information is surfacing on how attacks happen through unsecured websites, phishing emails, memory scraping, and keyboard logging malware that can get installed on individual user PCs. Once the hackers have usernames and passwords they can work their way through a network to where the sensitive information is stored.
For those of you on the IBM i platform, it might interesting to note that the IBM i is not immune from attacks and data loss. IBM i has a well-earned reputation as a secure platform, yet we are seeing keyboard logging attacks get past that great security as users log-in to the IBM i from their PC. IBM i platforms are typically great reservoirs of sensitive information; credit card numbers, social security numbers, personally identifiable information of all types make the IBM i platform a clear target for attackers.
In addition to the basics: encrypting your data and properly managing your encryption keys, you can immediately improve your security posture in relation to log-in security, as well as application level security by using two factor authentication (2FA) to prevent unauthorized access.
The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat. Combining something the person knows (password) with something they have, or something they are, which can then be used for two factor authentication.
- Something you know - a password
Security administrators can set system values for rules on passwords, require certain length passwords, characters and numbers, uppercase characters... but end-users are quite adept at creating passwords that can be easily remembered, yet meet the criteria of the strong password from the systems point of view. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.
- Something you have - a mobile phone
Mobile phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:
- Companies don't have to buy expensive additional servers and hardware
- Users generally have a mobile phone already, and even if they replace their mobile phone, their phone number remains the same
- Reduced cost of administrative expenses
- Something you are - biometric authentication options (iris pattern or fingerprint)
By using 2 of those 3 things you can authenticate more securely to the system.
Here are a couple examples of things that are not two factor authentication:
- Requiring two passwords: using one factor twice is not 2FA!
- Using shield questions of which are actually fairly easy in our social world to determine (Just the other day I received a message on a social media site that said “Hey! We might be related… what is your mother’s maiden name?”)
We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts.
Cell phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:
Earlier this year we introduced Alliance Two Factor Authentication for the IBM i, which fully implements 2FA using SMS text or a voice verification call to your mobile phone. In case you don't have a mobile phone, or are in a location where you can't get cell service, we allow the user or system administrator to record up to five mobile and 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 Two Factor Authentication 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 changes to the configuration files into the IBM security audit journal QAUDJRN. For anyone running our Alliance LogAgent solution to capture information from QAUDJRN into your SEIM 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 application program interface (API) 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 a more in depth technical discussion, please check out this great webinar on two factor authentication by security expert Patrick Townsend: