Townsend Security Data Privacy Blog

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

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

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

Podcast: Better System Logging Download the podcast "System Logging on the IBM i - How to Do It Better." Click Here to Download Now

Townsend Security’s latest version of Alliance LogAgent, Alliance LogAgent Suite, will allow IBM i log agent administrators to stay one step ahead of security compliance regulations. In a recent podcast, Patrick Townsend, Founder & CEO, discussed this enhancement:

Our major enhancement to Alliance LogAgent allows system logging administrators to extend visibility right down to the field and column level, record-by-record, in their databases. With the new features you’ll have the ability to monitor any particular file in order to recognize exactly which fields were viewed or changed by a particular user. The ability to do this is a soon-to-be critical area of compliance. Customers will need to be able to do forensics on access to particular fields in particular records.

European companies have some additional log management compliance regulations that we don’t yet experience in the United States, but these regulations are coming towards us. Advanced system logging on the IBM i is becoming more important than ever. With Alliance LogAgent Suite we give you the option to log the before and after versions of a particular field so you can see if there was a change made and what it was. If the field contains sensitive data, we can also log a secure hashed value of that field in order to keep the field completely secure.

Alliance LogAgent Suite will also let you create white lists of inclusion (people who should be able to see values in the database) and exclusion (who should not be able to see them). We can then log those unauthorized accesses, so that log management administrators don’t need to depend on native object authority on the IBM i. Instead you’ll see record-by-record, column-by-column level access and who has seen data they should or shouldn’t have seen.

We’ll also let you select floor and ceiling values, so that when a value goes over or under a certain amount, Alliance LogAgent Suite will alert you and record the event in a log. For example, a systems administrator at a bank could establish a wire transfer ceiling of $10,000 so that if an employee tried to wire $1 million to Aruba, LogAgent Suite would detect this report this large transfer attempt immediately.

These new features in Alliance LogAgent Suite will substantially improve the security posture of a company using system logging the IBM i. The implementation of LogAgent suite is easier than ever and will help to prepare IBM i users for the evolution of new compliance regulations.

Download a free 30-day evaluation of Alliance LogAgent Suite to start meeting compliance regulations (PCI DSS, HIPAA, etc.).  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.

The United States Department of Health and Human Services (HHS) is cracking down on HIPAA violators. Now, more than ever, there is just about zero mercy shed on any practice, large or small, if they are discovered to have made an error in patient confidentiality. On April 17, the HHS made an example out of a physician’s office in Phoenix, Arizona. The practice has only five doctors, but despite being what some may call a small business, they must pay the hefty fine of $100,000 for violating HIPAA privacy and security rules. While this sanction may seem unreasonable for such a small practice, it is simply demonstrating the zero tolerance policy that HHS has regarding HIPAA violations.

A complaint was filed against the practice retroactive to discovering an online calendar that the public had access to. On this calendar were patients’ appointment schedules and even a list of scheduled surgeries. After an HHS investigation took place, it was discovered that employees of the firm were grossly misinformed when it came to knowing the rules and regulations of HIPAA. A second red flag was shown when investigating the amount of effort the company put forth on their policy protecting patient information.

While these two violations are most alarming, there were many other conduct errors found including a failure to obtain a legal business associate agreement in reference to scheduling and email services, and there was no report of risk analysis. All of these violations resulted in the aforementioned six-figure fine.

The message sent here is clear: Follow the bylaws of HIPAA, or suffer major financial consequences. Leon Rodriguez, director of the HHS Office of Civil Rights was quoted in saying  “This case is significant because it highlights a multiyear, continuing failure on the part of this provider to comply with the requirements of the Privacy and Security Rules.” He went on to discuss his desire for companies to comply with the changing rules of HIPAA no matter the size or prominence of the practice.

It is imperative to educate yourself and your staff about the current HIPAA rules.  For more information on HIPAA compliance, view our webinar “Protect PHI & Manage Risk – HIPAA/HITECH Compliance” and learn more about managing your risk of a data breach, achieving breach notification safe-harbor status, and encryption and key management best practices.

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

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.

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

The security breach involving Global Payments, a US credit card processing company is still in complete disarray months after the breach took place. A little over a month ago, it was reported that a maximum of a staggering 10 million credit card numbers could have been apprehended during a five week period starting in late January. Global Payments reluctantly admitted to being the victims countering with a figure of 1.5 million credit card numbers stolen. While there isn’t any reason why any company should have this happen to them, it is a growing trend to claim a bit of ignorance on the matter, or at least try to redistribute the blame.

When these breaches happen, many business owners and executives are blindsided by the blow. Of course they have security software, and in most cases, if they have it, the word “breach” shouldn’t have any place inside the walls of these businesses. But, as we’ve seen, credit card numbers and other personal information that should be safe, sometimes isn’t. Having strong passwords is the first step an organization should be doing to keep unauthorized individuals from accessing sensitive information.

Make sure that any passwords that you choose to enter are not what as known as “default passwords.” It seems logical enough, but a default password is one of most common flaws in a security system that leads to a breach. Hackers have databases full of default passwords, and those can be typed in at a rapid pace. Some of these include the obvious “1-2-3-4-5” or “a-s-d-f.” Any sequence of characters that in some universe make sense in a logical order should be completely abandoned. Also, birthdays or dates that can be easily discovered should be the last passwords that are selected. It is far better to come up with something so outrageous, and take the extra time to completely type it out then to use simple passwords that are already on databases. Also, use different passwords for different accounts. That way, if one is discovered, the rest are still secure.

Your credit card company should be monitoring all activity on your accounts, so that if anything suspicious is going on, you will be notified about it instantly. You don’t want to be on this list of companies that have allowed breaches, so make sure to be smart about your passwords. If you ever had a tree house and the bully next door successfully guessed “peanut butter” as the password, you would have to, begrudgingly, let him in. But, he probably wouldn’t guess “138927491AsmaraEritrea53211” so taking the smart choice would pay off.

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.

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

More 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 10.0.1.11 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="10.0.1.23" 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 10.0.1.43 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!

 

IBM announced recently the end of support date for V5R4. This has prompted many IBM i shops running this older OS to upgrade to a newer release - either V6R1 or V7R1. Traditionally, we have seen that most IBM i administrators upgrade just one release forward. In this particular case, we recommend going to V7R1. Not only is upgrading to V7R1 a fully supported path by IBM, there are security reasons. I recently sat down with Patrick Townsend, Founder & CEO, to discuss IBM i V7R1 and how Townsend Security can help organizations take advantage of FIELDPROC, a new feature that allows companies to encrypt their sensitive data without changing their applications.

You said recently that upgrading your IBM i to V6R1 is a bad idea. Can you explain why?

Security today is more important than it was even two or three years ago. We live in an evolving world around security and organizations of every size - from small companies to global companies - really have been under severe attack. The bad guys are getting much better at what they do and we are faced with highly sophisticated attacks. Even mid-sized companies are now under pressure to protect their data. So we live in a world that is far more sensitive and insecure, and we really have to put more attention on protecting sensitive data.

IBM gave us FIELDPROC in the latest release of the operating system (V7R1), which allows encryption with no application changes. FIELDPROC is really attractive for mid-sized and large customers. It makes the usually very difficult task of encrypting data in our systems much easier. I think that customers who are on older versions of the operating system (V5R4, for example) and who might in the past have just moved up one level, should really move up to V7R1. From a security perspective, it is time to jump a level from V5R3 or V5R4, past V6R1, which would be the next release, to V7R1 and get the benefits of FIELDPROC encryption.

What would an organization need to do to take advantage of FIELDPROC once they upgrade? They still need third-party encryption, right?

Yes, FIELDPROC is the ability to do encryption, but IBM relies on third-party vendors like us to actually provide the encryption libraries and appropriate encryption key management. When customers deploy our FIELDPROC encryption solution on V7R1, they are getting our NIST-certified encryption libraries, as well as seamless integration with Alliance Key Manager, our encryption key manager. Alliance Key Manager is FIPS140-2 certified, and when used with our encryption, lines up perfectly with best practices for encryption across all compliance regulations. Whether it is PCI/DSS with Credit Cards, HIPAA/HITECH in the Healthcare industry, FFIEC in the financial industry, DICAP if you are a civilian company working with the federal government, or if you are a federal agency where it is a mandate that you must have a FIPS140-2 solution.

Our FIELDPROC solution installs into an IBM i customer’s environment, provides both our optimized and certified AES encryption libraries, and the key management you need to be compliant. IBM has done the hard work of making this capability available and we do the work of snapping in proper encryption and key management.

Download a free 30-day evaluation of our Alliance AES/400 encryption, built specifically for IBM i V7R1. Alliance AES/400 is the only NIST-certified FIELDPROC encryption available.