Townsend Security Data Privacy Blog

The academic cryptographic community has been very inventive lately and we are seeing some promising new encryption technologies start to emerge. Format preserving encryption is moving through a standards track at the National Institute of Standards and Technology (NIST) and I think we will see one or more of the proposed FFX modes of encryption achieve standards status soon.

Homomorphic encryption is also a promising encryption approach that allows for various operations on encrypted (ciphertext) values without having to first decrypt the value. That’s pretty cool. There are a number of cryptographers working on approaches to homomorphic encryption, but at this point there is no clear consensus on the right approach. I suspect that some consensus on the best approach will emerge, but it may take some time for this to happen. Cryptography is hard, and it needs time for proper examination and analysis of both mathematical and implementation strengths and weaknesses before its adoption in commercial systems. We need to give the cryptographic community time to do their work.

If homomorphic encryption is cool, why not use it?

It has not achieved wide review and acceptance
While there is promising work on homomorphic encryption, there is no clear consensus on the best method or implementation approach. Typically a new cryptographic method will not get a full review from the cryptographic community until there is some consensus, and not until a standards body takes up the new method in a formal review process. There are a large number of potentially good encryption methods that have been thoroughly reviewed by the professional cryptographic community but which have not achieved the status of an approved standard.

Homomorphic encryption has not yet been through this process and it is too early to trust any current proposals or implementations.

It is not a standard
Standards are important in the encryption world. Standard encryption algorithms receive the full scrutiny of the professional cryptographic community and we all benefit from this. Weaknesses are discovered much faster, weak implementations are identified, and we all have much more confidence in encryption based on standards. The Advanced Encryption Standard (AES) has stood the test of time since its adoption by NIST in 2001.

Homomorphic encryption has not yet achieved the status of an accepted and published standard.

Note: Mathematical proofs do not a standard make. They are required as a part of the standards review and adoption process, but mathematical proofs alone do not rise to a level of an accepted standard. Claims to the contrary are false.

It cannot be certified by a standards body
Since homomorphic encryption is not a standard, there is no independent standards body process to validate a vendor’s implementation. This is important - in an early study by NIST of encryption solutions submitted for validation, nearly 37% of the solutions contained errors in the implementation and failed validation. The failure rate for implementations of homomorphic encryption are likely as high and unknowable. All serious vendors of encryption technology have validated their AES implementations to FIPS 197 standard through the NIST AES validation process.

No such similar standards validation process exists for homographic encryption.

It cannot achieve FIPS 140-2 validation
Encryption key management solutions are cryptographic modules and can be validated to the FIPS 140-2 standard. NIST has established a validation process through a number of chartered test labs. All serious vendors of encryption and key management solutions validate their products through this process. One of the first steps in key management FIPS 140-2 validation is validation of the encryption methods used by the key manager. The approved encryption methods are documented in Annex A of FIPS 140-2.

Homomorphic encryption is not an approved encryption method and cannot be validated to FIPS 140-2 at this point. Any representation that homomorphic encryption or key management systems implemented with it are “FIPS 140-2 compliant” is false.

Intellectual property claims are not resolved
Organizations large and small are rightfully concerned about violating patents and other intellectual property claims on information technology. At the present time there are multiple vendors claiming patents on homomorphic encryption techniques. Most encryption methods that have been adopted as standards are free of these types of IP claims, but homomorphic encryption is not free of them.

Organizations would be wise to be cautious about deploying homomorphic encryption until the patent and intellectual property issues are clearer.

Compliance regulations prohibit its use
Many compliance regulations such as PCI-DSS, HIPAA/HITECH, FISMA, and others are clear that only encryption based on industry standards meet minimal requirements. Standards bodies such as NIST, ISO, and ANSI have published standards for a variety of encryption methods including the Advanced Encryption Standard (AES).

Homomorphic encryption is not a standard and it is difficult to imagine that it could meet the minimum requirements of these and other compliance regulations.

Summary
Homomorphic encryption is a promising new cryptographic method and I hope that we will continue to see the cryptographic community work on it, and that we will see its future adoption by standards bodies with a proper validation processes. We just aren’t there yet.

The internet has become a portal for the transmission and storage of sensitive data. Most websites today gather information from potential or current customers, clients, and users. From credit card numbers to email addresses and passwords, few websites exist today that don’t collect some sort of personal data. Therefore, website developers are becoming more and more interested in learning how to build websites that can easily encrypt sensitive data that their client’s website may be collecting.

Encryption isn’t as widely used at the application and module level in websites as it probably should be. Protecting sensitive data using strong encryption from the moment a website accepts a customer’s information, and throughout transmission and storage of that data is the only method to ensure that data is never compromised. This is critical for websites using commerce modules or forms that collect a person’s health information, financial information, or other personally identifiable information (PII); and for businesses who wish to avoid a data breach.

As Drupal grows and more Drupal developers are beginning to interact with larger clients, the need to provide strong security to those businesses grows as well. The need for encryption will continue to grow as potential clients ask Drupal developers for standards-based security solutions that will help them meet compliance regulations and mitigate risk.

• Government websites, for example, will need to pass FISMA regulations around encryption.
• Large retail websites will need to pass Payment Card Industry Data Security Standards (PCI DSS).
• Colleges and Universities have multiple compliance requirements, as well as FERPA, to adhere with.

Helping clients meet compliance regulations will also require, in some cases, the need for encryption key management. Historically, developers only had three choices for encryption key storage: they could store the key in a file protected on the server, in the Drupal database, or in Drupal’s settings file. None of these options are secure, and would not meet several compliance regulations and general security best practices.

Encryption key management is more than a “key storage” solution. An encryption key manager protects encryption keys on a separate server (located in the cloud or as a physical Hardware Security Module (HSM) or in a (VMware) virtual environment) that implements control layers such as dual control and separation of duties. An encryption key manager manages encryption key creation, deletion, lifecycle, rollover, and archival. Key managers that are FIPS 140-2 compliant have undergone NIST validation and are based on industry standards. Choosing an encryption and key management solution based on standards will ensure your solution will stand up to scrutiny in the event of a breach.

If you are a Drupal developer, you can now join the Townsend Security Drupal Developer Program, work with our encryption and key management technology free of charge, and learn how to secure sensitive data in Drupal for your clients concerned with security.

Using Key Connection for Drupal, the first encryption & encryption key management module, Drupal developers can now build NIST compliant AES encryption and FIPS 140-2 compliant encryption key management into their Drupal websites.  

Just click below to sign up:

 

It seems like everyday there is a new data breach in the news.

From malicious hackers to unintentional employee mistakes, loss of sensitive data is skyrocketing. Risk management has brought the data breach issue out of the IT department, and into the offices of Enterprise executives. Data loss is considered such a critical issue that encryption and encryption key management is mandated not only by many industry compliance regulations, but also by most state and governmental laws.

Here are a few key thoughts to consider:

5 Misconceptions About Data Security That Put You At Risk

1   If we have a breach, we’ll just pay the fine.

In many cases there will be fines for a data breach, but it is only a small part of the total cost. The cost of a breach also typically includes a forensics investigation, credit monitoring for customers, lost sales due to brand damage, and litigation costs.

2   We’ve never had a problem, so things are probably OK.

This type of thinking is not a form of risk assessment. Since data breaches often take months to discover, you may not know that a breach has already occurred. Wishful thinking won’t help you prevent a breach.

3   My software vendors and consultants say they have everything under control.

Today, many software vendors have not moved quickly enough to add encryption to their core products. It is not wise to rely on vague statements about data security from vendors and consultants. Make sure their solutions have been through a NIST FIPS 140-2 validation, using best practices, and based on industry standards such as AES.

4   My IT staff says we’ve done everything we can.

IT departments may not have the resources or management directives they need to accurately assess and address data security issues. Meeting management’s goals and objectives within a set of operational and budgetary constraints is not the same as meeting security best practices.

5   We are encrypting our data, we are doing everything we should.

If you are encrypting your sensitive data, you’ve already made a good step forward. Do you know how and where your encryption keys are stored? Making sure your keys are not stored with your data is only the first step.  Good key management practices will truly protect your data.

5 Steps to Take to Reduce Security Risk

1   Talk About It

Discuss the importance of data security as it relates to risk management with all members of the organization’s leadership team. Data security is an ongoing process that involves every member of the organization, and will extend beyond your organization’s boundaries to vendors and service providers. Responsibility for data security belongs to everyone.

2   Assess Your Current Data Security Posture

If you have not had an external audit and assessment of your organization’s data security practices by a qualified security professional, now is the time to start. First, perform a data security assessment with an in-house consultant, security audit firm, or platform vendor to evaluate your current security posture. Find the location of all sensitive data. Lastly, evaluate the security of your backup tapes. The right security assessor will help you identify the most urgent problems, and help you prioritize your efforts.    

3   Invest in Encryption and Key Management

When you have located sensitive data that is not encrypted, start a project to encrypt it now. Don’t forget to invest in the necessary encryption key management devices to protect the encryption keys. If your risk assessment warrants, provide budgetary exceptions to address the problem. Invest where you need to, as soon as you can. When choosing an encryption and key management solution make sure it uses industry standard NIST compliant encryption and FIPS 140-2 compliant key management.

4   Strengthen your technology acquisition processes

Every organization relies on off-the-shelf software solutions to manage and run their business operations. If your core applications do not provide encryption and key management to protect data, put your vendors on notice that they must address this issue immediately, and ask for updates. All new technology acquisitions should incorporate data security requirements into the RFP process.

5   Create ongoing review processes and procedural controls

Performing one security assessment or passing one compliance audit will not provide the focus and attention needed to protect you from a data breach over time. You must conduct routine vulnerability scans, create new processes, and review points within the organization to ensure that you continue to monitor your security stance. Use good procedural controls to minimize the chances of fraud. Implement Dual Control and Separation of Duties to achieve a defensible data security stance.

To learn more, download the eBook, "Turning a Blind Eye to Data Security: Mending the Breakdown of Communication Between CEOs and CIOs", and authors Kevin Beaver, CISSP, Patrick Townsend, and Todd Ostrander will teach you about:

• Business risks associated with unprotected sensitive data 
• Tools and resources to begin the discussion about data security in your company 
• Actionable steps YOU can take

Download the ebook today!  

Businesses leaders are becoming more and more scared of an impending data breach. Most IT security professionals agree that a data breach is no longer a matter of “if” but “when”. While major enterprises are now scrambling to implement strong encryption and encryption key management to protect customer data, for many companies, like Target and Home Depot, these efforts are too little too late.

These medium to large enterprise-sized businesses are now holding their vendors and partners to a higher security standard. As a B2B organization that would like to onboard these larger clients, you should consider learning how to implement strong data security into your hardware, software, and cloud applications.

Encryption is one of the best-kept secrets of companies that have prevented or mitigated the consequences of a data breach. Because encryption renders data unreadable, any unauthorized access to that data is useless to the person who sees it. If the encryption key is adequately protected and not discovered by the intruder, then there is no way to decrypt the data and the breach has been secured. Encryption and encryption key management are the most defensible technologies for data breach protection.

Today encryption and encryption key management is as easy as launching an AMI in Amazon Web Services (AWS) in just a few minutes. Developers can now launch Townsend Security’s key manager, Alliance Key Manager (AKM), in AWS, Microsoft Azure, or VMware and receive up to two free licenses to develop and test encryption and key management in their applications. Alliance Key Manager is FIPS 140-2 compliant and provides NIST compliant AES encryption services so that encryption keys never leave the key server.

Businesses are not only concerned with risk management. Meeting compliance using standards-based solutions is also a critical piece to building defensible data security. Especially for government organizations that must comply with FISMA, many CIOs and CTOs won’t even consider an encryption or key management solution that hasn’t undergone NIST certification.

The importance of NIST compliance is far-reaching. Implementing a solution that meets an industry standard means that your solution will stand up to scrutiny in the event of a breach. NIST compliant encryption and key management have been tested against accepted standards for cryptographic modules and are routinely tested for weaknesses. Can meeting compliance regulations still be a low bar? Of course, but following standards and then implementing accepted best practices is the only way to meet compliance and achieve the highest levels of security.

With the Townsend Security Developer Program, you can develop applications that not only meet compliance but exceed them to give your clients the highest levels of security, you can win enterprise clients that you haven’t been able to work with before, and gain access to a host of Townsend Security APIs that have been designed for easy integration into new development projects.

Language libraries we provide for Alliance Key Manager include: Java, C/C++, Windows .NET application source code, Perl, and Python. Also available are client side applications for SQL Server and Drupal CMS.

To learn more and to join our Developer Program, click here.

VMware and PCI DSS Compliance: Taking the right steps in a virtualized environment

As of vSphere 6.5, AES encryption has been added to VMware. With VMWare encryption, complying with PCI DSS, requirement 3 is even easier. And executives are taking note as they look to conserve resources by moving their organizations databases and IT environments to virtualized platforms and to the cloud.

Security best practices and compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

The Payment Card Industry Data Security Standard (PCI DSS) is one of the most rigorous and specific set of standards established to date and is used by many organizations as a standard to secure their systems. PCI DSS applies to all organizations that store, process, or transmit cardholder data, regardless of volume. This includes merchants, service providers, payment gateways, data centers, and outsourced service providers.

Here is a high level look at all twelve items that must be met in order to be compliant, with three new requirements in PCI DSS 3.0 (**) that warrant mentioning as being most relevant to the use of VMware and cloud technologies in a PCI-regulated infrastructure:

Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data


(3.0) **Req. 1.1.3: "[Maintain a] current diagram that shows all cardholder data flows across systems and networks."

Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

(3.0)** Req. 2.4: "Maintain an inventory of system components that are in scope for PCI DSS."

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*


* Requirement 3 specifically addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs


Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know


Requirement 8: Identify and authenticate access to system components


Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data


Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

(3.0) ** Req. 12.8.5: "Maintain information about which PCI DSS requirements are managed by each service provider and which are managed by the entity."

It can seem overwhelming at first, but the PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43.

Fortunately, there are also standards and published guidance on running payment applications in a virtualized environment:

Payment Card Industry Data Security Standard: Virtualization Guidelines and Cloud Computing Guidelines

NIST SP 800-144: Guidelines on Security and Privacy in Cloud Computing

Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing

While virtual technology is not limited to VMware, it is one of the most commonly used and supported architectures by many cloud service providers. In addition to the PCI compliance and cloud guidelines above, VMware worked with CoalFire, a QSA auditing firm, to create guidance on how to specifically deploy payment applications in a VMware environment. You can access the CoalFire document  here.

As platform virtualization becomes a more popular solution, executives need to remain vigilant with their data security and meeting compliance requirements. We can help make the transition to VMware easy with our Alliance Key Manager for VMware solution, which meets the PCI recommendations when deployed properly in a VMware environment. We are committed to helping businesses protect sensitive data with industry standard NIST compliant AES encryption and FIPS 140-2 compliant encryption key management solutions.

Here is a sneak peek at the introduction for the latest regulatory guidance white paper from Townsend Security. For detailed information, download the entire document:

On March 25, 2014, the Article 29 Data Protection Working Party of the European Union issued new guidance on data breach notification and the use of data protection technologies such as encryption and encryption key management. Extending beyond just Internet Service Providers, the new regulations cover all organizations that process, store, or transmit private information of EU citizens. Along with these new regulations, there are substantial financial penalties for failing to protect sensitive information. These penalties can reach into the 10’s of millions of Euros depending on the organization’s size and amount of data compromised.

The European Union does not mandate that all organizations immediately encrypt sensitive data, but the only exclusion for subject data breach notification and financial penalties will be for those organizations who use encryption and other security methods to protect the data. Applying these security methods after a breach will not remove the notification requirements and penalties.

EU Data Protection Directive (also known as Directive 95/46/EC) is a directive adopted by the European Union designed to protect the privacy and protection of all personal data collected for or about citizens of the EU, especially as it relates to processing, using, or exchanging such data. The following guidelines will help meet these new EU objectives:

Encrypt Data at Rest

Make a full inventory of all sensitive personal information that you collect and store. Use strong encryption to protect this data on servers, PCs, laptops, tablets, mobile devices, and on backups. Personal data should always be encrypted as it flows through your systems, and when you transmit it to outside organizations.

Use Industry Standard Encryption

Use industry standard encryption such as Advanced Encryption Standard (AES, also known as Rijndael). AES is recognized world-wide as the leading standard for data encryption. Never use home-grown or non-standard encryption algorithms.

Use Strong Encryption Keys

Always use cryptographically secure 128-bit and 256- bit AES encryption keys and never use passwords as encryption keys or the basis for creating encryption keys. Encryption keys based on passwords will never meet minimum standards for strong encryption keys. Keys should be generated using a cryptographically secure random bit generator (CS-RBG) validated to international standards.

Protect Encryption Keys from Loss

Encryption keys must be stored away from the data they protect and must be securely managed. Manual procedures cannot accomplish the goal of proper encryption key management. Use a professional encryption key management solution to protect keys and provide different keys for different data protection needs. Key management solutions should implement key creation, management, and distribution and be compliant with the NIST FIPS 140-2 standard recognized and accepted worldwide.

Change Encryption Keys Regularly

Using one encryption key for a long period of time can expose you to a breach notification for historical data. Change your encryption keys on a quarterly or semi-annual basis. A good key management solution can automatically change encryption keys at an interval you define.

Use Strong, Industry Standard Hash Algorithms

Use strong, industry standard secure hash algorithms when protecting passwords and other information. Never use MD5 or other weaker hash methods. Use the SHA-256 or SHA-512 methods for your hash requirements.

Use Keys or Salt with Your Hashes

When using a strong secure hash algorithm, always use an encryption key or random salt to strengthen the resulting hash value. You can use the Hashed Message Authentication Code (HMAC) method with an encryption key or use a strong encryption key under the protection of a key manager as the salt for the hash method.

For details on the EU Data Protection Directive...

We all know that in today’s climate of information technology, the steps we take to secure sensitive data must go beyond simply using passwords and firewalls. However, many organizations are still hesitant to adopt encryption and encryption key management, even when it’s mandated by industry regulations and is the strongest safeguard against a data breach. In our new eBook, we’re asking, “What’s preventing you from implementing strong data security?”

Encryption and encryption key management have a reputation for being costly and difficult. This reputation causes organizations a lot of fear. Many people ask themselves, will an encryption and key management project overtake my time and resources? Will it consume my budget? Will it slow down my systems? The good news is, with evolving technology these fears are now based simply on misconceptions. For many organizations, especially those using the cloud, the cost and ease of an encryption and key management project has been greatly improved due to reduced complexity of the Technology. Also, the idea that encryption and key management severely affect performance is usually a misconception of how encryption and key management work in an IT environment, and with proper key management technology, the fear of losing an encryption key is nearly void.

To learn how to overcome the top five most common fears of implementing encryption and encryption key management, check out the excerpts from the new eBook below!

1. Will encryption & key management affect performance on my systems?

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 rarely impact your performance more than 2-4%. Performance impacts can also vary based on the amount of data you’re encrypting 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 that attempt “do-it-yourself” encryption solutions see a much higher performance impact…

2. Encryption & key management is too complicated

In the past, managing encryption keys was incredibly complicated as well as costly and time consuming. Specialized solutions had to be developed for an organization’s specific IT infrastructure in order to provide access as well as limit control to certain users. These projects would take months of development to complete and be complicated for an administrator to manage.

Today encryption and key management is easy with SDKs, sample language libraries, and ready-to-use client side applications provided by key management vendors. Little-to-no programming is required by the user at all, and keys can be automatically generated so that complex configuration steps are entirely eliminated...

3. What if I lose a key?

One of the greatest fears of encryption is key loss. If an organization encrypts data and then loses the encryption key, unless they’ve made a backup of the key or restore access to the key, the data becomes permanently unusable. This could be a nightmare for those encrypting millions of pieces of data, such as customer credit card information that needs to be read and retrieved daily in order to complete transactions and maintain business continuity.

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 of all, protecting encryption keys...

4. Encryption key management is too expensive

Today, a reputable encryption key management vendor will never overcharge you or have hidden fees or costs, and will provide you with information to help you find the right solution, free of charge.

The climate of data security is always changing. However, one thing we know for sure is that hackers are never going away. Hacking is a profitable and growing industry. Firewalls and strong passwords are no longer considered adequate means for protecting sensitive data...

5. 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 it can be implemented in just a few minutes…

To continue reading, download "Overcome the Top 5 Fears of Encryption and Key Management" today.

Protecting sensitive data stored in Amazon Web Services (AWS) is a major priority for SlimTrader, a company helping businesses and individuals in Africa complete secure transactions via mobile ecommerce solutions. SlimTrader chose AWS to host their extensive database of users based on their ability in AWS to reduce costs and scale up as their business grows. The challenge, however, was to find an encryption and encryption key management solution that also featured low initial costs and could scale as well.

Implementing strong encryption and key management in the cloud has been a major challenge in the past. Recently, AWS released the AWS CloudHSM; however, the high startup costs for implementing this encryption key management solution as well as its limitations made this solution an impractical fit. That’s why SlimTrader chose Alliance Key Manager for AWS.  According to Martin Pagel, CTO of Slim Trader:

“Our main challenge is that we’re cloud based, so we can’t use an HSM because we don’t have a physical IT infrastructure. We want to do it the right way, and do it in the cloud. With Alliance Key Manager for AWS I can deploy encryption key management the way I want, and I don’t have to ask anyone in Amazon for help.”

Alliance Key Manager not only scales to meet your business needs, but also gives you complete administrative control over your own virtual key server. Having this level of control is critical in a cloud environment where you may not be sure who you are sharing resources with. Alliance Key Manager also uses the same FIPS 140-2-compliant encryption key management and NIST-validated AES encryption service found in Townsend Security’s HSMs so that you can provably meet compliance requirements for several industry security regulations. Meeting compliance requirements is important to SlimTrader and many of their larger customers.

Overall, Townsend Security helped SlimTrader achieve their security goals and overcome security challenges in four major ways:

• Making encryption and key management in AWS easy. For many businesses, moving their data to the cloud is simply more practical than assembling an internal IT department. It is also significantly easier.  “The ease of firing up an AKM cloud instance and having control over it appeals to me,” said Pagel, “And I don’t have the limitations of needing to install a physical box.”
• Making encryption and key management in AWS affordable. SlimTrader also chose AKM for AWS for affordability. With Alliance Key Manager for AWS, SlimTrader is taking advantage of Townsend Security’s no end-point license fee model that will allow them to grow without burdening their budget. For strong data security to become ubiquitous, and for data breaches to become fewer, encryption and key management must become affordable. With AKM for AWS, small businesses such as SlimTrader can lead the way in data breach prevention.
• Providing encryption and key management that works with their applications. SlimTrader needed a key management solution that would work seamlessly with MySQL and Drupal in AWS. Alliance Key Manager is designed from the ground up to integrate with many platforms, applications, and databases and can protect encryption keys for data encrypted at the application level.
• Certified Solutions. SlimTrader works with several banks and government agencies in Africa who consider PCI compliance important. “When we manage data on their behalf, we need to manage it securely,” says SlimTrader CTO Martin Pagel. FIPS 140-2 compliance is critical for many organizations who must meet government standards, and important for businesses that want provably defensible encryption key management.  Alliance Key Manager also provides onboard NIST-validated AES encryption service. This service allows you to provably meet compliance regulations for encryption.

To see for yourself how easy encryption and key management can be in Amazon Web Services, download a free 30-day evaluation.

Logistics and the Food Bank

I observe an incredible amount of logistics when I volunteer each month at our local food bank. Food is donated from a multitude of sources including government programs, community food drives and individual contributions. It arrives packed in bulk quantities on pallets from the federal government and in small grocery bags of assorted items from local citizens. All of the items need to be resorted and repackaged so that families will have access to a variety of foods in quantities that meet their needs.

My first few volunteer sessions I floated around to various departments like produce and dairy, but lately find myself consistently in the dry goods sorting room where pallets of assorted items are delivered to the sorting room to take the next steps in the process from arrival to distribution: 

1. Teams of volunteers sort a box at a time into carts by type so that they can be counted.  
2. Boxes of donations are resorted into carts by type of item such as canned vegetable, cereal, oatmeal, fruit, large soup, small soup, coffee, tea, baking ~ there are close to forty different sorts. 
3. Each group of items is then counted and entered into the tracking system that records the amount by donor.  
4. The counted items are sorted into their storage bins and then stocked to the shelves for clients to choose from.

The same process and sort function goes on in other departments ~ dairy products into yogurt, eggs, milk; pizza & baked goods into smaller packages; produce into bins by type. Any particular item gets handled several times from its initial donation until it ultimately is delivered to the community.

I think I probably demonstrated my accounting inclinations at an early age ~ I was always sorting items by type, color, whatever I could figure out.  I’ve come to see accounting as a giant sort function, taking large amounts of data and sorting it into its relevant buckets.  I find it a bit funny that volunteering with cans of green beans and packets of oatmeal, I am still doing the same function.  

As always, each time I volunteer, I am humbled by the grace and kindness of the volunteers and clients at the food bank.  I am grateful that Townsend Security encourages and allows me the opportunity to contribute back to our community with its Volunteer Program.

Sandra, Controller at Townsend Security

The time required to crack an encryption algorithm is directly related to the length of the key used to secure the data.

Every now and then, our development team comes across someone still using antiquated DES for encryption.  If you haven’t made the switch to the Advanced Encryption Standard (AES), let’s take a look at the two standards and see why you should!

Data Encryption Standard (DES):

DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005 [although NIST has approved Triple DES (3DES) through 2030 for sensitive government information].

The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.

To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).

• The DES I contest (1997) took 84 days to use a brute force attack to break the encrypted message.
• In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was "The unknown message is: Many hands make light work". The second challenge took less than three days, with the plaintext message "It's time for those 128-, 192-, and 256-bit keys".
• The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation's Deep Crack computer (built for less than $250,000) and distributed.net's computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read "See you in Rome (Second AES Candidate Conference, March 22-23, 1999)", and was found after checking about 30 percent of the key space...Finally proving that DES belonged to the past.

Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

Advanced Encryption Standard (AES):

Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES. In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.

One of the original requirements by the National Institute of Standards and Technology (NIST) for the replacement algorithm was that it had to be efficient both in software and hardware implementations (DES was originally practical only in hardware implementations). Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous. Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).

Comparing DES and AES

So the question remains for anyone still using DES encryption…
How can we help you make the switch to AES?