By Rebecca Herold, Posted 12/28/09
Final Draft for July 2009 CSI Alert
An important consideration with information security incidents is identifying if personally identifiable information (PII) is involved. If it is, then the privacy breach response team needs to be put into action to determine whether or not an actual privacy breach occurred. Answering the question, “Has a privacy breach actually occurred?” is not as easy of a task as it may seem by this simple question. The definitions of a privacy breach vary greatly within the at least 48 U.S. state and territory level breach notice laws, in addition to the federal laws which require privacy breach activities.
I love talking with practitioners about their information security incident and privacy breach response plans and practices. I’m always interested in hearing the challenges and unique situations they run across as they not only create their plans, but also for how they execute them. I often find that companies run across situations that they had not considered when they created the plans, but then have to deal with in real-life situations. These seemingly unique situations often turn out to be not so unique after all when they find many other companies are also addressing the same issues.
Here are three of these situations, often overlooked and not planned for, but experienced by organizations.
Electronic messages accidentally going to the wrong internal recipient
I’ve spoken with at least a couple dozen information security practitioners who have had the situation occur where someone on the internal corporate network has sent email messages containing PII accidentally to another person within the organization who was not already authorized to see the PII. In one of the situations an organization described to me, an employee in the accounting department meant to send an email with a question, including an abundance of PII such as SSNs and medical information, about a group of employees to the corporate lawyer, but accidentally sent it to an IT employee with a similar name. She realized the error when the IT employee called and asked if she really meant to send the email to a different employee. Embarrassed, she said yes, asked the recipient to delete the email immediately, and then, following the documented corporate breach response plans, she notified the information security department. So, is this a privacy breach?
It is a great question and good situation to discuss and debate. Certainly this is a recommended discussion between the information security, privacy and legal offices. For each organization to determine the best answer that applies, consider the following questions:
- What breach response laws apply to your organization?
- Do the laws specifically address this issue? Do the definitions of a breach cover this situation?
- Did the errant recipient actually open the message? Do you have logs that can verify this?
- Have you interviewed the person who received the message to see if he or she read it?
- Based upon your discussion, and any other issues related to the individual’s work history, do you have any reason to believe the recipient would do something bad with the information?
Passwords built into applications
Building in back door access capabilities and coding passwords into programs are security-poor practices probably as old as programming itself, but as the incidents resulting from insiders continue to be increasingly revealed, the question surrounding the discovery of such situations becomes, are these considered as privacy breaches?
I’ve spoken with information security and privacy officers over the past year who are pondering this question. And for good reason, not only for the insider threat consideration, but also based upon how these backdoors and hard-coded passwords are used. In one case, the programmer updating an application hard coded passwords to get access to real customers’ accounts to test the application before putting it into production. A bad idea? Very. However, I bet a lot more programmers are putting this type of “testing” code into programs.
The situation became worse when the CISO discovered that the hard coded passwords were left in the code when it then was placed into production. Not just in one program, but this had been going on for an embarrassingly long time for multiple application programs. So, basically, all the programmers with access to the code also had access to the customers’ live accounts and associated information. Is this a privacy breach?
Certainly this situation calls for a discussion between the information security, privacy and legal offices and all the related impacts and consequences. Again, for each organization to determine the best answer that applies, consider the following questions:
- Are the passwords actual passwords for the customers? Or, were they passwords made to work, by the programmers, to access the customer accounts?
- To what resources do the hard coded IDs and passwords have access? Customer PII?
- Are the people who coded these backdoors and passwords still working at your organization?
- Do the programmers have access to the same resources to which the hard coded ID and passwords have access?
- How many programmers have access to the code?
- Are the programmers contracted and employees of another company?
Employees taking PII with them when leaving the organization
Now here’s a situation I know all organizations have had to deal with at one time or another. And with the widespread use of USB thumb drives and the ease of sending huge amounts of data out via email attachments, it is growing. Add to the mix the fact that growing numbers of personnel are mobile workers, and use the company’s laptops in their home offices, fully loaded with tons of PII, or even are using their own personally owned computers to do business work.
So, if you discover an ex-employee has taken PII with him or her, or the individual didn’t return a computer or storage device containing PII, or hard print papers with PII, is this a privacy breach? In the past year a CPO at another organization had an employee who had been approved to work from home on her own computer. She did payroll activities for the company, and over the course of a year or so had basically accumulated all the employee PII relating to compensation, including benefits that had Social Security numbers and insurance numbers, onto her computer. She apparently went through some personal hardships within her family, and unexpectedly called in one day and said she had to quit immediately to take care of family problems. When asked to allow someone to come to her home to remove the company information and software from her computer, including the employee PII, she refused, saying that she had already deleted all the data and software, and she was not going to let anyone look at her personal and home files, and she was simply too distraught to even think about the company any more.
So, is this a breach? There are definitely many issues involved with this situation, beyond a potential breach. And yes, this is yet another recommended discussion between the information security, privacy and legal offices. But let’s focus for now on the breach issues. You should consider the following:
- Specifically what were all the PII items that the individual had in her possession?
- Are there any logs or audit trails to show the activities of this individual to the employee files?
- What contracts, if any, were in place with this individual to work from home?
- What policies and procedures existed for mobile working?
- Is there any legal recourse to persuade the individual to provide access to the computer and home office area?
- Have there been any indications that the individual may be planning to use the employee files, or did she need money, and so on?
So, are these privacy breaches?
Let’s consider each of these perplexing privacy issues by using just one regulation; possibly the most far reaching of recent breach notice laws; the HITECH Act breach notice requirements that expanded the reach of HIPAA. The HHS provides the following in their guidance for complying with the HITECH Act (see it at http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/federalregisterbrea chrfi.pdf).
“For purposes of these provisions, “breach” is defined in the Act as “the unauthorized acquisition, access, use, or disclosure of protected health information which compromises the security or privacy of such information, except where an unauthorized person to whom such information is disclosed would not reasonably have been able to retain such information.” The Act includes exceptions to this definition for cases in which: (1) The unauthorized acquisition, access, or use of PHI is unintentional and made by an employee or individual acting under authority of a covered entity or business associate if such acquisition, access, or use was made in good faith and within the course and scope of the employment or other professional relationship with the covered entity or business associate, and such information is not further acquired, accessed, used, or disclosed; or (2) where an inadvertent disclosure occurs by an individual who is authorized to access PHI at a facility operated by a covered entity or business associate to another similarly situated individual at the same facility, as long as the PHI is not further acquired, accessed, used, or disclosed without authorization (section 13400, definition of “breach ”).”
Now let’s do a quick review of each of these situations using the HITECH Act definition of a breach. Even though all the organizations used as examples were not necessarily healthcare covered entities or business associates, the definition will serve for the purpose of our discussion.
Accidental electronic messages
Since the message was unintentionally sent to the wrong person, an employee at the same organization, during the course of work, and the message was confirmed deleted from the erroneous recipient’s email account, the organization determined that no breach actually occurred, and that no notification was necessary. The company provided information security and privacy training to both the sender and recipient, and then documented the incident and the training.
Would your organization make the same decision? It depends upon your electronic messaging practices, controls you have in place, policies, training, and other related issues. Think about it.
The programmers were definitely doing something bad, but interviews and discussions determined they were doing it because they believed that was the best way to test the programs; there were no policies, procedures or training addressing this type of activity. While the access was technically unauthorized for the individuals, the programs were authorized for the access.
The organization decided not to treat this as a breach. They implemented policies, supporting procedures, and provided not only training but also ongoing awareness communications to the IT areas about the need for incorporating security into their job responsibilities and programming activities. They documented the situation and filed the documentation with their lawyer, who approved of the actions taken.
Would your organization make the same decision? Do you have internal staff who create and maintain your applications and systems code? Or, do you outsource this activity? Do you have policies, procedures and training in place for this issue? Think about it.
Ex-employees taking or keeping PII
The insider threat has been shown to be very real and very significant. While this was a trusted employee, the organization was completely taken by surprise by her sudden departure. Even though she was authorized to access the employee PII as an employee, she immediately became unauthorized as soon as she quit. And since she refused to allow the company to remove the PII and other company data and information from her computer and home, in addition to refusing to cooperate with the organization, this was considered as a privacy breach, and the privacy breach response plan was put into action.
The organization immediately implemented new policies, procedures, training, ongoing awareness communications and contractual requirements for their mobile workers. They also discontinued allowing personnel to use their personally owned computers to do business work. They notified all their employees of the breach and provided them with two years of credit monitoring, per their documented privacy breach response plan. They also provided some question-and-answer sessions for the employees to ask the information security and privacy leaders, along with the legal counsel, questions about how the breach could potentially impact them, and the changes being made to prevent a similar situation.
Would your organization make the same decision? Do you have personnel that work outside of your company facilities? Do you have contracted workers who do mobile working or work from home? Do you allow mobile workers to use their own personal computers and storage devices? Do you have policies, procedures and training in place for this issue? Think about it.
Follow the laws and use common sense
Of course using the HITECH Act definition of a breach is just one definition out of many definitions in many different laws. Your organization must consider all laws that apply to your organization when making decisions in these types of situations. You must comply with your applicable laws; that is a given. However, most of the laws do not clearly cover the many obscure and perplexing issues involving PII that all organizations must address on an ongoing basis.
Many, and perhaps most, organizations often err on the side of being overly cautious and will send notices for all such situations. I call this type of cautionary decision to send breach notifications for any type of situation, inside or out, involving PII to be “over-notifying.”
The potential problem with over-notifying individuals about these types of possible breaches, that may not really be breaches at all when considering all things involved that go far outside the letter of the laws, is that the folks receiving the notification may get irritated that you alarmed them only to find out that the situation really did not put them at any risk of fraud or crime at all.
Common sense thinking also needs to kick in along with your incident response plans when considering breaches involving PII. Know what the definition of a “breach” is within all the laws that apply to you, and then plan for, and document, what you will do for obscure but common situations, such as those described previously. Meet with your legal counsel and ask the questions provided here, and you will be well on your way to making some good decisions for your organizations. By planning now you will save a lot of valuable time later, and your decisions will not be fettered and fuzzy by the stress of the active situation when it occurs.
Rebecca Herold, CIPP, CISSP, CISM, CISA, FLMI, The Privacy Professor ®, is an information security, privacy and compliance consultant, writer and Norwich University MSIA adjunct professor. See more about her services and awareness and training products at http://www.privacyguidance.com. She can be reached at "email@example.com". She will be giving a 1-day class which will cover breach response at the CSI conference in October!