I wrote about this last month, but since the workshop is quickly approaching, I wanted to put out a quick reminder of this message to those of you who may be interested in attending…

The number of information security and privacy incidents are not on the decline; quite to the contrary.  As the amount of data and information continues to grow exponentially, as the flavors of information technologies continue to be cooked up and become quickly ladled into the business environment, as computers and data bytes become more mobile, and as the ethereal world gets more intimate as systems continue to become interconnected, more incidents will occur, more data protection laws will emerge, and more ways to compromise data and systems will continue to appear. 

Establishing effective privacy and information security strategies has moved to the top of the list for companies maintaining customer and employee information. However, there are often gaps in communication and coordination between privacy and information security activities, creating risks for incidents, duplication of effort, contradictory privacy and security initiatives, along with contractual and regulatory noncompliance.

Successful efforts require privacy and information security strategies to be complementary and integrated throughout all of the enterprise, within every business process stage and at every level within the organization.  There must be documented processes for addressing information security and privacy throughout the entire applications and systems development lifecycle.  There must be coordinated and mutually supportive information security and privacy awareness and training efforts.  Corporate policies, and website policies, must establish clear requirements for personnel to follow to safeguard information, in addition to complying with applicable laws and regulations.  There must be processes to ensure the security of information entrusted to third parties.  A corporate information security and privacy framework must be built, using the concepts from such already established and globally supported frameworks as COBIT, ITIL, ISO27001 (BS7799), and the OECD privacy principles, to address these, and other, major information security and privacy issues that will turn out to be your company’s security and privacy Achilles’ heel if you don’t.

I had the opportunity to work with Christopher Grillo to create a workshop,"Effectively Partnering InfoSec and Privacy For Business Success" that provides insight into Privacy and Information Security practitioners’ roles and responsibilities within the organization and offers not only guidance and discussion for how to effectively work together, but we have also spent literally hundreds of hours creating tools to help support information security and privacy that we provide to workshop attendees.  Businesses are now successfully using these tools to make their information seccurity and privacy efforts more efficient and effective. 

Within our workshop, through presentation, discussion, and case-studies, attendees will obtain a better understanding of the challenges faced by both information security and privacy, and be able to create a workable framework for integrating efforts. Participants take away tools for building an effective Privacy and Information Security framework, a roadmap for creating synergy between the groups, and many tools and methodologies to start using right away to result in positive business impact. 

If you take our workshop along with the CSI conference in November, you will save $200 on the regular workshop cost.  I was happy to recently learn that CSI is allowing us to give a discount code for our workshop through my blog; if you only want to attend our workshop, then you can save $100 by using the code PR133 when you register. 

If you already have an integrated, highly successful information security and privacy program in place, that is great!!  I know it takes a lot of effort to have a successful program.  You likely have spent a great amount of figurative blood, sweat and tears in making your program effective and successful. 

I also know there are so many new and evolving challenges that even the most dedicated and hard-working information security and privacy professionals can benefit from new ideas, interactions with others, and effective tools and resources.  If you want to improve your information security and privacy programs, or need help establishing them, I hope you’re able to join us.  After all the hard work we put into creating this workshop, I am happy to know that the people who have attended have told Christopher and I that they found it very valuable, and that they were very pleasantly surprised by the large amount of tools and reference material we provided to the workshop attendees.

Technorati Tags
information security
IT compliance
policies and procedures
corporate governance
conference discount
awareness and training
privacy

Today a press release came from an information security vendor from my neck of the woods, Palisade Systems. 

The press release discussed the results of a survey performed by the vendor that "concluded accidental or malicious data leaks by employees pose the biggest data security, monetary and compliance threat to organizations."

Indeed.  Humans always have been and always will be the biggest vulnerability and threat to basically any type of business function, including information security and privacy compliance. 

I did not contact the company to request a copy of the study results.  However, I found it very ironic that they used the study results, concluding that people are the weakest link in information security and compliance, to then have the vendor CEO basically state that his technology product will prevent sensitive data leaks.

"By combining our content monitoring and blocking technology with ZixCorp’s encryption service, we will now be able to guarantee another level of content security to organizations that require their confidential data remain confidential to only authorized personnel," said Kurt Shedenhelm, CEO and president of Palisade Systems. "While competing vendors provide pieces of an overall content security solution, Palisade and ZixCorp deliver a completely integrated solution that ensures private content is protected even after its been checked and approved internally for outbound delivery."

It bothers and concerns me when vendors make guarantees, especially about security and compliance.  It bothers me when I see claims that a technology product alone "ensures private content is protected."

Just quickly off the top of my head I can think of two situations in which technology is probably not going to be able to stop the leakage of sensitive data from a network.
1)  Sensitive data within encrypted files
2)  Sensitive data transferred out of the network via a network user’s personal email account via a browser front end and webmail

I know these two situations happen within organizations all the time.  I know that even if an organization has blocked access to the most common types of webmail, such as Yahoo, AOL and so on, it is trivial for people to have their own domain name on their own ISP and mailserver using webmail that is not blocked by the filters on the network.

I admit, I know nothing about the Palisade product other than what was written in the press release. And, perhaps there is something it could do about the webmail issue…but I’m not sure…

The situations I mentioned are only two possibilities; there are many more covert, and overt, ways in which data leakage can occur from a network, as well as, of course, non-network ways.

Yes, using good information security technologies to help prevent the leakage of sensitive data will lesson the leaks, and it will also demonstrate due diligence on behalf of the organization.  Yes, it will help to meet a subset of compliance requirements for many different data protection laws and regulations.  But, that is just part of the complete solution for preventing as many data leaks as possible, and for meeting all compliance requirements.

Information security, privacy and compliance take much, much more than technology.  I’ve seen too many SMBs and, frankly, gullible organizations of all sizes, purchase technology products and install them thinking they are then in complete compliance with data protection laws and regulations, only to have a rude awakening later when they get audited, being told they also need policies, procedures, training, awareness and other administrative requirements from the regs.  Or, worse yet, discovering after an incident occurred that the technology alone was not the complete solution after all.

Technology alone will not make any organization completely compliant with any data protection law or regulation.

That’s worth a deja vu…

Technology alone will not make any organization completely compliant with any data protection law or regulation.

Technorati Tags
information security
IT compliance
policies and procedures
data leakage
encryption
awareness and training
privacy

Today a press release came from an information security vendor from my neck of the woods, Palisade Systems. 

The press release discussed the results of a survey performed by the vendor that "concluded accidental or malicious data leaks by employees pose the biggest data security, monetary and compliance threat to organizations."

Indeed.  Humans always have been and always will be the biggest vulnerability and threat to basically any type of business function, including information security and privacy compliance. 

I did not contact the company to request a copy of the study results.  However, I found it very ironic that they used the study results, concluding that people are the weakest link in information security and compliance, to then have the vendor CEO basically state that his technology product will prevent sensitive data leaks.

"By combining our content monitoring and blocking technology with ZixCorp’s encryption service, we will now be able to guarantee another level of content security to organizations that require their confidential data remain confidential to only authorized personnel," said Kurt Shedenhelm, CEO and president of Palisade Systems. "While competing vendors provide pieces of an overall content security solution, Palisade and ZixCorp deliver a completely integrated solution that ensures private content is protected even after its been checked and approved internally for outbound delivery."

It bothers and concerns me when vendors make guarantees, especially about security and compliance.  It bothers me when I see claims that a technology product alone "ensures private content is protected."

Just quickly off the top of my head I can think of two situations in which technology is probably not going to be able to stop the leakage of sensitive data from a network.
1)  Sensitive data within encrypted files
2)  Sensitive data transferred out of the network via a network user’s personal email account via a browser front end and webmail

I know these two situations happen within organizations all the time.  I know that even if an organization has blocked access to the most common types of webmail, such as Yahoo, AOL and so on, it is trivial for people to have their own domain name on their own ISP and mailserver using webmail that is not blocked by the filters on the network.

I admit, I know nothing about the Palisade product other than what was written in the press release. And, perhaps there is something it could do about the webmail issue…but I’m not sure…

The situations I mentioned are only two possibilities; there are many more covert, and overt, ways in which data leakage can occur from a network, as well as, of course, non-network ways.

Yes, using good information security technologies to help prevent the leakage of sensitive data will lesson the leaks, and it will also demonstrate due diligence on behalf of the organization.  Yes, it will help to meet a subset of compliance requirements for many different data protection laws and regulations.  But, that is just part of the complete solution for preventing as many data leaks as possible, and for meeting all compliance requirements.

Information security, privacy and compliance take much, much more than technology.  I’ve seen too many SMBs and, frankly, gullible organizations of all sizes, purchase technology products and install them thinking they are then in complete compliance with data protection laws and regulations, only to have a rude awakening later when they get audited, being told they also need policies, procedures, training, awareness and other administrative requirements from the regs.  Or, worse yet, discovering after an incident occurred that the technology alone was not the complete solution after all.

Technology alone will not make any organization completely compliant with any data protection law or regulation.

That’s worth a deja vu…

Technology alone will not make any organization completely compliant with any data protection law or regulation.

Technorati Tags
information security
IT compliance
policies and procedures
data leakage
encryption
awareness and training
privacy

Yesterday the FTC released a 13-page report on "Internet Data Brokers and Pretexting: Who Has Access to Your Private Records?" documenting their stance on consumer information privacy, discussing their efforts in combatting pretexting, and making recommendations to congress for stronger laws and enforcement.

If you wonder what pretexting is and want to understand better what all the hubbub is surrounding the HP board pretexting and privacy turmoil, then this is a nice report for you to read.

Some interesting tidbits from within the report…

• "…in May 2006, the Commission filed five lawsuits in federal courts across the country against online data brokers that, directly or through third parties, allegedly obtained and sold consumer telephone records without the consumer’s knowledge or consent."

Pretexting appears to be widely practiced.  Considering few, but thankfully growing, numbers of companies have strong identity verification procedures in place, this is not surprising.

• "The complaints charge the defendants with violating Section 5 of the FTC Act, which prohibits ‚Äúunfair or deceptive acts or practices in or affecting commerce.‚Äù7 In each of these cases, the defendants advertised on their websites that they could obtain confidential customer phone records from telecommunications carriers for fees ranging from $65 to $180. The FTC alleged that the defendants or persons they hired obtained this information by using false pretenses, including posing as the phone carrier’s customer to induce the telephone company’s employees to disclose the records."

Unfortunately many information security and privacy officers are not aware of the FTC Act, but they should be.  It certainly applies to a much wider scope of activity than just pretexting; many companies have received fines and penalties under the FTC Act because they did not follow their own posted privacy policies, their employees carelessly sent PII within emails to large groups of customers, and so on.

• "Although the acquisition of telephone records does not present the same risk of immediate financial harm as the acquisition of financial records does, it nonetheless is a serious intrusion into consumers‚Äô privacy and could result in stalking, harassment, and embarrassment."

This is an important point, and it is good that a federal agency is stating this.  Misuse and unauthorized access of PII most commonly is associated with identity fraud, but so many more bad things can happen as a result of criminals and fraudsters obtaining PII.

• "And while there is no specific federal civil law that prohibits pretexting for consumer telephone records, the Commission may bring a law enforcement action against a pretexter of telephone records for deceptive or unfair practices under Section 5 of the FTC Act."

Good!  In fact, much of the strength of the FTC Act is that it does not get into naming specific activities, but covers the general ways in which companies must do business in an honest and ethical manner.

• "In addition to the recent cases involving telephone records pretexting, the Commission has brought actions under Section 5 of the FTC Act and Section 521 of the GLBA against businesses that use false pretenses to obtain financial information without consumer consent."

Another good point; pretexting is also covered under the Gramm Leach Bliley Act (GLBA).

• In 2oo1, "FTC staff conducted a ‚Äúsurf‚Äù of more than 1,000 websites and a review of more than 500 advertisements in print media to identify firms offering to conduct searches for consumers‚Äô financial data. The staff found approximately 200 firms that offered to obtain and sell consumers‚Äô asset or bank account information to third parties. The staff then sent notices to these firms advising them that their practices were subject to the FTC Act and the GLBA, and providing information about how to comply with the law."

200 companies from the 500 ads…if each of the ads was from a different company (which they probably were not) this would mean 40% of companies they looked at were obtaining personal information through other than legitimate or ethical methods.  This percentage is likely higher considering some of the companies probably put more than one of these ads out on the websites.

• "In 1999, Congress passed the GLBA, which provided another tool to attack the unauthorized acquisition of consumers‚Äô financial information.17 Section 521 of the GLBA prohibits ‚Äúfalse, fictitious, or fraudulent statement[s] or representation[s] to an officer, employee, or agent of a financial institution‚Äù to obtain customer information of a financial institution."

This GLBA statement covers a wide range of activities that have been reportedly pursued by many organizations.

As the report indicates, the FTC has made efforts to warn the public about pretexting through some awareness efforts, such as their consumer alert, "Pretexting: Your Personal Information Revealed."

• "in several recent cases, the Commission has challenged data security practices as unreasonably exposing consumer data to theft and misuse.26 Companies that have failed to implement reasonable security and safeguard processes for consumer data face liability under various statutes enforced by the FTC, including the Fair Credit Reporting Act, the Safeguards provisions of the GLBA, and Section 5 of the FTC Act."

And also the Fair Credit Reporting Act (FCRA); another regulation to make sure your company is complying with, if applicable.  Make sure you know if it IS applicable; don’t make assumptions that it is not.

The FTC’s Recommendations within the report:

1.  "Have more specific prohibitions against pretexting for consumer telephone records and soliciting or selling consumer telephone records obtained through actual or reasonably known pretexting activity."

2.  Ensure "any such legislation contain appropriate exceptions for specified law enforcement purposes."

3.  Ensure "as part of any such legislation give the Commission authority to seek civil penalties against violators."

4.  "Congress enact cross-border fraud legislation. The proposal, called the ‚ÄúUS SAFE WEB Act,‚Äù will overcome many of the existing obstacles to information sharing in cross-border investigations."

Technorati Tags
information security
IT compliance
policies and procedures
FTC Act
GLBA
FCRA
pretexting
awareness and training
privacy

Yesterday the news report following my commentary was published.

It doesn’t say what the sensitive information was, but makes clear that often times the wrong law is used to pursue wrongful disclosure of personal information.  HIPAA (the Privacy Rule and the Security Rule) tends to be foremost in most people’s minds when privacy infractions occur because it is written about so often.  However, as the article points out, it only applies to covered entities (CEs). 

Unfortunately the discussion given to the television station is misleading.  The list provided is incomplete in that some organizations not in the list are considered hybrid entities; those whose primary business is not being a healthcare provider or healthcare insurer, but have portions of their business that do those type of activities.  Some educational institutions certainly are hybrid entities; simplistically those who provide health clinic services with the medical staff providing the care on their payroll.

It is good whenever considering privacy issues and regulatory noncompliance related to the protection of personally identifiable information (PII) within educational institutions to keep FERPA in the foremost of your considerations.

However, it *IS* possible that inappropriate sharing of PII can be covered by more than one regulation; and certainly, depending upon the details and involved issues, a situation where student PII is inappropriately shared with others could come under both FERPA and HIPAA.  It is important to discuss any situation with a lawyer well-versed in the data protection laws and regulations to determine which one to use when pursuing legal action.

"A Grove mother who’s suing the school district on behalf of her 15 year-old son says an administrator told her sensitive information about another student.

Specific medical information that she says, he had no right to reveal.

Sheila Dawson’s lawsuit alleges Grove school faculty and administrators violated the Health Insurance Portability and Accountability Act or HIPAA, when they told others medical facts and lies about her son and other students.

The News on 6 spoke with a HIPAA expert and learned that "the act" only protects healthcare providers, healthcare clearing houses and others who bill electronically for medical services. Elise Brennan says if the information comes from anywhere else, it’s not protected under HIPAA. "HIPAA doesn’t pertain to idle gossip. If an employer or the school has learned information from gossip, then that’s not protected health information, which is what’s covered under HIPAA."

The US Department of Education points to the Family Education Right to Privacy Act, which prohibits schools from disclosing a student’s records without parental consent.

If a school has medical information about a student, it becomes part of the education record and is protected under FERPA."

Technorati Tags
information security
IT compliance
policies and procedures
HIPAA
FERPA
student privacy
awareness and training
privacy

I read with interest an article from The Register yesterday, "Malware Lurks Behind Safety Seal" that looked at some research done by Ben Edelman for his PhD at Harvard.

Within his report he stated, "I find that TRUSTe-certified sites are more than twice as likely to be untrustworthy as uncertified sites, a difference which remains statistically and economically significant when restricted to “complex” commercial sites." He also determined through his research of cross-referencing 500,000 websites that of the ones with TRUSTe certification, 5.4% were linked to either spamming or spywire, compared to 2.5% of the sites with no TRUSTe certification.

TRUSTe disputed the findings.  They indicate that some of the sites Edelman reported as having the TRUSTe seal either did not actually have it, or had the seal revoked.

The research report and TRUSTe rebuttal are interesting reads.

Bottom line, consumers must realize that web seals typically only represent the "certification" of that site at one point in time.  Security and trustworthiness of a site will change as site updates are made, staff changes are made, and other business changes occur.  A web seal can show the site was considered, by a certification vendor, as being trustworthy on the date indicated on the seal, but always take that seal with a grain of salt knowing that since the seal was put on the site it may no longer be as trustworthy. 

If you aren’t sure about doing business with a site, besides just looking at the seal, among other things also look at their posted privacy policy (if they don’t have one, that’s a red flag for you), see if they use SSL for collecting personal and sensitive information, see if they use cookies in an acceptable way (very simplistically meaning they do not collect clear text meaningful or personal data within cookies), they don’t use web bugs on their site, and they have not been involved in any litigation or had adverse audit findings about their site security.

Yes, I know that is a lot of checking to do before you make that purchase that you really, really wanted.  You may decide to take the risk.  But just keep in mind that the less checks you perform before doing business with a site, the more likely it will be that you will experience some adverse consequences.

Technorati Tags
information security
IT compliance
policies and procedures
web bugs
trust seals
TRUSTe
awareness and training
privacy

On September 20 the U.S. Office of Management and Budget (OMB) issued an 11-page memo with guidance to government agencies on how to plan to give notifications for data breaches.

This is a very important issue.  Too many times organizations, including, certainly, government agencies, have woefully responded to breaches and handled the notifications in a much less than stellar manner.  Good guidance would certainly be welcome.

I read the guidelines closely, hoping to find recommendations for a common ground of good practice not only for government agencies, but also to serve as a starting point or model for any type of organization.

Overall there are some good recommendations.  However, it misses an important point that bad things can be done with personally identifiable information (PII) other than what the memo defines as "identity theft."  Granted, the memo clearly states that the purpose is to notify individuals if identity theft specifically is a good possibility, but I think it should have also at least mentioned that many bad things have also been done with PII beyond identity theft, such as stalking, spamming, unsolicited phone calls, using other people’s medical insurance, voting, and so on.

Just a few of the excerpts…

• "The memorandum provides a menu of steps for anagency to consider, so that it may pursue such a risk-based, tailored response. Ultimately, the precise steps to take must be decided in light of the particular facts presented, as there is no single response for all breaches."

Yes, the response definitely must be risk-based, considering *ALL* types of risks, and the resulting actions based upon the specific situation.  Certainly pre-planning MUST occur.   Unfortunately most organizations do not have a breach identification plan in place, let alone a breach notification plan, according to many different surveys. 

Most of the organizations I’ve spoken with who have a breach notification plan in place do not have one that is truly executable, taking into consideration the types of data involved, or how to communicate about the breach to the impacted individuals or the news media.

• "This memorandum focuses on the type of identifying information generally used to commit identity theft." 

In fact the memo not only focuses on that type of PII, but also just on the potential of identity theft and nothing beyond, as I stated earlier.

• "Thus, an important first step in responding to a breach is for agencies to engage in advance planning for this contingency."

Indeed!  Pre-planning must be done to handle an incident and determine when, if and how to provide notification in order to be as effective and efficient as possible, and to lessen the resulting potential damage as much as possible.

• "Our experience suggests that such a core group should include, at minimum, an agency’s chief information officer, chief legal officer, chief privacy officer (or their designees), a senior management official from the agency, and the agency’s inspector general (or equivalent or designee)."

Where’s the information security officer, CISO, in this list?  Are they assuming the CIO has all the background and information security knowledge necessary for this type of event?  Most CIOs have awareness, but not all the experience and knowledge necessary to use for an effective breach notification response.  It is very important to include the CISO.  Even if notification is determined to not be necessary it is important to remember a security incident has occurred and needs to be resolved. 

Security incident response plans must consider breach notifications, and breach notification teams must consider information security and the actions they must take to help prevent a similar incident from happening.

Another person to definitely include in the core group is the public relations officer.  They must know the reality of what is going on with the incident in order to release information about the incident in the most honest and effective way possible.

• "Thus, the first steps in considering whether there is a risk of identity theft, and hence whether art "identity theft response" is necessary, are understanding the kind of information most typically used to commit identity theft and then determining whether that kind of information has been potentially compromised in the incident being examined."

Again, the considerations must go beyond just whether or not identity theft can occur, and it will depend upon the situation.  For example, what if a database of names and addresses were stolen from a company that is a potential terrorist target?  There could be safety issues involved here for these individuals, even if the possibility of identity theft with this information is low.

• "An SSN standing alone can generate identity theft. Combinations of information can have the same effect. With a name, address, or telephone number, identity theft becomes possible, for instance, with any of the following: (1) any government-issued identification number (such as a driver’s license number if the thief cannot obtain the SSN); (2) a biometric record; (3) a financial account number, together with a PIN or security code, if a PTN or security code is necessary to access the account; or (4) any additional, specif c factor that adds to the personally identifying profile of a specific individual, such as a relationship with a specific financial institution or membership in a club."

All good information to have documented within the breach notification plan.  Along, of course, with other types of data that could lead to bad things.

• "Our experience suggests that in determining the level of risk of identity theft, the agency should consider not simply the data that was compromised, but all of the circumstances of the data loss, including
  • how easy or difficult it would be for an unauthorized person to access the covered information in light of the manner in which the covered information was protected;
  • the means by which the loss occurred, including whether the incident might be the result of a criminal act or is likely to result in criminal activity;
  • the ability of the agency to mitigate the identity theft;
  • and evidence that the compromised information is actually being used to commit identity theft"

Some of these recommendations are concerning.  It implies that if the theft of the PII can be mitigated the individuals involved should not be notified.  Wouldn’t this be a little bit like saying the police do not have to notify a homeowner if they found a burgler in the homeowner’s house and chased him away, and don’t think the burgler actually took anything?

I do believe that stongly encrypted data that is stolen poses very little risk to the individuals.  Whether or not data is encrypted should be a consideration.  It would be nice if we could get to a point where all PII on mobile computers and storage devices were strongly encrypted.   

However, trying to second guess WHY the incident occurred and the criminals INTENTIONS is not a good idea. 

Also, breach notifications should be made as quickly as possible.  Just because PII has not been used within a week or two or three…or even a couple of months…to commit crime, does not mean that the individuals’ PII will not be used to commit crimes months later.  Some criminals are smart enough and patient enough to wait until the heat is off to do their crimes. 

• "For example, as a general matter, the risk of identity theft is greater if the covered inforrnation was stolen by a thief who was targeting the data (such as a computer hacker) than if the information was inadvertently left unprotected in a public location, such as in a briefcase in a hotel lobby. Similarly, in some cases of theft, the circumstances might indicate that the data-storage device, such as a computer left in a car, rather than the information itself, was the target of the theft."

You cannot know the intentions of an unknown thief!  It is best for the potentional vicitms involved for an organization to consider that the thief HAS intentions to do bad things…or potentially someone buying the stolen laptop from the thief will want to do bad things with the PII.

Granted, the circumstances must be considered.  If someone accidentally knocked their computer off the Grand Canyon, smashing it into canyon gravel, then true, this would not need notification…but then again, this really wouldn’t be a breach.  Yes, this is a bit of a facetious example, but hopefully you see my point.

• "Considering these factors together should permit the agency to develop an overall sense of where along the continuum of identity-theft risk the risk created by the particular incident falls. That assessment, in turn, should guide the agency’s further actions."

This AND following the at least 33 state level breach notification laws.  Those laws do not try to second guess the intentions of criminals.  It is odd the memo does not even reference the state level breach notification laws; it mentions the state level freeze laws.

• "While assessing the level of risk in a given situation, the agency should simultaneously consider options for attenuating that risk."

More reason to include the CISO in the core breach notification team.

• "It might take a few months for most signs of fraudulent accounts to appear on the credit report, and this option is most useful when the data breach involves information that can be used to open new accounts."

Yes, it could!  It could also take many months.  Funny they included the seemingly contradictory statement earlier when talking about how to determine IF notification should be made. 

It is still nice to see this point being made, though, within a government publication such as this.  Often organizations and agencies make published statements that "there is no evidence of fraud occurring" just a week or two after the data compromise. 

They recommend telling the individuals to

• "Place an initial fraud alert on credit reports maintained by the three major credit bureaus noted above."

Legitimate advice, but it is still placing the responsibility of dealing with the organization’s breach impact upon the victim.  All unplanned time, stress and irritation for individuals when the breach often could have been prevented to begin with…or if the data had been encrypted!

• "Be aware that the public announcement of the breach could itself cause criminals engaged in fraud, under the guise of providing legitimate assistance, to use various techniques, including email or the telephone, to deceive individuals affected by the breach into disclosing their credit card numbers, bank account information, SSNs, passwords, or other sensitive personal information."

This may be possible, but then again, these scams are going on all the time.  Silence about a crime that has occurred potentially impacting privacy and security is not a good risk mitigation control.  It’s usually better to have many eyes and ears on the alert for the subsequent wrong-doings with the stolen data than worry about one or two people who may take advantage.

Here are the high levle recommendations for actually executing the breach notification; see the memo for the details that go with each:

"1. Timing: The notice should be provided in a timely manner, but without compounding the harm from the initial incident through premature announcement based on incomplete facts or in a manner Iikely to make identity theft more likely to occur as a result of the announcement. While it is important to notify promptly those who may be affected so that they can take protective steps quickly, false alarms or inaccurate alarms are counterproductive."

"2. Source: Given the serious security and privacy concerns raised by data breaches, notification to individuals affected by the data loss should be issued by a responsible official of the agency, or, in those instances in which the breach involves a publicly known component of an agency, a responsible official of the component."

"3. Contents: The substance of the notice should be reduced to a stand-alone document and written in clear, concise, and easy-to-understand language, capable of individual distribution and/or posting on the agency’s website and other information sites."

"4. Method of Notification: Notification should occur in a manner calibrated to ensure that the individuaIs affected receive actual notice of the incident and the steps they should take. First-class mail notification to the last known mailing address of the individual should be the primary means by which the agency provides notification."

"5. Preparing for follow-on inquiries: Those notified can experience considerable frustration if, in the wake of an initial public announcement, they are unable to find sources of additional accurate information."

"6. Prepare counterpart entities that may receive a slsrge in inquiries: Depending on the nature of the incident, certain entities, such as the credit-reporting agencies or the FTC, may experience a surge in inquiries also."

On the last page they provide a "Risk Based Decision Framework" flowchart.  I really like, and encourage organizations to use, flowcharts to map out and visually describe procedures.  It makes it clearer what needs to be done, and can be referenced more quickly than 10 pages of documentation (which you still need as support for the flowchart) on its own.

This flowchart would make a good starting point for organizations.  It will need modification to go beyond just indentity theft possibilities, and your will want to incorporate the state level breach notification requirement considerations as well.

Overall this is a nice resource for organizations to use when establishing their breach notification plans, but organization need to keep in mind that it is incomplete and that they need to consider the other issues I discussed earlier.

Technorati Tags
information security
IT compliance
policies and procedures
identity theft
OMB
breach notification
incident response
awareness and training
privacy

On September 20 the U.S. Office of Management and Budget (OMB) issued an 11-page memo with guidance to government agencies on how to plan to give notifications for data breaches.

This is a very important issue.  Too many times organizations, including, certainly, government agencies, have woefully responded to breaches and handled the notifications in a much less than stellar manner.  Good guidance would certainly be welcome.

I read the guidelines closely, hoping to find recommendations for a common ground of good practice not only for government agencies, but also to serve as a starting point or model for any type of organization.

Overall there are some good recommendations.  However, it misses an important point that bad things can be done with personally identifiable information (PII) other than what the memo defines as "identity theft."  Granted, the memo clearly states that the purpose is to notify individuals if identity theft specifically is a good possibility, but I think it should have also at least mentioned that many bad things have also been done with PII beyond identity theft, such as stalking, spamming, unsolicited phone calls, using other people’s medical insurance, voting, and so on.

Just a few of the excerpts…

• "The memorandum provides a menu of steps for anagency to consider, so that it may pursue such a risk-based, tailored response. Ultimately, the precise steps to take must be decided in light of the particular facts presented, as there is no single response for all breaches."

Yes, the response definitely must be risk-based, considering *ALL* types of risks, and the resulting actions based upon the specific situation.  Certainly pre-planning MUST occur.   Unfortunately most organizations do not have a breach identification plan in place, let alone a breach notification plan, according to many different surveys. 

Most of the organizations I’ve spoken with who have a breach notification plan in place do not have one that is truly executable, taking into consideration the types of data involved, or how to communicate about the breach to the impacted individuals or the news media.

• "This memorandum focuses on the type of identifying information generally used to commit identity theft." 

In fact the memo not only focuses on that type of PII, but also just on the potential of identity theft and nothing beyond, as I stated earlier.

• "Thus, an important first step in responding to a breach is for agencies to engage in advance planning for this contingency."

Indeed!  Pre-planning must be done to handle an incident and determine when, if and how to provide notification in order to be as effective and efficient as possible, and to lessen the resulting potential damage as much as possible.

• "Our experience suggests that such a core group should include, at minimum, an agency’s chief information officer, chief legal officer, chief privacy officer (or their designees), a senior management official from the agency, and the agency’s inspector general (or equivalent or designee)."

Where’s the information security officer, CISO, in this list?  Are they assuming the CIO has all the background and information security knowledge necessary for this type of event?  Most CIOs have awareness, but not all the experience and knowledge necessary to use for an effective breach notification response.  It is very important to include the CISO.  Even if notification is determined to not be necessary it is important to remember a security incident has occurred and needs to be resolved. 

Security incident response plans must consider breach notifications, and breach notification teams must consider information security and the actions they must take to help prevent a similar incident from happening.

Another person to definitely include in the core group is the public relations officer.  They must know the reality of what is going on with the incident in order to release information about the incident in the most honest and effective way possible.

• "Thus, the first steps in considering whether there is a risk of identity theft, and hence whether art "identity theft response" is necessary, are understanding the kind of information most typically used to commit identity theft and then determining whether that kind of information has been potentially compromised in the incident being examined."

Again, the considerations must go beyond just whether or not identity theft can occur, and it will depend upon the situation.  For example, what if a database of names and addresses were stolen from a company that is a potential terrorist target?  There could be safety issues involved here for these individuals, even if the possibility of identity theft with this information is low.

• "An SSN standing alone can generate identity theft. Combinations of information can have the same effect. With a name, address, or telephone number, identity theft becomes possible, for instance, with any of the following: (1) any government-issued identification number (such as a driver’s license number if the thief cannot obtain the SSN); (2) a biometric record; (3) a financial account number, together with a PIN or security code, if a PTN or security code is necessary to access the account; or (4) any additional, specif c factor that adds to the personally identifying profile of a specific individual, such as a relationship with a specific financial institution or membership in a club."

All good information to have documented within the breach notification plan.  Along, of course, with other types of data that could lead to bad things.

• "Our experience suggests that in determining the level of risk of identity theft, the agency should consider not simply the data that was compromised, but all of the circumstances of the data loss, including
  • how easy or difficult it would be for an unauthorized person to access the covered information in light of the manner in which the covered information was protected;
  • the means by which the loss occurred, including whether the incident might be the result of a criminal act or is likely to result in criminal activity;
  • the ability of the agency to mitigate the identity theft;
  • and evidence that the compromised information is actually being used to commit identity theft"

Some of these recommendations are concerning.  It implies that if the theft of the PII can be mitigated the individuals involved should not be notified.  Wouldn’t this be a little bit like saying the police do not have to notify a homeowner if they found a burgler in the homeowner’s house and chased him away, and don’t think the burgler actually took anything?

I do believe that stongly encrypted data that is stolen poses very little risk to the individuals.  Whether or not data is encrypted should be a consideration.  It would be nice if we could get to a point where all PII on mobile computers and storage devices were strongly encrypted.   

However, trying to second guess WHY the incident occurred and the criminals INTENTIONS is not a good idea. 

Also, breach notifications should be made as quickly as possible.  Just because PII has not been used within a week or two or three…or even a couple of months…to commit crime, does not mean that the individuals’ PII will not be used to commit crimes months later.  Some criminals are smart enough and patient enough to wait until the heat is off to do their crimes. 

• "For example, as a general matter, the risk of identity theft is greater if the covered inforrnation was stolen by a thief who was targeting the data (such as a computer hacker) than if the information was inadvertently left unprotected in a public location, such as in a briefcase in a hotel lobby. Similarly, in some cases of theft, the circumstances might indicate that the data-storage device, such as a computer left in a car, rather than the information itself, was the target of the theft."

You cannot know the intentions of an unknown thief!  It is best for the potentional vicitms involved for an organization to consider that the thief HAS intentions to do bad things…or potentially someone buying the stolen laptop from the thief will want to do bad things with the PII.

Granted, the circumstances must be considered.  If someone accidentally knocked their computer off the Grand Canyon, smashing it into canyon gravel, then true, this would not need notification…but then again, this really wouldn’t be a breach.  Yes, this is a bit of a facetious example, but hopefully you see my point.

• "Considering these factors together should permit the agency to develop an overall sense of where along the continuum of identity-theft risk the risk created by the particular incident falls. That assessment, in turn, should guide the agency’s further actions."

This AND following the at least 33 state level breach notification laws.  Those laws do not try to second guess the intentions of criminals.  It is odd the memo does not even reference the state level breach notification laws; it mentions the state level freeze laws.

• "While assessing the level of risk in a given situation, the agency should simultaneously consider options for attenuating that risk."

More reason to include the CISO in the core breach notification team.

• "It might take a few months for most signs of fraudulent accounts to appear on the credit report, and this option is most useful when the data breach involves information that can be used to open new accounts."

Yes, it could!  It could also take many months.  Funny they included the seemingly contradictory statement earlier when talking about how to determine IF notification should be made. 

It is still nice to see this point being made, though, within a government publication such as this.  Often organizations and agencies make published statements that "there is no evidence of fraud occurring" just a week or two after the data compromise. 

They recommend telling the individuals to

• "Place an initial fraud alert on credit reports maintained by the three major credit bureaus noted above."

Legitimate advice, but it is still placing the responsibility of dealing with the organization’s breach impact upon the victim.  All unplanned time, stress and irritation for individuals when the breach often could have been prevented to begin with…or if the data had been encrypted!

• "Be aware that the public announcement of the breach could itself cause criminals engaged in fraud, under the guise of providing legitimate assistance, to use various techniques, including email or the telephone, to deceive individuals affected by the breach into disclosing their credit card numbers, bank account information, SSNs, passwords, or other sensitive personal information."

This may be possible, but then again, these scams are going on all the time.  Silence about a crime that has occurred potentially impacting privacy and security is not a good risk mitigation control.  It’s usually better to have many eyes and ears on the alert for the subsequent wrong-doings with the stolen data than worry about one or two people who may take advantage.

Here are the high levle recommendations for actually executing the breach notification; see the memo for the details that go with each:

"1. Timing: The notice should be provided in a timely manner, but without compounding the harm from the initial incident through premature announcement based on incomplete facts or in a manner Iikely to make identity theft more likely to occur as a result of the announcement. While it is important to notify promptly those who may be affected so that they can take protective steps quickly, false alarms or inaccurate alarms are counterproductive."

"2. Source: Given the serious security and privacy concerns raised by data breaches, notification to individuals affected by the data loss should be issued by a responsible official of the agency, or, in those instances in which the breach involves a publicly known component of an agency, a responsible official of the component."

"3. Contents: The substance of the notice should be reduced to a stand-alone document and written in clear, concise, and easy-to-understand language, capable of individual distribution and/or posting on the agency’s website and other information sites."

"4. Method of Notification: Notification should occur in a manner calibrated to ensure that the individuaIs affected receive actual notice of the incident and the steps they should take. First-class mail notification to the last known mailing address of the individual should be the primary means by which the agency provides notification."

"5. Preparing for follow-on inquiries: Those notified can experience considerable frustration if, in the wake of an initial public announcement, they are unable to find sources of additional accurate information."

"6. Prepare counterpart entities that may receive a slsrge in inquiries: Depending on the nature of the incident, certain entities, such as the credit-reporting agencies or the FTC, may experience a surge in inquiries also."

On the last page they provide a "Risk Based Decision Framework" flowchart.  I really like, and encourage organizations to use, flowcharts to map out and visually describe procedures.  It makes it clearer what needs to be done, and can be referenced more quickly than 10 pages of documentation (which you still need as support for the flowchart) on its own.

This flowchart would make a good starting point for organizations.  It will need modification to go beyond just indentity theft possibilities, and your will want to incorporate the state level breach notification requirement considerations as well.

Overall this is a nice resource for organizations to use when establishing their breach notification plans, but organization need to keep in mind that it is incomplete and that they need to consider the other issues I discussed earlier.

Technorati Tags
information security
IT compliance
policies and procedures
identity theft
OMB
breach notification
incident response
awareness and training
privacy