Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Paul Taylor

Recent Posts

Data Breach Risk Management with AES Encryption

Posted by Paul Taylor on Jun 6, 2012 12:25:00 PM

data breachIt is common knowledge in the IT world that the threat of a data breach is now greater than any other time in the history of technology. Since late 2007, the amount of personal information that has been exposed through data breaches is alarming. According to the Identity Theft Resource Center, over 30 million Americans have been victims of data breaches. This is not withstanding the fact that these statistics only count breaches that have been reported.

However, this problem is not unique to the United States. No business organization is immune to risk no matter its size and regardless of the industry or location. Governments all over the world have instituted laws and regulations aimed at protecting the privacy of its citizens. Businesses have now realized the importance of keeping their sensitive data (PCI DSS, HIPAA, SOX, FFIEC) safe and secure. They have come to realize that protecting their sensitive and critical data protects not only their reputation and profitability, but also aids business objectives. Storing and moving unencrypted sensitive data means taking risks that may result in brand damage, loss of customers, heavy litigation expenses, and possibly millions of dollars in fines. These are some of the dilemmas that an organization would not want to find itself needing to mitigate.

Encryption and key management are a critical part of the solution.

Data encryption is now the primary control helping organizations meet security standards and comply with regulatory guidelines such as the PCI DSS, HIPAA, SOX, and GLBA/FFIEC.

What factors and threats drive companies to use encryption key management to mitigate their risk of a data breach?

  • An increase in the amount of sensitive data being stored
  • Risk of data loss by employees mishandling data
  • Increased sharing of authorized data with external users
  • Emerging markets for stolen data
  • Stringent regulatory requirements

Current NIST standards have rendered old security technologies ineffective in dealing with IT security risks. Effective encryption key management protects your customers data from potential threat. Encryption will help:

  • Protect your data and sensitive information regardless of the location
  • Meet compliance and regulatory requirements and therefore pass your audits
  • Protect your business, avoid brand damage and  increase profitability

If your business wishes to protect its information from all the above risks, data encryption is necessary to achieve your data security goals and objectives.

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.

Click me

Topics: Encryption Key Management, Data Breach

Encryption Key Management - Key Attributes

Posted by Paul Taylor on Jun 1, 2012 10:20:00 AM
encryption keys

I am often asked about what policy and features can be assigned to an AES encryption key that is created by Alliance Key Manager, our encryption key management HSM.  Simply put there are various options available at key level for each symmetric encryption key you create. This helps you line up with PCI-DSS, HIPAA/HITECH and other compliance regulations, as well as providing a well rounded security strategy for proper encryption key management.  I wanted to give you a little bit of flavor of what some of these key options are so you can get a sense of the flexibility when it comes to key creation.

To get started, when creating a symmetric key, you assign it a user friendly name.  This can be something as simple as ENCKEY_HR.  This makes it easily identifiable from a management standpoint for what it's used for and for what group will be using it.  And since these are AES keys we are creating, you'll be asked to specify what key size you wish to utilize for each individual key.  Your options are 128 bit, 192 bit, and 256 bit keys.  I normally recommend the 256-bit size as it is the strongest options available, but in all honesty, any size is adequately strong against any brute force attack it might come up against by a crafty hacker trying to decrypt your data  

When creating keys, you’re allowed to set activation and expiration dates.  This allows you to pre-create keys and to define a schedule as to when a key can be made available for use.  You may want to have a policy where keys expires every few years and you revoke their use from users.  If you're familiar with PCI requirements you'll know that you have to establish a crypto-period for your active encryption keys.  When creating an encryption key you can specify how many days that key will be made available before it automatically rolls over into a new version of that key.  The friendly key name you assigned to it at conception will never change, but behind the scenes you'll have a completely new instance of that key for use.  Additionally, in an event where you suspect a data breach or need to roll a key manually, these options are available for you as well.

To provide an additional layer of security to who can have access to encryption keys, we provide a Key Access table that lets you lock down who or what groups can have access to which keys. There are varying levels of granularity that are made available for you in this area. For example, from a very unrestricted sense where anyone in your organization with an authorized TLS session to the server can request a key, all the way to the very strict policy where only specified users within specified groups can requests certain keys. These credentials are all set at the key level and are defined on the key requestor side within the distinguished name of the digital certificate they are using to connect to the key server and establish a secure link for key retrieval.

Additionally, keys have mirroring attributes that can be set at the key level to ensure you don't experience a business interruption by always having access to keys in the event of a network outage.  I've seen customers never miss a beat when that unexpected outages occurs due to the fact that they have a hot failover standing by and ready to go.  Also, to help add a level of detail to the keys you'll be creating, we provide sixteen different metadata fields for you specify details unique for each individual key.  These fields enable you to easily track important details relevant to the key throughout its lifecycle.

Managing encryption keys with a Hardware Security Module (HSM) is the best way to ensure encrypted data remains secure. Learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.

Click me

Topics: Alliance Key Manager, Encryption Key Management

SQL Server Compliance: Top 5 Things You Can Do to Pass an Audit

Posted by Paul Taylor on May 30, 2012 1:50:00 PM

SQL encryption key managementIt is important for businesses of all sizes running on SQL servers to encrypt any sensitive data that they store or move. Although business size can determine specific compliance requirements that need to be met, all companies handling sensitive data are vulnerable to the major risk of failing a security audit if their data isn’t properly secured on their SQL servers.

Here are the 5 steps you can take to ensure you pass your next audit:

1. Test applications to address vulnerabilities

Continually test and re-test your applications including payment applications and firewalls  to look for vulnerabilities and address them from the start.

2. Protect information transmission

Protect data in motion by offering secure authentication features, logging application activity, using secure payment applications, and protecting wireless transmissions.

3. Protect your data

Ensure stored cardholder or PII/PHI data is protected with encryption; this information should never be stored on a server that is connected to the internet.

4. Encrypt sensitive traffic over public networks

Any transfer of data over public networks should be encrypted, whether this is cardholder information or PII/PHI data. Encrypting sensitive information guarantees that if it is intercepted that it is unusable without the encryption key.

5. Separate the encryption key from encrypted data

Separating the encryption keys from the data ensures the safety of the data in the event of an outside breach. It also allows internal separation of duties, thereby preventing unauthorized access to the the SQL Server data. This is a best practice for encryption management when dealing with sensitive information.

Taking theses steps in order to pass a security audit will proactively prevent data breaches. Even if data becomes compromised, properly encrypted data will guarantee that the data can not be used or accessed.  With a comprehensive data security plan, your company can easily meet state and national compliance regulations. Using proper encryption and key management on SQL Server will make encrypting your data quick and painless, and will help ensure you pass your next audit.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.

Click me

Topics: Compliance, Encryption Key Management, SQL Server

HIPAA Security: Healthcare Data Breaches on the Rise

Posted by Paul Taylor on May 29, 2012 9:32:00 AM

HIPAA SecurityIn a highly digitized environment, identity theft poses a great risk if the necessary safeguards are not utilized. It is paramount that businesses and consumers are made aware of the massive repercussions a data breach of patient info can result in--such as identity theft of patients, as well as financial damage to and reputation loss of healthcare organizations. Current HIPAA regulations mandate that if a data breach occurs, then the organization responsible for that breach must reported it to Health and Human Services (HHS), pay thousands or millions of dollars in fines, and may have to report the breach to the media.  However, if your organization’s data is securely encrypted, you will be exempt from these repercussions.

Despite Health Insurance Portability and Accountability Act (HIPAA) security laws, healthcare data breaches are on the rise. According to the Ponemon Institute, the healthcare industry has lost more than $6.5 billion dollars due to data breaches.

Ponemon also identifies the three most common culprits of healthcare data breaches: stolen or lost equipment, third-party mistakes, and employee errors, indicating that many data breaches stem from unintentional mistakes. Storing health information on mobile devices is also a common practice among health care organizations. However, 49% of the respondents reportedly do not take any steps to secure patients' information on those devices.

medicaid breachA great example of an accidental data breach recently took place in South Carolina where a Medicaid employee transferred several spreadsheets of sensitive patient data to a personal email account. This kind of data breach could have exposed hundreds of thousands of patients to possible theft of Social Security numbers, Medicaid ID numbers, addresses, phone numbers, and birthdates.

Another alarming example took place at an Emory Healthcare storage facility where 10 back-up disks for an old computer were found missing. These disks contained protected health information (PHI) of more than 300,000 patients including patients' names, doctors' names, diagnoses, medical procedures and other privileged information protected under HIPAA.

As healthcare organizations face greater challenges in protecting massive amounts of patient data, the US federal government continues to strengthen security laws, regulations, and best practices. Due to the HITECH act of 2009, HIPAA compliances now requires more stringent steps to ensure full security of patient information.

As the CTO, IT Manger or System Administrator of your healthcare company, you have a critical task to accomplish. You cannot afford to waste time and money on legal battles that you can avoid in the first place. If you do experience a data breach, the emotional toll on your patients could result in lost clients and a tarnished company image.

Here is the good news: NIST-certified encryption and FIPS 140-2 certified encryption key management is at your fingertips!  Townsend Security’s encryption solutions offer affordable possibilities that will fully protect your patients' records and allow you to avoid a breach notification in accordance with HIPAA/HITECH. You need a security technology with a strong encryption solution that is NIST certified and suitable to your server environment. If data is securely encrypted, data breaches don’t need to be reported and you and your patients are assured peace of mind.

For more information, download our podcast "Protect PHI and Manage Risk - HIPAA Compliance" and learn more about achieving Safe-Harbor status in the event of a breach and what is considered a data breach.  Additionally, learn what to be aware of when selecting an encryption or key management solution.

Click me

Topics: HIPAA, Healthcare, Data Breach

Transparent Data Encryption on SQL Server 2008/2012 – Where are Your Keys?

Posted by Paul Taylor on May 25, 2012 8:51:00 AM

ekm encryption keysAny way you look at it, 2011 was a very bad year for database security. From the high-profile (and highly embarrassing) series of attacks on Sony's PlayStation Network, to the less-publicized Epsilon breach which was described by the Privacy Clearinghouse as the worst data breach in history, there was a huge upswing in attacks targeting private user data. In fact, according to a recent Verizon PCI Compliance Report (PCIR), "about 42 percent of organizations have trouble implementing a proper encryption key management strategy to keep information safe."

In short, hacking has become a goldmine for criminals looking to steal and exploit personal information, and you need to be doing everything you can to avoid being their next victim. For database administrators, this means making sure your encryption keys are as secure as possible.

Key Management in SQL Server 2008/2012

In previous years, encryption security was difficult because the keys were almost always stored locally on the same computer as the data. However, with the SQL Server 2008/2012 Enterprise Edition encryption key management became much more robust thanks to the introduction of Extensible Key Management (EKM).

EKM works alongside the Microsoft Cryptographic API to create a system where SQL server key management is significantly more secure. They can now easily be stored in an external Hardware Security Modules (HSM) that store the encryption keys securely, away from the data they protect. This makes it far more difficult for hackers to gain access to your secure private information.

The Advantages of a Hardware Security Module (HSM)

Alliance Key Manager, Townsend Security's encryption key management HSM provides a number of significant benefits for secure encryption key management.

  • Direct Integration With SQL 2008/2012: SQL Server 2008/2012 natively supports HSMs, requiring only a small tweak to the configuration files to enable their usage and disable local key storage.
  • True Key Security: With TDE, the key to your encryption never actually leaves the HSM. It cannot be captured through packet-sniffing or at the end user's machine.
  • Robust Standards Compliance: A properly-configured HSM setup gives you robust compliance with most of the major public and private security standards, including PCI DSS, HIPAA, SOX, and the Gramm-Leach-Bliley Act.
  • End User Simplicity with TDE: EKM also allows for Transparent Data Encryption (TDE), meaning that it's invisible to the end user. Your employees can continue to use their applications as they normally did, with the Hardware Security Module being queried as necessary, behind the scenes.
  • Cell Level Encryption: Through EKM, each individual column of cells can be encrypted separately, making large-scale data breaches far more difficult to pull off.
  • Easy Implementation: Once the hardware is installed, the key management software only needs to be installed on your server machine. End user access to it is managed through software licenses rather than requiring time-consuming individual installations.

A Smart Choice for Server Security

While encryption and key management are not the only elements necessary for robust data security, they are a major component of it. By implementing a HSM, your business can quickly and easily give its security a shot in the arm, telling your customers and investors that you're serious about protecting private personal information on your servers.

Don't let 2011 be a sign of things to come; take steps now to make 2012 the year of data protection.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.

Click me

Topics: SQL Server 2008, Encryption Key Management

Advantages of Third-Party IBM i (AS400) Encryption

Posted by Paul Taylor on May 18, 2012 1:46:00 PM

automatic encryptionThe newest version of the IBM i (AS400) operating system, V7R1, brings sophisticated new security tools from IBM’s larger systems to mid-range markets. These new features allow third-party companies such as Townsend Security to offer NIST-certified automatic AES encryption, so that you can now encrypt your sensitive data without application changes!

With the update from V5R4 or V6R1 to V7R1, the AS400 can now protect data more efficiently by using FIELDPROC, an “exit point” technology that works in the database instead of in application programs. Previously, IBM i (AS400) encryption was an application-level process where a user had to first identify the field such as credit card numbers, social security numbers, or other private information and then decide on an approach that usually involved modifying applications. This required programmers to make changes and undergo a sophisticated test cycle.

The new FIELDPROC exit point allows a user to identify all fields they wish to encrypt with Townsend Security’s automatic AES encryption without making application changes.

It is crucial to keep in mind that administrators can use strong encryption in a weak manner by neglecting the use of proper encryption key management. In using a third-party encryption  provider such as Townsend Security, a company with more than 20 years of IBM i (AS400) experience has three distinct advantages:

  1. AES encryption is automatic, meaning that no changes in applications need to be made. This saves your company time and money by focusing on your business instead of a complicated encryption project.
  2. NIST-certified encryption will pass all state, federal, and industry compliance regulations. Townsend Security guarantees our NIST certified Alliance AES/400 solution will meet or exceed encryption standards in PCI, SOX, HIPAA/HITECH and other regulations.
  3. Third-party encryption can be faster. Alliance AES/400 from Townsend Security can encrypt one million credit card numbers in one second of CPU time--100 times faster than competing encryption libraries on the same IBM i platform.

Because encryption has a reputation for creating performance problems, the newly specialized FIELDPROC tool optimizes encryption and sets up secure caches. Townsend Security’s Automatic AES Encryption integrates seamlessly with these features to create the most secure data environment available on the IBM i (AS400) today.

Download our podcast on "The Benefits of FIELDPROC Encryption" to learn more about FIELDPROC capabilities and the benefits of automatic encryption.  Additionally, we have a podcast titled "FIELDPROC Performance - Speed Matters" for those who are wondering how it will impact their systems.

Click me

Topics: Encryption, AES, FIELDPROC

Data Breaches Drive Encryption Projects in 2012

Posted by Paul Taylor on May 16, 2012 1:45:00 PM
data breach 2012

In today's interconnected world, your company's reputation can be won or lost on the strength of your data security. Almost every day, you can read news reports about data breaches that expose confidential customer information. Credit card numbers, banking information, even home addresses and telephone numbers have been exposed by unscrupulous hackers and inattentive employees. Social network and online news outlets quickly spread the word of any potential breaches, exposing your company to public scrutiny and ridicule. Data breaches also expose your business to legal liability and sanctions. Once the data is out, there is no putting the cat back into the bag. You will be forced to explain what precautions you've taken, and why they didn't work. If you fail to meet any federal, state, or industry standards for data security, you could find yourself in a very precarious position.

Data breaches come about in a variety of ways. Many highly publicized exposures are the result of direct efforts by hackers. These hackers can have a variety of motivations, from purely financial to personal ideology, but the end result for your company is the same. If they get in, and get useful information, your bottom line and reputation can suffer irreparable harm.

Another infamous, but no less harmful, form of data loss can be caused by employee negligence. Lost laptops, misplaced flash drives, and low-quality passwords can all lead to data loss. A common thief who steals a notebook computer from a car may find himself in possession of your most sensitive data. Even though these exposures can't be directly attributed to any failure on your part, your business will still be responsible for a breach notification.

To adequately protect your data from all conceivable threats, you need to be protecting it with encryption and key management, which goes farther than just access prevention. A dedicated hacker or inattentive employee can circumvent the most secure firewall and bypass the most stringent security protocols. The only way to make sure your data is truly secure is to make sure that, no matter where it's located, it's useless to unauthorized personnel.

It's almost impossible to ensure that your sensitive data remains where you put it. Whether intentional or accidental, there is always the possibility that sensitive data will be removed from your site. The best defense against harmful data breaches is a comprehensive security protocol that utilizes data. When your data is properly encrypted, compliance regulations state that you aren’t responsible for a breach notification – because there is no useable data!

Townsend Security provides NIST-certified AES encryption for all major enterprise platforms and a FIPS 140-2 certified encryption key management hardware security module (HSM) – technology that will help you avoid a breach notification. There is no better way to securely store data and minimize your exposure. 

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.

Click me

Topics: security, Data Privacy

Meeting Section 10 of PCI with System Logging on IBM i (AS/400)

Posted by Paul Taylor on May 11, 2012 8:33:00 AM

IBM i Logging PCISection 10 of PCI DSS requirements v2.0 states the need to track user activities, to be able to detect, prevent or minimize the impact of a data compromise.  Because of the mere fact that most every application under the sun produces a log entry for when something goes amiss, you can also use that same log file as a security tool.  It can provide a means of tracking and analysis when a possible data breach may be occurring as well as add crucial detail for investigative purposes.  Now a smart criminal knows to cover their tracks at the scene of a crime, and they can do this simply by wiping out any log data that may exist.  However if you’re capturing these logs in real time and sending them to a third party server, even the most savvy of crooks will be caught red handed.

Our Alliance LogAgent solution helps accomplish that, as well as satisfying parts of section 10 of PCI DSS by being able to capture logs from your IBM i’s audit journal, formatting them and sending them off to a waiting log collection server.  We monitor for log entries out of numerous places on the iSeries allowing the user the a level of granularity to choose what log messages to capture and kick over the wall to the waiting log server.  It's always a good idea to work hand-in-hand with your PCI auditor to make sure you're collecting all the appropriate events on your system to meet their requirements.

For instance, you'll want to make sure you're collecting AF (Authority Failure Events) events which come from the System Value QAUDLVL.  This particular event is triggered by all access failures, such as sign-ons authorization, and job submissions. It also includes incorrect password and user ID attempts from a device.  These details can play a crucial role in tracking down details around a possible breach into your system.  

As I mentioned, Alliance LogAgent sends these events to a listening collection server or SIEM solution.  We work with any SIEM product that is actively listening and waiting for logs to arrive and can accept messages in the RFC 3164 or Common Event format.  There are a number of SIEM products available on the market and they help parse the influx of log messages as they arrive, as well as send out notification and alert emails when something suspicious is detected.

Currently, the PCI guidelines don't include transmitting logs over a secure SSL/TLS session (it’s a very, very good idea).  However, looking ahead to when this becomes a requirement, you can rest assure that you’re already running software that can meet those needs.  LogAgent is already setup to handle secure SSL/TLS transmissions and is one of the reasons it stands apart from the competition.  The only change you'll have to make in the configuration of the product when switching over from UDP/TCP to SSL will be to provide an SSL application ID.  This is an ID that is associated with a digital certificate that you can create with IBM's Digital Certificate Manager (DCM).   Having this secure session in place will ensure that your log message data won't be intercepted on its journey to the collection server.

Download a free 30-day evaluation of Alliance LogAgent Suite and meet Section 10 of PCI DSS.  In under an hour, you can start collecting all system logs on your IBM i (AS/400) and converting them to syslog or CEF format for any SIEM or log collection server.

Click me

Topics: System Logging, PCI DSS, Alliance LogAgent

System Logging: Log Messages Format for your SIEM - RFC 3164 or CEF?

Posted by Paul Taylor on May 7, 2012 8:29:00 AM

system loggingThe Alliance LogAgent Solution for system logging on the IBM iSeries is able to grab log messages out of a variety of places such as your system's audit journal, (QAUDJRN), your history log (QHST), and system operator messages (QSYSOPR) and format them to either a standardized Syslog format, in this case RFC3164 or Common Event Format (CEF). Once formatted, we pass the messages over to the communications module that handles the transmission of the messages to your waiting log collection server using either the UDP, TCP or SSL/TLS protocol.  

LogAgent can send to any collection server that is listening for messages.  You simply assign either a remote host or IP address of the waiting server as well as the port number.  Ideally you would want a SIEM (like from LogRhythm, Solutionary, or SolarWinds, for example) running on that server to read the messages that are received, sort them and send out alarms to your security team when dubious messages arrive.

IBM i Security: Event Logging & Active MonitoringMore often than not you'll want to use the Syslog format as it is generally accepted.  The RFC3164 format that we use is composed of three parts.  The first part is called the PRI, the second part is the HEADER, and the third part is the MSG.  

The PRI part is the Priority value and begins the log message.  Its value is contained within angled brackets and is either two or three digits in length.  It is comprised of the Facility value and the Severity level of the message.  The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity.  (Example: <40> )

The second part of the message is the header which will contain a timestamp, and an indication of the hostname or IP address of the device it originated from.  The MSG part will fill out the remainder of the syslog packet and contain the generated message and the text of the message.  

Here is a quick sample of a log message in RFC 3164 format.

<118> Apr 18 16:32:58 QAUDJRN: [AF@0 event="AF-Authority failure" violation="A-Not authorized to object" actual_type="AF-A" jrn_seq="1001363" timestamp="20120418163258988000" job_name="QPADEV000B" user_name="TESTFORAF" job_number="256937" err_user="TESTFORAF" ip_addr="" port="55875" action="Undefined(x00)" val_job="QPADEV000B" val_user="TESTFORAF" val_jobno="256937" object="AFTEST" object_library="CUS9242" object_type="*FILE" pgm_name="" pgm_libr="" workstation=""]

If you're using a SIEM such as ArcSight who is expecting logs messages in the Common Event Format (CEF) you can easily switch the formatting from the configuration menu of LogAgent to send in this manner.  Much like the RFC 3164 version, the message contains a timestamp and hostname or IP address at the beginning.  This is followed by the Extension part of the message and is really a placeholder for additional fields.  Some common fields you'll find are CEF version, Device Vendor, Device Product Severity and Signature ID just to name a few.   

Example of what a CEF formatted log message looks like.

Feb 29 15:47:25 CEF: 0|PATownsend|IBM-QAUDJRN|1.28|1007|CO-Create object|4|msg=CO-Create object act=N-Create of new object actual_type=CO-N jrn_seq=102361 timestamp=20120229154725823000 dproc=ICC suser=MVAGANEK job_number=638012 eff_user=MVAGANEK object=X_BIGNUM object_library=ICAPITST object_type=*MODULE object_attrCLE

It's always a good idea to check with the team managing your log collection server to see what format they are expecting log messages to arrive in. Hopefully having a clearer understanding of what your choices are will help make the task of deploying system logging on your AS/400 smoother and easier to satisfy section 10 of PCI DSS compliance.  If you haven't yet, download a free 30-day evaluation of our Alliance LogAgent for IBM i system logging software.  Our customers have deployed the solution in under an hour from the time they download the evaluation from our website!



Topics: System Logging, IBM i, Alliance LogAgent

How Emory Healthcare Could Have Avoided A Data Breach Notification

Posted by Paul Taylor on Apr 23, 2012 10:17:00 AM

Breach Notification Safe-Harbor

PCI Compliance White Paper

Download the white paper "Achieve Safe-Harbor Status from HITECH Act Breach Notification" to learn more about encyption and key management best practices.

Click Here to Download Now

Data breaches in the medical industry are occurring at a greater rate now than ever before. Emory Healthcare recently experienced a significant PHI (Private Health Information) breach and has announced that approximately 315,000 medical records have gone missing.

Included among those records are those of the chief executive officer of the hospital, who has tried to calm public outcry by noting that, to his knowledge, none of the personal information had been used in attempts at identity theft. But the loss is significant because it violates patient privacy rights and could have been prevented if Emory Healthcare was properly encrypting the data.

In total, 10 backup discs for the hospital system have been gone from their storage facilities since mid-February. Within each record was a wealth of information, including patient names, Social Security numbers, and surgical procedures and dates.

Emory has said that it had strong policies in place to protect the personal information of patients. It also attributed the cause of the theft to an honest mistake made by an employee.  However, HIPAA states that an organization is responsible for a breach notification regardless of whether the data was “hacked” or just lost.

As part of their remediation plan, Emory is providing free resources to help patients combat and prevent identity theft. While Emory has said it is revisiting its policies and procedures to better protect patient information, it's unclear if they are making systemic changes that could protect patients even if data is stolen in the future. Regardless of what security measures they take to better protect patient information, the only way Emory -- or any other medical facility -- can guarantee patient information is safe and avoid a breach notification will be to protect it with encryption and key management.

If you are not familiar, AES encryption (the standard for Data at Rest) is a form of data protection that uses an algorithm to transform information in a way that makes it unreadable by other entities. AES encryption that is certified by the National Institute of Standards and Technology (NIST) is used to attain the highest levels of security. Encryption can't be ignored as a security measure.

The second part of the encryption process is managing the encryption key. Only by knowing the encryption key can that information be unlocked and read. When data such as patient information is encrypted with proper key management, it is safe from being compromised by hackers or other entities that steal the information. Without the encryption key, the data is worthless.

With breaches in the healthcare industry up 32% in the last year, it is more important than ever to be encrypting PHI.  Data breaches have dollars lost directly tied to each record lost.  Download our white paper “Achieve Safe-Harbor Status from HIPAA/HITECH Breach Notification” to learn more about how your organization can protect PHI with encryption and key management.

Click me

Topics: Data Privacy, HIPAA, Security News

The Definitive Guide to AWS Encryption Key Management
Definitive Guide to VMware Encryption & Key Management


Subscribe to Email Updates

Recent Posts

Posts by Topic

see all