Data-centric security means planning for and implementing encryption and the proper management of encryption keys regardless of the environment.

All data security plans should constantly evolve to reflect changes in business and compliance regulations, as well as policy and infrastructure changes. Because of this evolution, developers are often called upon to modify existing applications, and to implement new or better security solutions. They also are often required to add new security applications in order to meet data protection best practices or prepare for an audit to meet compliance requirements (PCI DSS, HIPAA, FFIEC, etc.).  

What do developers need to know about coding for compliance?

From the ground up, regardless of the platform or language you use, it is the data security mindset that is critical. Developers need to be aware of protecting sensitive data when writing code because ever-evolving compliance requirements call for that disposition. There should be an emphasis to meet industry compliance standards from the beginning design stages. Code needs to be built with those data protection requirements in mind so that is doesn’t have to be reengineered. Projects can sink or fail due to inadequate data security measures, which can put a whole organization at risk.

Whether you are working in hardware, virtual, or cloud environments, understanding and identifying where sensitive data will reside is very important from day one. There needs to be an understanding of the criminal mindsets that will be trying to breach the systems you create, proper preparation for security audits, and a full knowledge of the compliance guidance available to meet industry standards. Developers should also develop for every possible platform/application that the project might be deployed on. As applications move more to multi-tenant cloud environments, you want to make sure you are not locked into or out of a particular platform. You want your code to be compatible from day one with hardware, VMware virtual environments, and cloud platforms. As more organizations move away from using only hardware, VMware technology is at the center of a revolution around virtual and cloud environments. VMware (the company) has done a great job with providing educational materials, helping developers program in a compliance fashion, and producing reference architecture for PCI compliance.

As developers know, their customers want “out of the box” third-party solutions that already meet required security validations. A few of the fundamental basics to keep in mind when developing for data security compliance:

• Use encryption standards such as AES encryption for data-at-rest.
• Use proper Encryption Key storage and management tools
• Do not burn the keys in code
• Do not store keys on the same server as the protected data
• Plan for a compliance audit from the beginning stages

It is also important to look for solution providers that will talk with you before just giving you an instant trial download, it is a good idea to make sure their solution is a technical fit, and not a waste of your time. This is something we do here at Townsend Security with all of our products. We offer a 30-day full version trial of all our software so that you can do a full proof-of-concept and test in your environment. We also feel it is important to supply client-side applications, SDK’s and modules that fit naturally into the platforms and languages that match your development environment. I encourage you to take a little time to listen to this podcast and hear from Patrick Townsend, the Founder & CEO of Townsend Security, on his perspective for developers.

Looking into 2016, what is the role encryption key management will play in securing sensitive data?

Encryption and key management are the Fort Knoxes of security technologies for organizations wanting to protect sensitive data from hackers and data breaches. While commonly used by retail and financial institutions (and gaining even more traction after the onslaught of retail data breaches we saw in 2014), we still see major gaps and problems with implementation of these technologies across multiple industries. In 2015, with over 181 million records exposed in data breaches by mid November, we ask ourselves, what are the challenges of implementing encryption and key management, how widely are they used today, and what can we expect from encryption and key management vendors looking forward?

While encryption has become an easily accessible technology, it remains a major point of struggle for most companies. Since organizations have multiple departments with siloed technical infrastructure, many different tools must be used to manage data across the enterprise. From HR to Accounting to stored customer data, many different platforms, operating systems, databases, and applications are used to store and process sensitive information. This makes locating this data extremely difficult as well as achieving consistent data encryption that can be managed from a single, central location.

Boards of directors and executives are becoming more aware that data security is not just a technical problem, but a governance, risk management, and compliance problem that deserves the same level of attention to risk as financial, legal, and corporate aspects of their business. However, employees at the IT level still hold the most buying influence over encryption and key management technologies.

These sorts of buying decisions have historically landed in the wheelhouse of IT Operations; however, the primary issue that arises in these decisions is that  complicated data security projects are often perceived as a threat to operational continuity. When an IT professional feels they must choose between security and functionality, they will always choose function to avoid the dreaded business-down scenario. Companies should not have to chose between security and continuity, and today, security professionals advocate that executives assign an IT security team to advocate for security solutions and work with IT Operations to implement these technologies.

According to the Ponemon Institute 2015 Global Encryption & Key Management Trends Study, meeting compliance requirements such as PCI-DSS remains the primary driver for encryption and key management implementation. PCI-DSS and federal and financial regulations such as FISMA and GLBA/FFIEC also continue to set the strictest data security regulations. However, despite compliance with industry regulations, organizations still experience breaches, often by a hacker accessing their network through a third party vendor or through employee mistakes. Sadly, often these breaches reveal that data was not encrypted, despite industry compliance.

This flagrant lack of encryption begs the question, will our data security ever get better, or will hackers continue to be one or even two steps ahead?

The answer to that question may come from the fact that in many large corporations, about 80% of resources allocated for data security apply towards network and anti-virus security. This includes firewalls, malware detection, and other intrusion-prevention software. The problem with relying mostly on network security is that hackers continually succeed in breaking through these barriers, often using social engineering and phishing scams to achieve enough authority to open a door and walk right in. Once inside, they discover sensitive data stored in the clear and steal it.

Network security is always an important part of a data security plan, but time after time we see encryption, which is also a critical part of that plan, implemented after-the-fact. This comes back to the issue of sensitive data being difficult to locate inside an enterprise, but the sheer amounts of unencrypted data that hackers are able to discover leads one to believe that some organizations simply do not implement encryption very well. This may be backed up by the discovery that only 37% of companies in the U.S. deploy encryption extensively (as opposed to partially) across their enterprise.

Diving deeper into the challenges surrounding encryption, one of the most painful parts of encrypting data is managing encryption keys. Even if a company encrypts a database of customer credit card numbers, if they do not protect the encryption key, a hacker could easily find the key and decrypt the data, rendering the encryption useless. Unfortunately, protecting and managing encryption keys away from encrypted data is still something organizations fail to do.

As organizations begin to move into the cloud and virtualized environments, as many already have, another stumbling block will be lack of availability of hybrid (cloud and in-house) encryption and key management solutions.

Looking into 2016 and beyond, the key management solutions that will excel will be the solutions that can manage encryption keys anywhere your sensitive data is located whether that be in the cloud, virtual platforms, or hardware. A majority of companies believe that hybrid deployment in both cloud and on-premise is the most important feature of an encryption solution. Without strong hybrid key management, encryption of data spread across an enterprise and the cloud will become even more difficult. Key management vendors that follow their customers into virtual environments will, in the long term, deliver more comprehensive data security.

It’s hard to imagine that data breaches will begin to diminish any time soon, but hopefully organizations will learn from others’ mistakes. It is clear from the evidence that deployment of encryption is nowhere near complete across most organizations, and lack of encryption key management continues to be a challenge, but working with the right encryption key management vendor can ease this pain.

When looking for a key management vendor that can help you manage encryption keys across your enterprise, including the cloud, look for a key management vendor that has:

• No hidden or additional fees for nodes or client-side applications
• Commitment to innovation and development
• Commitment to legacy products
• Excellent reputation for customer support

 

How to implement solutions that are based on compliance standards and meet security best practices.

As more and more Enterprise businesses move into virtual and cloud environments, they face challenges and security issues in these multi-tenancy situations. VMware customers benefit from the many operational and cost efficiencies provided by VMware virtualization technologies both in traditional IT infrastructure and in cloud environments. As VMware customers deploy data encryption solutions as a part of their defense-in-depth strategy, the need for compliant encryption key management can present barriers to a good encryption implementation. It is possible to deploy a proper encryption key management solution within the VMware infrastructure without the need for traditional hardware security modules (HSMs) when this approach is appropriate to the security needs of the organization.

Here is some high level guidance on how to deploy and protect a solid encryption and key management solution for VMware within your virtual or cloud environment. While these recommendations are general in nature (actual VMware deployments will use different VMware applications and architectures to meet specific user, application, and security needs) they can provide a good roadmap.

Seven General VMware Recommendations

1. Identify and Document Trusted and Un-Trusted Applications

Properly identifying application groups based on the level of trust is critical for a secure implementation of virtualized applications and encryption key management services. Create and isolate a management cluster for your core VMware applications such as vSphere, vShield, etc. Identify application groups and their associated level of trust, and isolate applications into appropriate workgroups. Avoid mixing trusted and untrusted applications in a workgroup.

You should consider creating a security workgroup to contain your third party security applications such as encryption key management, authentication services, active directory, system logging, and other applications whose primary function is to assist in securing your applications in your VMware environment.

In preparation for properly securing these environments, create an inventory of all Virtual Machines managed in each workgroup. For each workgroup and virtual machine, identify the security controls that will be required for each one (network segmentation, storage segmentation, system logging, active monitoring, etc.). VMware flow tools can assist with this documentation.

2. Restrict Physical Access

Fundamental to all IT security implementations is proper security of the physical environment. This means proper physical security controls and physical monitoring of the data center as well as good auditing and procedural controls. These physical controls should also apply to access of VMware management and security applications. You can look to the PCI Data Security Standards and guidance for information on appropriate physical controls. You can also refer to standard security guidance in SOC 2 and SOC 3 assessments for information on physical controls. When deploying on a cloud platform it is always a good idea to ask the Cloud Security Provider (CSP) for a copy of the PCI letter of attestation, or an SOC 2 / SOC 3 report.

3. Isolate Security Functions

Because security applications are often a target of cyber-criminals, you should isolate them into their own security workgroup and implement the highest level of VMware security. Only trusted VMware administrators should have access rights to the encryption key management solution, system logs, and audit reports. Be sure to actively monitor access to and use of all encryption key management, key retrieval, and encryption services.

4. Change VMware Default Passwords

Review all VMware applications used to secure and manage your VMware environment and change the default passwords as recommended by VMware. The failure to change default passwords is one of the most common causes of security breaches.

5. Implement Network Segmentation

Network segmentation is easy to accomplish with VMware network management and security applications and you should implement network segmentation to isolate applications that process sensitive information from applications that do not require as high a level of trust. Additionally, you should provide network segmentation for all third party security applications such as your encryption and key management solution. Network segmentation should include all high availability and business recovery infrastructure. Do not rely on virtual network segmentation alone; use firewalls that are capable of properly securing virtual networks.

6. Implement Defense in Depth

The VMware management and security applications provide for a high level of security and monitoring. They also provide hooks and integration with third party security applications that provide system log collection, active monitoring, intrusion detection, etc. Encryption is a critical part of a defense-in-depth strategy, and protecting encryption keys is the most important part of an encryption strategy. Regardless of the operating systems in your application Virtual Machines, your solution should provide encryption key management, key retrieval, and encryption services for your business applications and databases running in your VMware infrastructure.

7. Monitor VMware Administrative Activity

Use an appropriate SIEM solution to collect VMware application and ESXi hypervisor system logs and perform active monitoring. The log collection and SIEM active monitoring solutions should be isolated into a security workgroup that contains other third party security applications such as Townsend Security’s Alliance Key Manager.

For additional information on securing Alliance Key Manager for VMware, our encryption key management solution, request the VMware Resource Kit containing the Guidance Document and other valuable resources:

As solutions and implementations vary a great deal, always consult with a security specialist and compliance auditor for specific guidelines for your industry and environment! Just contact us to get started!

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":

It’s not just “Target”… everyone has a bullseye painted on their information!

Forget about vampires, werewolves, and other things that go bump in the night.  If you want to be truly frightened this Halloween, just take a look at some of the 395 data breaches reported in the first half of 2014 alone.

According to the Identity Theft Resource Center there has been a 21% increase in breaches (and that is just the ones that have already been reported to regulators) in the same period as last year.  Some of these you may be familiar with, others might surprise you:

• eBay - online retailer
  The breach is thought to have affected the majority of the 145 million members when a database containing customer names, encrypted passwords, email addresses, physical address, phone numbers, and dates of birth was compromised.
• Home Depot
  In a large nationwide malware attack, 56 million card records were stolen through point-of-sale systems. In a second attack in Atlanta, 20,000 employees personal information was stolen and used to open fraudulent credit cards by 3 human resource employees.
• Michaels Stores - craft stores nationwide
  The point-of-sale (POS) systems at 54 stores were attacked using malware and up to 3 million payment card numbers and expiration dates were obtained.
• Snapchat (online photo app and delivery service)
  4.6 million accounts were hacked and millions of images stolen. The information (phone numbers and user names) database posted online at Reddit and another site that has now been taken down.
• Neiman Marcus (retailer)
  1.1 million payment cards were compromised over a period of 8 months as hackers repeatedly breached the point-of-sale systems through a central processing server.
• AIG (American International Group)
  774,723 customers - The insurance provider confirmed the theft of a file server and two laptops that held personal information was by a former financial adviser.

Those are some pretty significant numbers, and most likely everyone that reads this blog has been affected in some way by at least one of these events. What we all need to remember is that cyber crime isn’t limited to “Black Hat” hackers that only go after the big piles of data.  Sometimes it is a disgruntled employee that destroys or releases sensitive data. Sometimes it is an unintentional employee error, or loss of an employee’s laptop/thumbdrive that thieves go after.  Often it is the smaller company or mid-sized Enterprise that hasn’t yet implemented security steps, like encryption and authentication, to protect their sensitive information.  

If the first list didn’t give you a fright, here is another that might make you tremble with fear. However, we would prefer if it resulted in the topic of data security brought up at your next security and risk management meeting!

University of Maryland
307,079 individuals - personal records
*Hackers broke in twice and stole data

North Dakota University
291,465 student and staff records

Sutherland Healthcare Solutions
168,000 patients
*Stolen computer equipment containing personal health & billing information

Sally Beauty Holdings (retailer)
25,000 customers lost credit card data to a hacker

Catholic Church - Archdiocese of Seattle
90,000 employees and volunteers - database records

Goodwill Industries (charitable resale)
868,000 customers from approximately 330 stores

Jimmy John’s (national sandwich shop)
*undisclosed number of customers from 216 corporate and franchised locations

Internal Revenue Service (IRS)
20,000 individuals affected
*Employee incident - loaded an unsecure drive into insecure home network

Assisted Living Concepts
43,600 current and former employees in 20 states, had their payroll files breached when the vendor’s system was hacked.

Coco-Cola
74,000 people lost unencrypted personal information to a former employee from Atlanta who stole 55 laptops. Company policy requires laptops to be encrypted, but they weren’t.

The Montana Department of Public Health and Human Services
A server holding names, addresses, dates of birth, and Social Security numbers of approximately 1.3 million people was hacked.

Spec’s - wine retailer in Texas
Affecting as many as 550,000 customers across 34 stores, hackers got away with customer names, debit/credit card details (including expiration dates and security codes), account information from paper checks, and even driver’s license numbers.

St. Joseph Health System
Also in Texas, a server was attacked that held approximately 405,000 former and current patients, employees, and beneficiaries information.  This data included names, Social Security numbers, dates of birth, medical information, addresses, and some bank account information.

The US Department of Health and Human Services has a breach database of incidents related to exposure of personal health information.  Due to late entries, dates weren’t listed, but the following were reported:

• 25,513 records at Dept. of Medical Assistance Services in Virginia
• 22,511 records at Cook County Health & Hospital System
• 18,000 records at Terrell County Health Dept. in Georgia
• 10,000 records at Health Advantage in Arkansas
• 84,000 records at St. Francis Patient Care Services in Tulsa, OK
• 10,024 records at Missouri Consolidated Health care

A new study from researchers at Gartner indicates that it is markedly less expensive for companies to invest in new security and encryption technologies than it is for them to respond to a data breach. According to the analyst firm, businesses pay roughly $6 per year per user for encryption tools, or $16 per user per year for intrusion prevention software licenses, versus paying out an average of $90 per user to address problems after a breach has occurred.

Five steps you can take to make sure this doesn’t happen to you:

1. Have a defense-in-depth strategy that meets your level of risk tolerance
2. Make sure you know where all of your sensitive data is stored, and who has access to it
3. Use standardized encryption algorithms to make that data unreadable
4. Use an encryption key management solution to protect keys away from the data
5. Use two-factor authentication whenever possible, because passwords are no longer enough

To help open up the conversation around your conference table, download this eBook “Turning a Blind Eye to Data Security” and find out more about the tools & resources to begin discussions about data security in your company!

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

	DES	AES
Developed	1977	2000
Key Length	56 bits	128, 192, or 256 bits
Cipher Type	Symmetric block cipher	Symmetric block cipher
Block Size	64 bits	128 bits
Security	Proven inadequate	Considered secure

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

Encryption and Key Management Can Provide Data Security in the Cloud

Data security is frequently brought up as one of the biggest concerns of moving to the cloud. According to a recent American Institute of CPA’s survey, weighing in at over 63%, the top barrier to adopting or expanding cloud solutions are security concerns. Whether you are looking for a cloud database solution, or moving other sensitive business data to the cloud, choosing your cloud provider will be a critical decision. After all, not all cloud security providers or cloud security solutions are created equal.

If you’re thinking of moving some or all of your sensitive data to the cloud, we’ve compiled a handy list of questions to help you select the right security solutions for your business. Remember every provider is different, so what might be right for one company might not be the best solution for another. It can seem like a daunting process, but as long as you do your research then you’ll be on the right track!

1. If I have my sensitive data stored in the cloud, am I responsible if my cloud provider has a data breach?
   The short answer is yes you are.
   When you have sensitive data and are moving it into a cloud environment you are still ultimately responsible for protecting that data. This can be confusing because cloud vendors make a lot of statements about encryption and compliance, however you are responsible for your overall data protection strategy. Data security is a shared responsibility in the sense that it is the cloud providers network, datacenter, and hardware and you bring the applications, operating system, and data. You are fully responsible for that data. You are also responsible for making sure the cloud provider can back up their security claims by requiring to see specific written compliance reports such as a SOC 3 audit statement, annual security assessment, and a letter of attestation by a QSA auditor.
   

2. Which compliance regulations apply to my business?
   In addition to the 4 listed below, there are also many state laws and regulations that govern security best practices. It is your responsibility to know which ones apply to your company (and which ones apply to your cloud provider location).
   PCI Data Security Standard (PCI DSS) applies to anyone, public or private, who take credit cards for payment. Primary account numbers (PAN) are specifically addressed.
   HIPAA/HITECH Act requires the medical segment (and any business associate) provide data protection for protected health information (PHI) of patients.
   GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency) for protecting all sensitive consumer information.
   Sarbanes-Oxley (SOX) applies to public traded companies for sensitive data of personally identifiable information (PII).
   In addition to these compliance regulations, the Cloud Security Alliance (CSA) has created the Cloud Controls Matrix (CCM) specifically designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider.
   

3. What type of data will be stored in the cloud, and does it need to be encrypted?
   If you are storing any sensitive data (PAN, PII, or PHI) that information must be protected and will need to be encrypted both at-rest and in-transit. Sometimes your whole database must be encrypted, other times you can select to encrypt at the column level. Make sure options are available to cover all your critical information.
   

4. Who will have access to the encrypted data? Will my cloud service provider or other cloud tenants be able to access to my information?
   Only you should have access to your encrypted data and the encryption keys that protect it. In a multi-tenant environment like the cloud, it is even more important to control access. Depending on the value of the data that you store, and your risk tolerance, you may opt to use a virtual private cloud vs. a multi-tenancy cloud environment to store your most sensitive information.
   

5. Where should I store and manage my encryption keys?
   Always use an external Key Manager solution to create, store, manage, and properly rotate your encryption keys. Storing encryption keys in the same database as the encrypted data has always been something to avoid!  Moving your data to the cloud still allows you to choose where you store your encryption keys. Hardware Security Module (HSM), Cloud HSM, virtual appliance (VMware), private cloud instance… just as long as they are stored and managed away from the data they protect!
   

6. How much control do I retain over my encryption keys?
   With using an external encryption key management solution, you should retain complete control over your encryption keys.
   
   

   These next few questions are encryption & key management solution specific. So if you are comparing solutions be sure to ask each vendor!
   

7. Do Townsend Security solutions protect data at-rest or in-transit? What type of encryption is used?
   Yes.  We use industry standard AES Encryption to protect data-at-rest.  We also use 128-bit SSL encryption to protect data-in-transit.
   

8. Can Townsend Security solutions grow to meet my business needs? How scalable are the solutions, is there a limit to how many applications I can (connect)?
   Yes. We believe you should get a flexible solution that will be able to scale up as your business grows, and not have a limit on how many application connect to it!
   

9. Are Townsend Security solutions validated by the National Institute of Standards and Technology (NIST)?
   Yes. Our solutions are NIST validated and also FIPS 140-2 compliant.
   

10. Does Townsend Security Have a “Test Drive” Offering?
    Yes. We always offer a complimentary 30 day evaluation of all of our solutions. Providing a free trial allows you to fully test the concept first, which can help allay fears and and answer any questions before making a commitment. With cloud deployments, you may still need to pay for their implementation services associated with the evaluation period, but in the new world of cloud computing, it is important to look for proof points and results before you make your investment.

Data stored in the cloud can be as secure or accessible as you make it. It is up to each and every cloud user to assess their business risk and uphold an expected standard of security.

It is ultimately your responsibility to make sure your data security plan meets compliance regulations. Make sure you have a strong defense in depth strategy in place and are using industry standard encryption and proper key management to protect your data wherever it resides. Learn more by downloading our Resource Kit on Key Management in the Cloud:

I just listened to a discussion of database security hosted by Oracle that was very well done. At one point the discussion turned to current threats and how the Enterprise has lost the ability to use perimeter protection for sensitive data. This has been a topic of much discussion in the security area for the last few months. Perimeter protection is based on the use of Firewall and similar technologies to keep the bad guys out, but this approach is failing with the advance of more sophisticated attacks, the use of social media by large organizations, the advance of mobile technologies, insider threats, and the migration of applications to cloud platforms. The trend is called “de-perimeterization” and represents a bit of a challenge to organizations that need to protect sensitive data.

Vipin Samir and Nishant Kaushik did a great job of describing the how the process of de-perimeterization has forced companies to fall back on user access controls to protect data. But user access controls are notoriously weak.  Weak passwords and sophisticated password cracking routines make it almost impossible to properly secure a database. So what is a security administrator to do?

Here are the suggestions from the panel that are a part of a defense-in-depth strategy:

Use Encryption to Protect Data:
Companies should use encryption at the database level or column level to protect data. This will secure data at rest on backup tapes and on disk in the event a drive is replaced. Encryption is an important part of the data protection strategy, but it needs to be combined with other techniques.

Use Good Key Management:
Protecting encryption keys is the most important part of the encryption strategy. Good key management techniques are needed, and the keys must be separated from the data they protect. Without this separation from protected data it is impossible to implement separation of duties and dual control – important parts of the key management strategy. See our Alliance Key Manager solution for more information about securing encryption keys.

Separation of Duties:
Because the threat from insiders is rising, it is important that the management of encryption keys be separate from the management of databases. Database administrators responsible for our relational databases should not have access to encryption key management, and security administrators should not manage databases. This is a core principal in data security regulations such as PCI DSS, but is often overlooked.

Context Sensitive Controls and Monitoring:
The last important step is to be sure that data access controls are sensitive to the data and its context. Bill in shipping has access to the order database, but should he really be decrypting the credit card number? Does your encryption solution detect and block this type of event? How will you monitor this security event? Or, Sally is authorized to view HR data from the accounting application, but should she really be using FTP to transfer this data? Normal encryption functions would not provide adequate protection from these types of data access. Context sensitive controls are needed to augment encryption.

When we started planning for automatic encryption in our Alliance AES/400 product two years ago, we took care to implement context sensitive controls right in the decryption APIs. That is now available in V7R1 of the IBM i operating system. We avoided the error of basing these controls on user account authorities and native OS security. Just because the operating system says you have read access rights to a database table, doesn’t mean you should be decrypting the social security number or using FTP to transfer the file. I’m happy with our implementation that is based on explicit authorization by a security administrator, and application white lists.

You can get more information and request an evaluation version of our Alliance AES/400 solution here.

You can find the Oracle presentation here. Look for “How secure is your Enterprise Application Data?”

Patrick