Townsend Security Data Privacy Blog

When the weather outside is frightful, keep a watchful eye on those tracks in the snow!

I used to love looking out the sliding glass doors at my parents deck when it would snow. I would rush to the cold glass first thing in the morning to see just who had been out and about. It was always exciting to see what footprints the various critters had left behind from the night before. Strange topic for a tech blog to be sure, however this memory always pops to the front of my mind when discussing system logging, log collectors, and their ever-important counterpart, SIEM solutions. The one question I hear most in our support department is “I’ve got a log collector do I really need a SIEM?” Well let’s think about that and compare log collection and monitoring to a fresh snowfall.

Envision the log collector as a blanket of snow over a deck. The deck in this example represents your database, the footprints are the events. Just one database server can generate millions of events in a day. With that kind of traffic your blanket of snow is going to become packed ice very quickly. You wouldn’t be able to pick out and clearly identify any one specific footprint from that mess. The shear amount of events generated by the average system makes detecting an anomalous event a logistical nightmare for a human observer. So simply having a good log collector is great, but it is only half of the equation. You have to be able to identify events and act on the information gathered, preferably in real-time.

One morning, after it had snowed I was up early peering out at the snow cover when I noticed boot prints near the garage. This was unusual as we lived in a relatively rural area. I told my parents what I’d seen, and tried to show them, but the snow was starting to melt. So the evidence that I had seen was rapidly being lost to time and inactivity. My parents brushed off my concern and went on with their day, opting to forego any further “analysis”. The following morning they awoke to an open garage door and a missing car.

This scenario is strikingly similar to how cyber criminals operate. Evidence of a breach is often left long before any data is actually stolen. It can take weeks and, in some cases, months for an intruder to find the data they want and take it. Early detection has spelled the end of many data theft attempts. Unusual events like someone accessing the system from an unfamiliar location, or an unexpected access of a sensitive file can be identified before data goes missing. All of those events show up in the system logs, but if you aren’t doing anything with the information, then you are making it easy for criminals to get what they came for. When properly deployed, and monitored in real-time, a SIEM can be your strongest weapon in actively preventing breaches.

Proper set-up can appear to be daunting because the system logging solution needs to be able to understand the events being received. The SIEM can’t correlate data to recognize patterns, and identify suspicious activity if the log collector is sending events in a language the SIEM doesn’t understand. In a perfect scenario SIEMs and log collectors would work together to create an “out of the box “ solution. Townsend Security has recently worked with IBM to enhance our system logging solution to include support for IBM Security QRadar.  Alliance LogAgent for IBM QRadar can now send events in IBMs “Log Event Extended Format” or LEEF to the QRadar SIEM. Because we worked directly with the IBM team for the QRadar Device Support Module (DSM) definitions, you just need to pull the latest DSM definitions from IBM to get started. Though it’s similar to other log formats like syslog, QRadar can sort and use the information received without any major set up.  This means that instead of logging tons of unreadable, unsorted events, you can query the SIEM to find something specific like a log on, or file change - which, going back to the original analogy, can help you find the boot prints in the snow!

Alliance LogAgent for IBM QRadar works seamlessly with IBM Security QRadar to give you the real-time, active monitoring tools you need to be proactive when dealing with a potential data breach. For more information, request this white paper on Making Security Better for the IBM i and IBM QRadar:

Easier Encryption and Key Management for SQL Server Standard & Web Editions

Your IT environment is ever changing. As technologies evolve, you constantly have to upgrade systems and migrate to new platforms to accommodate these changes. This often results in complex IT environments that are comprised of multiple platforms and operating systems, and data located in disparate locations. Protecting sensitive data in a multi-platform environment that’s made up of both old and new technologies can be one of the most frustrating aspects of data security.

One of Townsend Security’s core missions is to help customers protect sensitive data, regardless of where that data resides, in a cohesive way. One area where we’ve seen the need to improve upon this is around encrypting data in Standard versions of Microsoft SQL Server. Because Microsoft does not provide transparent data encryption (TDE) capability on SQL Server Standard and Web editions, Microsoft customers using these older editions struggle with implementing easy and fast transparent encryption.

In order to simplify the encryption process for Standard and Web Edition users, we have partnered with NetLib, a database encryption solution provider that supports easy and automatic folder, file, and application encryption in Windows as well as database and column level encryption for all Microsoft SQL Server editions. NetLib Encryptionizer easily protects data in SQL Server (2000-2014), Standard, Web, Workgroup and Express Editions. NetLib provides column level encryption as well using triggers and views without the need to write SQL statements or any other development.  

NetLib’s customers choose NetLib Encryptionizer for their FIPS 140-2 compliant encryption solution, for which they require FIPS 140-2 compliant encryption key management as well. As a critical step in our partnership, Townsend Security built Key Connection for Encryptionizer, a no-cost plug-in module that allows Encryptionizer customers to easily secure encryption keys using Townsend Security’s Alliance Key Manager.  

System audits and logging are critical to detecting and alerting you to malicious activity in your systems. Key Connection for Encryptionizer allows users to fully audit the encryption and key management process. Encryptionizer audit logging of user-file interaction as well as audit logging of the key life cycle in Alliance Key Manager provides a comprehensive logging service. Additionally, encrypting data on SQL Server Standard and Web editions typically involves some level of development. With NetLib Encryptionizer, users can encrypt data using a simple point-and-click configuration.

Townsend Security is proud to partner with NetLib to provide an easier method to encrypting data in Microsoft SQL Server Standard and Web editions. To learn more about managing encryption keys for data encryption in complex environments, download the white paper, Key Management in the Multi-Platform Environment.

Article 29 Security Guidelines on Data Protection

The Article 29 Working Party is composed of representatives of the national data protection authorities (DPA), the European Data Protection Supervisor (EDPS), and the European Commission. It is a very important platform for cooperation, and its main tasks are to:

1. Provide expert advice from the national level to the European Commission on data protection matters.
2. Promote the uniform application of Directive 95/46 in all Member States of the EU, as well as in Norway, Liechtenstein and Iceland.
3. Advise the Commission on any European Community law (so called first pillar), that affects the right to protection of personal data.

Under EU law, personal data can only be gathered legally under strict conditions, for a legitimate purpose. Furthermore, persons or organisations which collect and manage personal information must protect it from misuse and must respect certain rights of the data owners which are guaranteed by EU law.

Every day within the EU, businesses, public authorities and individuals transfer vast amounts of personal data across borders. Conflicting data protection rules in different countries would disrupt international exchanges. Individuals might also be unwilling to transfer personal data abroad if they were uncertain about the level of protection in other countries.

Therefore, common EU rules have been established to ensure personal data enjoys a high standard of protection everywhere in the EU. The EU's Data Protection Directive also foresees specific rules for the transfer of personal data outside the EU to ensure the best possible protection of sensitive data when it is exported abroad.

In order to help address these EU objectives, Patrick Townsend, Founder and CEO of Townsend Security recommends the following data protection best practices:

• 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.
• Use Industry Standard Encryption
  Advanced Encryption Standard (AES, also known as Rijndael) is recognized world-wide as the leading standard for data encryption.
• Use Strong Encryption Keys
  Always use cryptographically secure 128-bit or 256- bit AES encryption keys and never use passwords as encryption keys or the basis for creating encryption keys.
• Protect Encryption Keys from Loss
  Encryption keys must be stored away from the data they protect.  Keys must be securely managed and should be compliant with the industry standards such as NIST FIPS 140-2 which is recognized and accepted worldwide.
• Change Encryption Keys Regularly
  Change your encryption keys on a quarterly or semi-annual basis. Using one encryption key for a long period of time can expose you to a breach notification for historical data.
• Use Strong, Industry Standard Hash Algorithms
  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
  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 more detailed information on these recommendations, download the white paper on the "EU Data Privacy Protections and Encryption":

An excerpt from the latest white paper “How to Meet Best Practices for Protecting Information in AWS” by Stephen Wynkoop, SQL Server MVP, Founder & Editor of SSWUG.org

Working in the cloud presents several challenges unique to that environment, including significant growth and change in the area of data protection and encryption. There is much confusion about what is - and is not - encrypted and protected.  This encryption of information, and the management of the keys and access controls is a core objective of this paper. If you can render information useless if accessed illegitimately, you have successfully addressed a whole host of regulations, compliance and best practices.

The very definition of protection by cloud providers is an important part of understanding the requirements and challenges of your configurations and information protection. AWS approaches data protection in several ways that impact your systems. The first is the configuration and design of your infrastructure. This consideration includes establishing Virtual Private Clouds (VPC) and providing for encryption of some information stores. The challenge exists in understanding the protection of these information stores and determining what you need to do to bring these protections in line with your requirements and compliance areas.

As you consider your systems, data protection will come down to several important areas:

• Physical access controls – This refers to the doors, secure access controls and other protections at the physical server and server room level.
• Logical access controls for your systems – These are the controls you put in place to prevent unwanted access to information.
• Data access – Data access controls are typically enforced at the information stores level.
• Protection of data in case of a breach – This is addressed by making the information in your systems unusable if accessed in a way that is unwanted.

Stephen’s white paper also covers the impact on data protection in public vs. private clouds, security fundamentals in AWS, and the best practices for deploying an encryption key management solution including:

• Segregation of Duties
• Dual Control and Split Knowledge
• Key Creation (and understanding strong keys)
• Key Rotation
• Protection of Keys
• Access Controls and Audits (Logging)

In his white paper, Stephen also discusses cloud-provider-based key management services and some of the important features, options, questions, and concerns that should be considered before selecting a service or a key management solution. Some important aspects to understand are:

• Control, Ownership, and Access - By managing your own encryption services and providing for industry-compliant key management and data protection practices, you help ensure that your data remains managed by your own secure keys.
• Multi-Tenancy and Key Management - In a worst case scenario it’s possible that keys could be compromised.
• Access to Keys - Many systems and architectures are based on hybrid solutions. Cases where there are systems on-premises combined with systems in the cloud are areas that will be problematic with the AWS services. Systems not on the AWS hosted services will not have access to the key management services on AWS.

There are many different considerations when thinking about the choices in your key management solution. Be sure to fully understand logs, key management, backups and other elements that provide the utility you require. Finally, be sure you’re checking for proper compliance and certification of the solutions you are considering. It is important that any solution you choose has been through a FIPS 140-2 validation, and that you have a full understanding of any PCI, HIPAA or other regulatory body requirements.

Please download the full document to learn more about protecting information in Amazon Web Services and how Townsend Security’s Alliance Key Manager for AWS provides a FIPS 140-2 compliant encryption key manager to AWS users who need to meet data privacy compliance regulations and security best practices.

Understanding PCI Merchant Levels and how an assessment can help your business

If your business takes credit cards for payment, then you are subject to the Payment Card Industry – Data Security Standards (PCI-DSS).

Companies of all sizes must comply with PCI DSS to ensure that their customers' data is protected during the processing and transmission of credit or debit card transactions and securely stored within any internal databases. PCI categorizes businesses into different classification levels based on the number of transactions and dollar amounts they processes each year.

Level 1 – All merchants processing more than 6 million card transactions annually

Level 2 – All merchants processing between 1 million and 6 million card transactions annually

Level 3 – All merchants processing between 20,000 and 1 million card-not-present only transactions annually

Level 4 – All other merchants

Level 1 companies are most likely well versed in the annual PCI audit process as they have a certified onsite audit annually with a Qualified Security Assessor (QSA). Level 2, 3, 4 merchants are not required to hire an onsite QSA, but can have a certified Internal Security Assessor (ISA) do the PCI self assessment annually. However, a small business preparing a self-assessment to participate in their first PCI review may find it a little daunting. If you're feeling that the PCI assessment process is overwhelming and complicated, understanding this process may be the first step toward putting your mind at ease. If you are a Level 1 merchant, the PCI assessment is a process carried out by a QSA to establish whether or not a business is compliant with security standards relating to the processing of transactions made via a credit or debit card (payment card). PCI compliance assesses your business point of sale system, payment applications, and all interconnecting systems with these goals in mind: (1) to examine your system, (2) to identify vulnerabilities, and (3) to prevent data from being compromised.

It’s not a matter of “IF”, but “WHEN”

If you have already suffered a data breach, working closely to review your assessment and put data security best practices into place will provide you with a roadmap to help avoid future losses. If you have not yet been breached, undergoing an assessment and reviewing your risk tolerance can still be stressful. Understanding the process may alleviate some of that stress and help you to maximize your use of the information in the PCI DSS assessment report

How can a PCI audit help my business?

PCI compliance auditing helps businesses to ensure they are providing the most secure environment for their customers to process payments and ensures that transactions are less likely to result in a compromise in the customers' data.

Ensuring that you meet PCI compliance and have a solid infrastructure for managing data security will increase customer confidence in your business and ensure that you're not exposed to security breaches that could have been avoided. 

To learn more about meeting PCI compliance requirements, download the whitepaper Meet the Challenges of PCI Compliance and find the answers to the following questions (and more):

• What will my auditor look for?

• How can I ensure my customers' data is secure?
• What is the difference between tokenization and encryption?
• What is encryption key management and why are auditors looking at this?

From the PASS Summit to the Worldwide User Group (SSWUG)

From Developers to Database Administrators, we have met another amazing group of people at the PASS Summit 2014. Over 5,000 members of the Professional Association for SQL Server converged on Seattle, WA and we got to talk about security with people from all over North America and from as far away as Norway, Spain, Australia, Colombia, Germany, and even Iceland.

We spent most of our time talking about the importance of encrypting sensitive data, and about using an encryption key management solution to protect encryption keys away from the database. There is a huge need to meet compliance regulations, and with all the options now available (Hardware appliance, Cloud HSM, VMware virtual environment, and cloud instances in AWS or Azure) there is a solution for each scenario we encountered.

If you are working with SQL Server, we hope you are familiar with the SQL Server Worldwide User Group (SSWUG).  If you don’t know about them, please allow me a moment to introduce you to Stephen Wynkoop who is the founder and editor for SSWUG.org. This website is a wealth of information about everything you would want to know about SQL Server (and they are even branching out to other database systems like Oracle and IBM DB2). The emphasis at SSWUG has been on SQL Server and you will find a large number of articles, blogs, videos and other content on wide variety of topics related to it. Stephen features weekly video programs about the database and IT world, webcasts, articles, online virtual community events and virtual conferences several times a year. He 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.

SSWUG has dedicated a section of their web site to the SSWUGtv Security Edition “Townsend Security Series” where they present videos of Stephen and our own industry expert, Patrick Townsend, discussing security topics ranging from securing data with encryption and key management on SQL Server (not just with EKM) to protecting data in the cloud. Additionally, they post a new security segment just about every week on their homepage, so there is always something fresh. A few of the sessions include topics such as What top industries do Hackers focus on and why? and Cross-platform security: How do you have a hybrid environment and keep it secure?  

Check out this one on: PCI Compliance and Security in the Cloud - (11 minutes) 

Stephen and Patrick have a great time recording these videos, and if you haven’t seen any yet, I urge you to check them out. In addition to all the great content on the SSWUG website, SSWUG also holds virtual conferences and Summer Camps that are great online resources for developers.

You are also invited to download this latest white paper, authored by Stephen Wynkoop, on understanding options and responsibilities for managing encryption in the Microsoft Azure Cloud.

Taking Security Beyond Usernames and Passwords

Security professionals understand that passwords alone are just not good enough protection, and the on-going flood of data breach reports just confirms this on a daily basis. Enterprise IBM i users aren’t going to stop using passwords to login to their IBM i platforms, and hackers aren’t going to slow the flood of attacks any time soon. But now, we can take a giant security step forward by implementing two-factor authentication (2FA) to dramatically reduce the risk of a security breach.

Compromised email, social media, online gaming, ecommerce, financial services and other types of cracked accounts continue to threaten both personal and corporate interests. Out of all the threats that face individuals and companies, account compromise stands out as one of the most easily addressed with available and mature security technologies.

Historically, companies used physical tokens to provide authentication on the IBM i beyond username and password. Even if someone hacked a user’s password, they still could not login without the physical token. Tokens represent another layer of protection, which is a step in the right direction. Unfortunately, tokens increasingly do not make fiscal sense for Enterprise IT departments who have to deploy, manage, and troubleshoot large numbers of tokens. There is a better way for organizations to quickly and cost-effectively roll out two-factor authentication to a large and sometimes global user base. Solutions that leverage the mobile phone as a reliable means of authentication have become readily available for the IBM i platform. For example, instead of tokens, businesses can simply send an SMS or voice message that contains a one-time authentication code to the individual user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone.

Mobile phones and landlines present key advantages for verification and authentication regimes:

• They possess unique identifiers – phone numbers, electronic identifiers and account numbers
• They remain in the possession of users or near at hand most of the time
• They are difficult to spoof
• If stolen or otherwise misappropriated, they are easy to disable
• Their association with actual individuals is verifiable through the operators that provide phone service

While none of these attributes alone are sufficient, together they provide a compelling basis for verification and authentication. The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat than a login password. Combining something the person knows with something they have, or something they are, which can then be used for two factor authentication.

1. Something you know - a password. 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.

2.  Something you have - a mobile phone. 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.

3. Something you are – biometric authentication options.  Physically scanning for an 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.

The IBM i platform has a well-earned reputation for security, but security is only as strong as the weakest point in the enterprise network. User PCs, internal and external web servers, and network applications represent points of attack. These systems are not safe from:

• Memory scraping
• Keyboard logging
• Stolen vendor credentials
• Stolen user passwords from external web services

Due to the nature and the extent of these security threats on the IBM i, two factor authentication has become a viable solution for meeting compliance regulations and safeguarding the vast amount of data and numbers of users with access to sensitive information on the IBM i. 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 and IBM i users now have an affordable solution for their platform. Find out more by downloading this white paper:

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

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?

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

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

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

Architecture Decisions Drive Technology Approach

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

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

Impact of Encryption

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

• Performance
• Backup and Restore Operations
• High Availability

Key Management Fundamentals

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

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

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

Author Bio: Stephen Wynkoop

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