Monday, March 19, 2012
Are Cloud Service Providers HIPAA Business Associates?
Are Cloud Service Providers HIPAA Business Associates?
As the use of cloud computing becomes more prevalent in health care, organizations that must comply with HIPAA face a number of compliance challenges, including the question of whether they should consider cloud service providers as HIPAA business associates. It matters because business associates have certain privacy and security requirements under the law that other third parties don’t -- and in turn, covered entities have specific requirements when it comes to business associates. Since guidance is tough to come by and consensus isn’t yet established, the decision can be complex.
The HIPAA privacy rule defines a business associate as “a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.” That seems clear (i.e., disclosing PHI to a vendor means they’re a business associate) until you examine the specifics of “disclosure.” For example, some cloud service models only require storage of PHI; does mere storage constitute “disclosure” in the manner intended? Other vendors might backup the date automatically; is that “disclosure”? How about debugging, troubleshooting or monitoring? The list of ambiguous scenarios is a mile long.
Making the HIPAA business associate call
Not everybody agrees and arguments can be made on both sides when it comes to assigning the business associate designation to cloud providers. For example, the U.S. Department of Health and Human Services FAQ tells us that a “conduit” of data (like a courier or a data transfer service) is not a business associate because it doesn’t routinely access the data as part of the normal course of their activities (“a conduit transports information but does not access it other than on a random or infrequent basis…”). However, according to a separate article on the HHS FAQ, a software vendor is a business associate when it needs routine access “…in order to provide its service… For example, a software company that hosts the software containing patient information on its own server or accesses patient information when troubleshooting ….”
So, depending on the level of access the provider has to the data, different considerations might apply. HHS has attempted to clarify some of these questions in its most recent rulemaking, but still the issue comes down to routine, normative access on one hand compared to infrequent, anomalous access on the other. This means the decision comes down to (as usual) your particular usage -- i.e., not whether you’re using cloud, but howyou’re using it. Using a SaaS where PHI is accessed every day by vendor personnel? That’s most likely a HIPAA business associate. Using a high-volume PaaS where only your staff routinely looks at data? Maybe not.
It’s a judgment call where usage is paramount. One caveat though: Usage isn’t always constant. You may initially engage a vendor to perform services only involving storage, but subsequently grant them other access. This means they might not be a business associate today, but could become one tomorrow.
Strategizing around HIPAA business associate status
A byproduct of all this is that organizations can reach different conclusions about the same vendor -- you might conclude the vendor is a business associate for you, whereas another covered entity might conclude otherwise. You can make this decision on an ad hoc basis of course, but the pragmatist can look to fold it into a broader strategy. For example, since business associates have enhanced security and privacy obligations relative to other vendors (for example, HITECH now mandates measures equivalent to covered entities), a covered entity with a more conservative posture may elect to treat cloud service providers as business associates in due diligence activities and contract negotiation.
While this is the most conservative approach, asking a cloud provider to enter into a business associate agreement can and does lead to many blank stares (or even calculated resistance) from vendors. Cloud services providers not focused on health care may not understand what a business associate is or why it matters -- while discount vendors might be loath to sign agreements because of additional due diligence or security control requirements. The point is, if you intend to treat your cloud services providers as a business associate, expect to have to educate them about what that means and what they’re obligations are -- and also anticipate potential resistance ahead of time. A vendor that specializes in health care or that has a health care focused service offering may be useful to consider should you choose to go down this route.
Deciding whether your cloud service providers are or are not business associates is a uniquely personal decision -- it varies by organization, by usage, and by organizational strategy. So be wary whenever someone argues that cloud vendors always are (or always aren’t) HIPAA business associates; remember that the definition of “cloud” is broad and can include a lot of different scenarios.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.
As the use of cloud computing becomes more prevalent in health care, organizations that must comply with HIPAA face a number of compliance challenges, including the question of whether they should consider cloud service providers as HIPAA business associates. It matters because business associates have certain privacy and security requirements under the law that other third parties don’t -- and in turn, covered entities have specific requirements when it comes to business associates. Since guidance is tough to come by and consensus isn’t yet established, the decision can be complex.
The HIPAA privacy rule defines a business associate as “a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.” That seems clear (i.e., disclosing PHI to a vendor means they’re a business associate) until you examine the specifics of “disclosure.” For example, some cloud service models only require storage of PHI; does mere storage constitute “disclosure” in the manner intended? Other vendors might backup the date automatically; is that “disclosure”? How about debugging, troubleshooting or monitoring? The list of ambiguous scenarios is a mile long.
Making the HIPAA business associate call
Not everybody agrees and arguments can be made on both sides when it comes to assigning the business associate designation to cloud providers. For example, the U.S. Department of Health and Human Services FAQ tells us that a “conduit” of data (like a courier or a data transfer service) is not a business associate because it doesn’t routinely access the data as part of the normal course of their activities (“a conduit transports information but does not access it other than on a random or infrequent basis…”). However, according to a separate article on the HHS FAQ, a software vendor is a business associate when it needs routine access “…in order to provide its service… For example, a software company that hosts the software containing patient information on its own server or accesses patient information when troubleshooting ….”
So, depending on the level of access the provider has to the data, different considerations might apply. HHS has attempted to clarify some of these questions in its most recent rulemaking, but still the issue comes down to routine, normative access on one hand compared to infrequent, anomalous access on the other. This means the decision comes down to (as usual) your particular usage -- i.e., not whether you’re using cloud, but howyou’re using it. Using a SaaS where PHI is accessed every day by vendor personnel? That’s most likely a HIPAA business associate. Using a high-volume PaaS where only your staff routinely looks at data? Maybe not.
It’s a judgment call where usage is paramount. One caveat though: Usage isn’t always constant. You may initially engage a vendor to perform services only involving storage, but subsequently grant them other access. This means they might not be a business associate today, but could become one tomorrow.
Strategizing around HIPAA business associate status
A byproduct of all this is that organizations can reach different conclusions about the same vendor -- you might conclude the vendor is a business associate for you, whereas another covered entity might conclude otherwise. You can make this decision on an ad hoc basis of course, but the pragmatist can look to fold it into a broader strategy. For example, since business associates have enhanced security and privacy obligations relative to other vendors (for example, HITECH now mandates measures equivalent to covered entities), a covered entity with a more conservative posture may elect to treat cloud service providers as business associates in due diligence activities and contract negotiation.
While this is the most conservative approach, asking a cloud provider to enter into a business associate agreement can and does lead to many blank stares (or even calculated resistance) from vendors. Cloud services providers not focused on health care may not understand what a business associate is or why it matters -- while discount vendors might be loath to sign agreements because of additional due diligence or security control requirements. The point is, if you intend to treat your cloud services providers as a business associate, expect to have to educate them about what that means and what they’re obligations are -- and also anticipate potential resistance ahead of time. A vendor that specializes in health care or that has a health care focused service offering may be useful to consider should you choose to go down this route.
Deciding whether your cloud service providers are or are not business associates is a uniquely personal decision -- it varies by organization, by usage, and by organizational strategy. So be wary whenever someone argues that cloud vendors always are (or always aren’t) HIPAA business associates; remember that the definition of “cloud” is broad and can include a lot of different scenarios.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.
SSAE 16 for Cloud Service Providers?
SSAE 16 for Cloud Service Providers?
Cloud consumers interested in getting a glimpse into the state of a cloud service provider’s internal security controls are likely familiar with the Statement on Auditing Standards No. 70 report, usually called SAS 70. This report served as an independent audit statement of an organization’s internal controls (financial and infrastructure-related). In 2011, however, the SAS 70 was retired in favor of the American Institute of Certified Public Accountants (AICPA) Statement on Standards for Attestation Engagements (SSAE) number 16 (SSAE 16).
While many CSPs touted their SAS 70 reports, many in the security community criticized theSAS 70, as the controls being audited were self-defined by the cloud service provider (CSP). What’s changed with the SSAE 16? Is it a better tool for evaluating CSP security?
SSAE 16 and SOC reports
The first key to understanding the new SSAE 16 standard is to recognize the various types of reports available. The SSAE 16 is very similar to the SAS 70, with the primary difference being the requirement for a written assertion by management that the controls included and audited are accurate and functioning properly. The SSAE 16 also aligns somewhat better with other international auditing standards. When a CSP is audited for SSAE 16 standards, the auditor will provide a Service Organization Control (SOC) 1 report at the culmination of the audit. This SOC 1 report can be a Type 1 or a Type 2 (much like SAS 70). Type 1 represents an attestation of controls efficacy and accuracy at a given point in time, while a Type 2 attests to the same over a period of time, usually six months or one year.
Unfortunately, the SSAE 16 SOC 1 report suffers from the same fundamental problem that the SAS 70 had before it: the controls are self-defined. Most security and risk management professionals would prefer to see more “best practices” standardization in independent audit reports for CSPs. Fortunately, there are two other types of SOC reports.
SOC 2 and SOC 3 reports are aligned with the AICPA Trust Services Principles and Criteria (TSPC). These principles are focused on five areas:
• Security: Unauthorized access to systems (both physical and logical) is prevented through controls.
• Confidentiality: Sensitive information labeled as confidential is protected with adequate controls (customer data and systems would likely fall into this category).
• Privacy: Personal information is collected and managed in accordance with the AICPA Generally Accepted Privacy Principles.
• Availability: Systems are designed with uptime and availability in mind, and continuity of system operations is maintained.
• Processing Integrity: All system processing activities are accurate, authorized, complete and authorized.
SOC 2 reports can also come in Type 1 and Type 2 variants. Most security professionals are pleased to see the evolution of the SOC 2, and view it as a more robust controls audit and attestation report for CSPs. SOC 2 is intended for internal consumption, with detailed technical information and sensitive audit data.
SOC 3 reports attest to the same standards as a SOC 2, but are issued with public consumption in mind. They’re much more general in nature and don’t reveal potentially dangerous technical security details that an attacker could leverage. The SOC 3 also has one very compelling advantage: It’s associated with a certification that CSPs can display for customers and prospects. This certification, known as the “SOC 3: SysTrust for Service Organizations” seal, is a big step in the right direction since security teams will know immediately that a CSP has conformed to the TSPC guidelines.
Not enough security details
Still, the TSPC guidelines go into nowhere enough detail for most security professionals. Compared to the Cloud Security Alliance (CSA) Cloud Controls Matrix and Consensus Assessments Initiative Questionnaire (CAIQ), the level of concrete security guidance and rigorous security controls is not there yet. Additionally, the TSPC does not encompass the realm of security domains that any mature CSP should cover, conforming to well-known standards like ISO 27001. At the same time, though, SOC 2 and SOC 3 reports can provide organizations with some insight into a cloud provider’s security.
However, most providers – at the moment -- do not seem eager to embrace the SOC 2 and SOC 3 reports. Procuring the SSAE 16 SOC 1 report is simpler and less expensive, and some CSPs are unlikely to voluntarily seek SOC 2 and/or SOC 3 reports unless pushed by customers. For this reason, it’s important that security teams educate the business unit management within their organizations about the differences between SOC 3 certified CSPs and those with only the SSAE 16 SOC 1 report. As these standards are still fairly new, SOC 2 and SOC 3 reports are still in the minority, and hopefully we’ll see this changing soon.
About the author:
Dave Shackleford is owner and principal consultant at Voodoo Security, senior vice president of research and CTO at IANS, and a SANS analyst, instructor, and course author. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. He is a VMware vExpert and has extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft, CTO for the Center for Internet Security, and as a security architect, analyst, and manager for several Fortune 500 companies. Dave is the co-author of Hands-On Information Security from Course Technology as well as the "Managing Incident Response" chapter in the Course Technology book Readings and Cases in the Management of Information Security. Recently, Dave co-authored the first published course on virtualization security for the SANS Institute. Dave currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance.
Cloud consumers interested in getting a glimpse into the state of a cloud service provider’s internal security controls are likely familiar with the Statement on Auditing Standards No. 70 report, usually called SAS 70. This report served as an independent audit statement of an organization’s internal controls (financial and infrastructure-related). In 2011, however, the SAS 70 was retired in favor of the American Institute of Certified Public Accountants (AICPA) Statement on Standards for Attestation Engagements (SSAE) number 16 (SSAE 16).
While many CSPs touted their SAS 70 reports, many in the security community criticized theSAS 70, as the controls being audited were self-defined by the cloud service provider (CSP). What’s changed with the SSAE 16? Is it a better tool for evaluating CSP security?
SSAE 16 and SOC reports
The first key to understanding the new SSAE 16 standard is to recognize the various types of reports available. The SSAE 16 is very similar to the SAS 70, with the primary difference being the requirement for a written assertion by management that the controls included and audited are accurate and functioning properly. The SSAE 16 also aligns somewhat better with other international auditing standards. When a CSP is audited for SSAE 16 standards, the auditor will provide a Service Organization Control (SOC) 1 report at the culmination of the audit. This SOC 1 report can be a Type 1 or a Type 2 (much like SAS 70). Type 1 represents an attestation of controls efficacy and accuracy at a given point in time, while a Type 2 attests to the same over a period of time, usually six months or one year.
Unfortunately, the SSAE 16 SOC 1 report suffers from the same fundamental problem that the SAS 70 had before it: the controls are self-defined. Most security and risk management professionals would prefer to see more “best practices” standardization in independent audit reports for CSPs. Fortunately, there are two other types of SOC reports.
SOC 2 and SOC 3 reports are aligned with the AICPA Trust Services Principles and Criteria (TSPC). These principles are focused on five areas:
• Security: Unauthorized access to systems (both physical and logical) is prevented through controls.
• Confidentiality: Sensitive information labeled as confidential is protected with adequate controls (customer data and systems would likely fall into this category).
• Privacy: Personal information is collected and managed in accordance with the AICPA Generally Accepted Privacy Principles.
• Availability: Systems are designed with uptime and availability in mind, and continuity of system operations is maintained.
• Processing Integrity: All system processing activities are accurate, authorized, complete and authorized.
SOC 2 reports can also come in Type 1 and Type 2 variants. Most security professionals are pleased to see the evolution of the SOC 2, and view it as a more robust controls audit and attestation report for CSPs. SOC 2 is intended for internal consumption, with detailed technical information and sensitive audit data.
SOC 3 reports attest to the same standards as a SOC 2, but are issued with public consumption in mind. They’re much more general in nature and don’t reveal potentially dangerous technical security details that an attacker could leverage. The SOC 3 also has one very compelling advantage: It’s associated with a certification that CSPs can display for customers and prospects. This certification, known as the “SOC 3: SysTrust for Service Organizations” seal, is a big step in the right direction since security teams will know immediately that a CSP has conformed to the TSPC guidelines.
Not enough security details
Still, the TSPC guidelines go into nowhere enough detail for most security professionals. Compared to the Cloud Security Alliance (CSA) Cloud Controls Matrix and Consensus Assessments Initiative Questionnaire (CAIQ), the level of concrete security guidance and rigorous security controls is not there yet. Additionally, the TSPC does not encompass the realm of security domains that any mature CSP should cover, conforming to well-known standards like ISO 27001. At the same time, though, SOC 2 and SOC 3 reports can provide organizations with some insight into a cloud provider’s security.
However, most providers – at the moment -- do not seem eager to embrace the SOC 2 and SOC 3 reports. Procuring the SSAE 16 SOC 1 report is simpler and less expensive, and some CSPs are unlikely to voluntarily seek SOC 2 and/or SOC 3 reports unless pushed by customers. For this reason, it’s important that security teams educate the business unit management within their organizations about the differences between SOC 3 certified CSPs and those with only the SSAE 16 SOC 1 report. As these standards are still fairly new, SOC 2 and SOC 3 reports are still in the minority, and hopefully we’ll see this changing soon.
About the author:
Dave Shackleford is owner and principal consultant at Voodoo Security, senior vice president of research and CTO at IANS, and a SANS analyst, instructor, and course author. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. He is a VMware vExpert and has extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft, CTO for the Center for Internet Security, and as a security architect, analyst, and manager for several Fortune 500 companies. Dave is the co-author of Hands-On Information Security from Course Technology as well as the "Managing Incident Response" chapter in the Course Technology book Readings and Cases in the Management of Information Security. Recently, Dave co-authored the first published course on virtualization security for the SANS Institute. Dave currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance.
IRS faces surge in identity theft tax fraud
IRS faces surge in identity theft tax fraud
The Internal Revenue Service is grappling with a surge in identity theft-based tax fraud as scamsters take advantage of web-based resources including electronic filing.
Identity theft cases, in which criminals obtain living or deceased people’s names and Social Security numbers to defraud the government, ranked No. 1 on an annual “Dirty Dozen” list of tax scams the agency released Thursday. The IRS called ID theft one of the most complex threats it handles.
The IRS estimates 404,000 people were victimized by identity theft tax fraud from mid-2009 to the end of 2011.
“We are seeing growth in this area. There’s no way around it,” said Terry Lemons, IRS director of communications. “But I also think that we’ve gotten better at detecting it.”
The IRS said it stopped nearly 262,000 fake returns based on identity theft from being processed in 2011, preventing nearly $1.5 billion in refunds from going to criminals. That is more than a fivefold increase from 2010, when the agency stopped about 49,000 fake returns seeking $247 million in fraudulent refunds.
The IRS said it has no way of knowing how much in fraudulent refunds made it through the system undetected.
Experts say this type of fraud has increased thanks in part to the Internet. The Web has made it easier for honest people to file their tax returns -- and for crooks to file fake returns electronically. The IRS has been on a major push to encourage people to file electronically.
“That was probably one of the biggest boons for the bad guys,” said Jay Foley, a partner with ID Theft Info Source and an identity theft expert.
With more than 100 million income tax refunds to process each year, the IRS concedes it will never be able to quell such tax fraud completely.
“The IRS cannot stop all identity theft. However, we are committed to continuing to improve our programs,” Steven T. Miller, the deputy commissioner for services and enforcement at the IRS, said in written congressional testimony in November.
The agency has added new filters to screen for potential identity theft tax fraud and is working harder to help victims get their rightful refunds.
In late January, the IRS and Justice Department announced a nationwide sweep of arrests, indictments and other actions against 105 suspected perpetrators of the crime in 23 states.
In its testimony to Congress, the IRS said it had initiated 276 investigations into identify theft tax fraud in fiscal 2011, up from 224 the previous year.
The IRS is under tremendous pressure to get taxpayers their refunds as quickly as possible while also accurately screening for fakes. That’s complex because people's lives are complicated. Many of the things that might flag a return as fraudulent -- such as a change in job, mailing address or name -- are legitimate.
The new IRS filters mean that more people’s tax refunds will get extra screening before they go out, Lemons said.
“I think for the vast majority of taxpayers, they’re not going to see any difference,” he said. “There will be some people who end up having some delays.”
ID theft tax fraud tends to occur early in the tax season as criminals try to file before legitimate taxpayers. (For tips on how to prevent and identify identity-based tax fraud, check the guide posted on the IRS website.)
Despite the agency's efforts, Foley, the identity theft expert, expects the problem to get worse before it gets better. That’s because criminals keep finding new ways to evade IRS systems.
Still, he thinks the IRS is doing the best it can given its limitations. People want their legitimate tax refunds as fast as possible, but if the IRS doesn’t catch the fraud before the refund goes out, the agency may not even realize fraud has occurred until long after, when the real taxpayer goes to file a return.
“You can’t fix something until you know something is broke,” he said.
The crime appears to have surged in popularity rapidly.
In Florida, NBC television affiliate WFLA and The Tampa Tribune reported identity theft tax fraud had became so widespread that some people were offering classes in how to commit the crime.
The station's investigation said the criminals dubbed the process “TurboTax” after the popular online software for filing returns.
Julie Miller, a spokeswoman for TurboTax’s parent company, Intuit, said in an email that the company had amped up its own fraud prevention efforts over the past year. She declined to give details for fear of tipping off criminals.
In many cases, the fraud begins when a criminal steals someone's name and Social Security number, and then uses them as a basis to create fake a return that ensures a hefty refund. The refund is sent to an address specified by the fraudster.
Another method involves getting the names, addresses and Social Security numbers of recently deceased people from websites such as Ancestry.com, which are meant to help people find their long-lost relatives.
A spokeswoman for Ancestry.com, Heather Erickson, said the company didn’t notice anything unusual. But around December, after being alerted to the problem, the website stopped showing Social Security numbers for anyone who had died in the past 10 years.
The Internal Revenue Service is grappling with a surge in identity theft-based tax fraud as scamsters take advantage of web-based resources including electronic filing.
Identity theft cases, in which criminals obtain living or deceased people’s names and Social Security numbers to defraud the government, ranked No. 1 on an annual “Dirty Dozen” list of tax scams the agency released Thursday. The IRS called ID theft one of the most complex threats it handles.
The IRS estimates 404,000 people were victimized by identity theft tax fraud from mid-2009 to the end of 2011.
“We are seeing growth in this area. There’s no way around it,” said Terry Lemons, IRS director of communications. “But I also think that we’ve gotten better at detecting it.”
The IRS said it stopped nearly 262,000 fake returns based on identity theft from being processed in 2011, preventing nearly $1.5 billion in refunds from going to criminals. That is more than a fivefold increase from 2010, when the agency stopped about 49,000 fake returns seeking $247 million in fraudulent refunds.
The IRS said it has no way of knowing how much in fraudulent refunds made it through the system undetected.
Experts say this type of fraud has increased thanks in part to the Internet. The Web has made it easier for honest people to file their tax returns -- and for crooks to file fake returns electronically. The IRS has been on a major push to encourage people to file electronically.
“That was probably one of the biggest boons for the bad guys,” said Jay Foley, a partner with ID Theft Info Source and an identity theft expert.
With more than 100 million income tax refunds to process each year, the IRS concedes it will never be able to quell such tax fraud completely.
“The IRS cannot stop all identity theft. However, we are committed to continuing to improve our programs,” Steven T. Miller, the deputy commissioner for services and enforcement at the IRS, said in written congressional testimony in November.
The agency has added new filters to screen for potential identity theft tax fraud and is working harder to help victims get their rightful refunds.
In late January, the IRS and Justice Department announced a nationwide sweep of arrests, indictments and other actions against 105 suspected perpetrators of the crime in 23 states.
In its testimony to Congress, the IRS said it had initiated 276 investigations into identify theft tax fraud in fiscal 2011, up from 224 the previous year.
The IRS is under tremendous pressure to get taxpayers their refunds as quickly as possible while also accurately screening for fakes. That’s complex because people's lives are complicated. Many of the things that might flag a return as fraudulent -- such as a change in job, mailing address or name -- are legitimate.
The new IRS filters mean that more people’s tax refunds will get extra screening before they go out, Lemons said.
“I think for the vast majority of taxpayers, they’re not going to see any difference,” he said. “There will be some people who end up having some delays.”
ID theft tax fraud tends to occur early in the tax season as criminals try to file before legitimate taxpayers. (For tips on how to prevent and identify identity-based tax fraud, check the guide posted on the IRS website.)
Despite the agency's efforts, Foley, the identity theft expert, expects the problem to get worse before it gets better. That’s because criminals keep finding new ways to evade IRS systems.
Still, he thinks the IRS is doing the best it can given its limitations. People want their legitimate tax refunds as fast as possible, but if the IRS doesn’t catch the fraud before the refund goes out, the agency may not even realize fraud has occurred until long after, when the real taxpayer goes to file a return.
“You can’t fix something until you know something is broke,” he said.
The crime appears to have surged in popularity rapidly.
In Florida, NBC television affiliate WFLA and The Tampa Tribune reported identity theft tax fraud had became so widespread that some people were offering classes in how to commit the crime.
The station's investigation said the criminals dubbed the process “TurboTax” after the popular online software for filing returns.
Julie Miller, a spokeswoman for TurboTax’s parent company, Intuit, said in an email that the company had amped up its own fraud prevention efforts over the past year. She declined to give details for fear of tipping off criminals.
In many cases, the fraud begins when a criminal steals someone's name and Social Security number, and then uses them as a basis to create fake a return that ensures a hefty refund. The refund is sent to an address specified by the fraudster.
Another method involves getting the names, addresses and Social Security numbers of recently deceased people from websites such as Ancestry.com, which are meant to help people find their long-lost relatives.
A spokeswoman for Ancestry.com, Heather Erickson, said the company didn’t notice anything unusual. But around December, after being alerted to the problem, the website stopped showing Social Security numbers for anyone who had died in the past 10 years.
Vulnerabilities in Public Key Infrastructure
Vulnerabilities in Public Key Infrastructure
The current public key infrastructure used to secure HTTPS has security shortcomings that--in some cases--could be exploited by attackers to steal data and attack servers.
That finding comes from a paper due to be presented at the Crypto 2012 conference in August in Santa Barbara, Calif. The paper was written by a team of European and American mathematicians and cryptographers, led by Dutch mathematician Arjen K. Lenstra at the Ecole Polytechnique Federale de Lausanne (EPFL) in Switzerland. The researchers published their paper early, given the severity of the vulnerabilities they discovered.
"We performed a sanity check of public keys collected on the Web," wrote the researchers in their report. "Our main goal was to test the validity of the assumption that different random choices are made each time keys are generated. We found that the vast majority of public keys work as intended."
But the researchers also discovered that public key encryption using the widely used RSA 1,024-bit algorithm is only 99.8% secure, at best, meaning that at least two out of every 1,000 public keys can be easily cracked.
"We were surprised...by the extent to which public keys are shared among unrelated parties," said the researchers. "What surprised us most is that many thousands of 1,024-bit RSA moduli, including thousands that are contained in still valid X.509 certificates, offer no security at all." Such X.509 certificates are used by certificate authorities to validate website identities, thus helping to secure everything from emails to online banking transactions.
"This comes as an unwelcome warning that underscores the difficulty of key generation in the real world," James P. Hughes, an independent Silicon Valley cryptanalyst who worked with the team, told the New York Times.
For their research, the EPFL team used data from multiple sources, including the Electronic Frontier Foundation (EFF) SSL Observatory project, which stores downloads of all publicly-visible SSL certificates on the Internet, to allow researchers to search for HTTPS vulnerabilities.
What accounts for the unexpected repetition or sharing of keys that the researchers spotted? When an RSA key is generated, it requires picking two random prime numbers that haven't been previously selected by anyone else using an RSA key. Anyone who uses the key will know these numbers, and use them--together with a public key created by the two prime numbers--to encrypt data.
To ensure that these two prime numbers don't get picked more than once, NIST recommends that anyone generating an RSA key "use a random seed of bit-length twice the intended security level," noted the researchers. "Clearly, this recommendation is not always followed."
These vulnerable keys pose serious risks to Internet security, because anyone able to identify the two prime numbers used to generate an RSA key could then bypass that key's protections. "In all cases, a weak key would allow an eavesdropper on the network to learn confidential information, such as passwords or the content of messages, exchanged with a vulnerable server," said the EFF's Dan Auerbach, a staff technologist, and Peter Eckersley, technology projects director, in a blog post. Furthermore, they said that in some cases, "sophisticated attackers could extract passwords and data from stored copies of previous encrypted sessions," or launch man-in-the-middle attacks "to inject malicious data into encrypted sessions."
The EFF said it will be working with the EPFL team to warn operators of any servers affected by the vulnerability. But the EPFL researchers have cautioned that their findings might have already been known to others. "The lack of sophistication of our methods and findings make it hard for us to believe that what we have presented is new, in particular to agencies and parties that are known for their curiosity in such matters," said the researchers. They said that their findings might also help to explain why NIST in 1991 bypassed RSA, and instead picked Digital Signature Algorithm (DSA) as its digital signature standard. Notably, DSA only requires selecting a single prime number, and the researchers found only a few cases in which two people had apparently selected the same prime number.
The current public key infrastructure used to secure HTTPS has security shortcomings that--in some cases--could be exploited by attackers to steal data and attack servers.
That finding comes from a paper due to be presented at the Crypto 2012 conference in August in Santa Barbara, Calif. The paper was written by a team of European and American mathematicians and cryptographers, led by Dutch mathematician Arjen K. Lenstra at the Ecole Polytechnique Federale de Lausanne (EPFL) in Switzerland. The researchers published their paper early, given the severity of the vulnerabilities they discovered.
"We performed a sanity check of public keys collected on the Web," wrote the researchers in their report. "Our main goal was to test the validity of the assumption that different random choices are made each time keys are generated. We found that the vast majority of public keys work as intended."
But the researchers also discovered that public key encryption using the widely used RSA 1,024-bit algorithm is only 99.8% secure, at best, meaning that at least two out of every 1,000 public keys can be easily cracked.
"We were surprised...by the extent to which public keys are shared among unrelated parties," said the researchers. "What surprised us most is that many thousands of 1,024-bit RSA moduli, including thousands that are contained in still valid X.509 certificates, offer no security at all." Such X.509 certificates are used by certificate authorities to validate website identities, thus helping to secure everything from emails to online banking transactions.
"This comes as an unwelcome warning that underscores the difficulty of key generation in the real world," James P. Hughes, an independent Silicon Valley cryptanalyst who worked with the team, told the New York Times.
For their research, the EPFL team used data from multiple sources, including the Electronic Frontier Foundation (EFF) SSL Observatory project, which stores downloads of all publicly-visible SSL certificates on the Internet, to allow researchers to search for HTTPS vulnerabilities.
What accounts for the unexpected repetition or sharing of keys that the researchers spotted? When an RSA key is generated, it requires picking two random prime numbers that haven't been previously selected by anyone else using an RSA key. Anyone who uses the key will know these numbers, and use them--together with a public key created by the two prime numbers--to encrypt data.
To ensure that these two prime numbers don't get picked more than once, NIST recommends that anyone generating an RSA key "use a random seed of bit-length twice the intended security level," noted the researchers. "Clearly, this recommendation is not always followed."
These vulnerable keys pose serious risks to Internet security, because anyone able to identify the two prime numbers used to generate an RSA key could then bypass that key's protections. "In all cases, a weak key would allow an eavesdropper on the network to learn confidential information, such as passwords or the content of messages, exchanged with a vulnerable server," said the EFF's Dan Auerbach, a staff technologist, and Peter Eckersley, technology projects director, in a blog post. Furthermore, they said that in some cases, "sophisticated attackers could extract passwords and data from stored copies of previous encrypted sessions," or launch man-in-the-middle attacks "to inject malicious data into encrypted sessions."
The EFF said it will be working with the EPFL team to warn operators of any servers affected by the vulnerability. But the EPFL researchers have cautioned that their findings might have already been known to others. "The lack of sophistication of our methods and findings make it hard for us to believe that what we have presented is new, in particular to agencies and parties that are known for their curiosity in such matters," said the researchers. They said that their findings might also help to explain why NIST in 1991 bypassed RSA, and instead picked Digital Signature Algorithm (DSA) as its digital signature standard. Notably, DSA only requires selecting a single prime number, and the researchers found only a few cases in which two people had apparently selected the same prime number.
Mobile Device Threats
Mobile Device Threats
The rapid proliferation of smartphones and tablet computers is exposing corporate networks and information to unprecedented risk, and organisations worldwide should expedite efforts to shore up their cybersecurity systems.
That’s the message of four recent reports from large accounting firms.
PricewaterhouseCoopers’ “Managing Security in a Mobile World,” warns that businesses face a triple threat of elevated risk in terms of mobile security.
1. Citing a Citrix report showing 28% of the workforce using non-organisation-issued computing devices for work, a number that’s expected to rise to 35% in 2013, PwC asserts that it’s becoming increasingly difficult for IT departments to establish security controls at all access points to the network. This raises the risks of network breaches and data leaks.
2. Adding to the risk, mobile devices often have limited storage for consumers trying to handle personal and business affairs on one smartphone or tablet. Those consumers increasingly are turning to storage based in the public cloud, which is convenient but beyond the reach of IT’s control. Using public cloud storage also raises concerns about data security, ownership and leakage.
3. Also raising risk is the increasing use of mobile devices to access social networking sites such as Facebook, Twitter and LinkedIn, which PwC says give hackers a uniquely effective position to dupe people into clicking malware-infected links from “friends” or to perhaps gain access to inadvertently shared corporate information
The PwC report recommends that businesses establish a multi-step process to create security policies that address the threats to regulated information, such as confidential client data, and intellectual property, such as trade secrets, patents and other proprietary material. Organisations need to determine which mobile devices will be allowed to access the network and establish connection policies. In addition, standards should be set for what types of corporate data can be stored on mobile devices, and IT must determine the types of encryption and authentication procedures that can be implemented to help protect the data, the report says.
IT departments also need to develop standards for cloud and social networking services. At the least, IT should ensure that cloud and data service providers meet the organisation’s security requirements.
Most important, the PwC report says, organisations need to educate employees on new data security practices and takes steps to ensure compliance. Employee failure to follow security guidelines is the biggest weakness in mobile security.
Other recent reports also highlighted security risks:
• Deloitte warns that cyberattacks on high-profile businesses already are on the rise, citing studies by the Ponemon Institute, antivirus software provider Symantec and the Digital Forensics Association that show a 44% increase in successful cyber-attacks, a four-fold jump in targeted cyberattacks from January 2011 to November 2011 and a data breach rate of 395,362 records a day in 28 countries surveyed. The Deloitte white paper, part of its Risk Intelligence Series, outlines a multi-step approach to assessing cyber-security risks, implementing processes for minimising those risks and multi-pronged strategies to address issues such as how organisations can control which software applications are running on mobile devices that can connect to the network. When IT can’t control which applications employees download onto mobile devices that have network access, the threat increases of a virus, worm or other malware infecting the network.
• Ernst & Young, in a report titled “Privacy Trends 2012: The Case for Growing Accountability,” also points to the security risks posed by mobile devices. The report recommends policy adjustments and awareness programmes but warns of possible privacy issues arising from the use of certain tracking and monitoring tools.
• Grant Thornton, in a report on the top three governance considerations for 2012, points to recent SEC guidance requiring companies to disclose any cybersecurity breaches and also to report material risks related to cybersecurity. The report recommends that organisations of all types make cybersecurity a top priority and conduct an IT internal audit, risk assessment and a security test.
The reports echo the 2011 findings of the AICPA’s 2011 Top Technology Initiatives Survey. CPAs and financial executives participating in the survey rated the proliferation of smartphones, tablet computers and mobile devices in the workplace as their top business technology concern. Mobile devices edged out information security, which had topped the list of tech concerns several years in a row.
The rapid proliferation of smartphones and tablet computers is exposing corporate networks and information to unprecedented risk, and organisations worldwide should expedite efforts to shore up their cybersecurity systems.
That’s the message of four recent reports from large accounting firms.
PricewaterhouseCoopers’ “Managing Security in a Mobile World,” warns that businesses face a triple threat of elevated risk in terms of mobile security.
1. Citing a Citrix report showing 28% of the workforce using non-organisation-issued computing devices for work, a number that’s expected to rise to 35% in 2013, PwC asserts that it’s becoming increasingly difficult for IT departments to establish security controls at all access points to the network. This raises the risks of network breaches and data leaks.
2. Adding to the risk, mobile devices often have limited storage for consumers trying to handle personal and business affairs on one smartphone or tablet. Those consumers increasingly are turning to storage based in the public cloud, which is convenient but beyond the reach of IT’s control. Using public cloud storage also raises concerns about data security, ownership and leakage.
3. Also raising risk is the increasing use of mobile devices to access social networking sites such as Facebook, Twitter and LinkedIn, which PwC says give hackers a uniquely effective position to dupe people into clicking malware-infected links from “friends” or to perhaps gain access to inadvertently shared corporate information
The PwC report recommends that businesses establish a multi-step process to create security policies that address the threats to regulated information, such as confidential client data, and intellectual property, such as trade secrets, patents and other proprietary material. Organisations need to determine which mobile devices will be allowed to access the network and establish connection policies. In addition, standards should be set for what types of corporate data can be stored on mobile devices, and IT must determine the types of encryption and authentication procedures that can be implemented to help protect the data, the report says.
IT departments also need to develop standards for cloud and social networking services. At the least, IT should ensure that cloud and data service providers meet the organisation’s security requirements.
Most important, the PwC report says, organisations need to educate employees on new data security practices and takes steps to ensure compliance. Employee failure to follow security guidelines is the biggest weakness in mobile security.
Other recent reports also highlighted security risks:
• Deloitte warns that cyberattacks on high-profile businesses already are on the rise, citing studies by the Ponemon Institute, antivirus software provider Symantec and the Digital Forensics Association that show a 44% increase in successful cyber-attacks, a four-fold jump in targeted cyberattacks from January 2011 to November 2011 and a data breach rate of 395,362 records a day in 28 countries surveyed. The Deloitte white paper, part of its Risk Intelligence Series, outlines a multi-step approach to assessing cyber-security risks, implementing processes for minimising those risks and multi-pronged strategies to address issues such as how organisations can control which software applications are running on mobile devices that can connect to the network. When IT can’t control which applications employees download onto mobile devices that have network access, the threat increases of a virus, worm or other malware infecting the network.
• Ernst & Young, in a report titled “Privacy Trends 2012: The Case for Growing Accountability,” also points to the security risks posed by mobile devices. The report recommends policy adjustments and awareness programmes but warns of possible privacy issues arising from the use of certain tracking and monitoring tools.
• Grant Thornton, in a report on the top three governance considerations for 2012, points to recent SEC guidance requiring companies to disclose any cybersecurity breaches and also to report material risks related to cybersecurity. The report recommends that organisations of all types make cybersecurity a top priority and conduct an IT internal audit, risk assessment and a security test.
The reports echo the 2011 findings of the AICPA’s 2011 Top Technology Initiatives Survey. CPAs and financial executives participating in the survey rated the proliferation of smartphones, tablet computers and mobile devices in the workplace as their top business technology concern. Mobile devices edged out information security, which had topped the list of tech concerns several years in a row.
Teenager Sentenced for Card Skimming
Teenager Sentenced for Card Skimming
Insider Scams a Growing Trend, Experts Say
Tracy Kitten
January 11, 2012
A 17-year-old was slapped with a 60-day jail sentence after he was busted for skimming credit and debit details while working the drive-thru window at a McDonald's restaurant in Olympia, Wash. This insider scam highlights a card fraud trend the industry needs to watch, experts say
Card-skimming expert and fraud consultant Jerry Silva says the case highlights just how easy it is for insiders to perpetrate card fraud, especially in a retail environment.
"It truly is remarkable," Silva says. "Even if we protect the ATMs and POS devices, insider fraud like this will take place due to the ease with which criminals can get their hands on the appropriate devices. This is an industry that clearly needs an elegant and innovative solution (not EMV) that can at least make it an order of magnitude harder for skimmers to succeed."
Silva argues that the problem "isn't big enough at top tier-banks to warrant any kind of financial disclosure, much less a preventive response. They just write it off as the cost of doing business."
Transactions Monitored
In the McDonald's incident, the teen's card-fraud scheme was foiled before exceeding $13,000 in losses after transaction monitoring traced the fraud. Detectives connected the dots and linked fraud to the Olympia McDonald's when contacted by the Washington State Employees Credit Union about fraudulent transactions hitting member accounts. The credit union found one commonality: All of the compromised cards had been used at the same McDonald's. McDonald's management later confirmed the juvenile suspect had worked the drive-thru every time one of the compromised cards had been used.
The teenager used the stolen card numbers, which he collected with a handheld skimming device, to buy gift cards at retail stores such as Walmart and Toys R Us, according to a news report. With the fraudulently purchased gift cards, he allegedly bought about $13,000 worth of merchandise that he later sold on Craigslist and eBay for profit.
The purchases the teenager made included iPads, computers, video game systems and digital cameras, according to the Thurston County Prosecuting Attorney's Office.
The teen has been in custody since Nov. 16, after his parents refused to post bail. On Monday, he pleaded guilty to two juvenile counts of forgery and two juvenile counts of identity theft. As part of his sentence, the court has asked that he pay restitution to the victims whose cards were compromised.
The investigation is ongoing because other suspects may be involved.
Insider Scams a Growing Trend, Experts Say
Tracy Kitten
January 11, 2012
A 17-year-old was slapped with a 60-day jail sentence after he was busted for skimming credit and debit details while working the drive-thru window at a McDonald's restaurant in Olympia, Wash. This insider scam highlights a card fraud trend the industry needs to watch, experts say
Card-skimming expert and fraud consultant Jerry Silva says the case highlights just how easy it is for insiders to perpetrate card fraud, especially in a retail environment.
"It truly is remarkable," Silva says. "Even if we protect the ATMs and POS devices, insider fraud like this will take place due to the ease with which criminals can get their hands on the appropriate devices. This is an industry that clearly needs an elegant and innovative solution (not EMV) that can at least make it an order of magnitude harder for skimmers to succeed."
Silva argues that the problem "isn't big enough at top tier-banks to warrant any kind of financial disclosure, much less a preventive response. They just write it off as the cost of doing business."
Transactions Monitored
In the McDonald's incident, the teen's card-fraud scheme was foiled before exceeding $13,000 in losses after transaction monitoring traced the fraud. Detectives connected the dots and linked fraud to the Olympia McDonald's when contacted by the Washington State Employees Credit Union about fraudulent transactions hitting member accounts. The credit union found one commonality: All of the compromised cards had been used at the same McDonald's. McDonald's management later confirmed the juvenile suspect had worked the drive-thru every time one of the compromised cards had been used.
The teenager used the stolen card numbers, which he collected with a handheld skimming device, to buy gift cards at retail stores such as Walmart and Toys R Us, according to a news report. With the fraudulently purchased gift cards, he allegedly bought about $13,000 worth of merchandise that he later sold on Craigslist and eBay for profit.
The purchases the teenager made included iPads, computers, video game systems and digital cameras, according to the Thurston County Prosecuting Attorney's Office.
The teen has been in custody since Nov. 16, after his parents refused to post bail. On Monday, he pleaded guilty to two juvenile counts of forgery and two juvenile counts of identity theft. As part of his sentence, the court has asked that he pay restitution to the victims whose cards were compromised.
The investigation is ongoing because other suspects may be involved.
Feds: Cyber Criminals Hijacked 4 Million Computers
Feds: Cyber Criminals Hijacked 4 Million Computers
An Eastern European pack of cyber thieves known as the Rovegroup hijacked at least four million computers in over 100 countries, including at least half a million computers in the U.S., to make off with $14 million in "illegitimate income" before they were caught, federal officials announced today.
The malware allegedly used in the "massive and sophisticated scheme" also managed to infect computers in U.S. government agencies including NASA and targeted the websites for major institutions like iTunes, Netflix and the IRS -- forcing users attempting to get to those sites to different websites entirely, according to a federal indictmentunsealed in New York today.
The accused hackers, six Estonian nationals and a Russian national, rerouted the internet traffic illegally on the infected computers for the last four years in order to reap profits from internet advertisement deals, the indictment said. The FBI busted up the alleged international cyber ring after a two-year investigation called Operation Ghost Click.
"The global reach of these cyber thieves demonstrates that the criminal world is... flat," said Janice Fedarcyk, the FBI Assistant Director in charge of the New York field office. "The Internet is pervasive because it is such a useful tool, but it is a tool that can be exploited by those with bad intentions and a little know-how."
Though they operated out of their home countries, the alleged hackers used entities in the U.S. and all over the world -- including Estonia-based software company Rove Digital from which the group apparently gets its name -- to carry out the plot.
According to the indictment, the suspects entered into deals with various internet advertisers in which they would be paid for generating traffic to certain websites or advertisements. But instead of earning the money legitimately, the FBI said the defendants used malware to force infected computers to unwillingly visit the target sites or advertisements -- pumping up click results and, therefore, ill-gotten profits to the tune of $14 million.
The malware was also designed to prevent users from installing anti-virus software that may have been able to free the infected computers.
The six Estonian nationals have been arrested on cyber crime charges while the Russian national remains at large.
"Today, with the flip of a switch, the FBI and our partners dismantled the Rove criminal enterprise," Fedarcyk said. "Thanks to the collective effort across the U.S. and in Estonia, six leaders of the criminal enterprise have been arrested and numerous servers operated by the criminal organization have been disabled."
The malware allegedly used in the "massive and sophisticated scheme" also managed to infect computers in U.S. government agencies including NASA and targeted the websites for major institutions like iTunes, Netflix and the IRS -- forcing users attempting to get to those sites to different websites entirely, according to a federal indictmentunsealed in New York today.
The six Estonian nationals have been arrested on cyber crime charges while the Russian national remains at large.
How the Fraud Worked, According to the FBI
The indictment describes several examples of alleged cyber fraud including two principle strategies: traffic redirection and ad replacement.
In the first case, if a user searched for the websites of major institutions like iTunes, Netflix or the IRS, the search results would return normally. However, if the user tried to click on the link to the websites, the malware on the computer would force a redirect to a different website where the criminals would profit in their advertisement deal.
In the second, when an infected computer visited a major website -- like Amazon.com -- the malware would be able to simply replace regular advertisements on that page with advertisements of their own making.
An Eastern European pack of cyber thieves known as the Rovegroup hijacked at least four million computers in over 100 countries, including at least half a million computers in the U.S., to make off with $14 million in "illegitimate income" before they were caught, federal officials announced today.
The malware allegedly used in the "massive and sophisticated scheme" also managed to infect computers in U.S. government agencies including NASA and targeted the websites for major institutions like iTunes, Netflix and the IRS -- forcing users attempting to get to those sites to different websites entirely, according to a federal indictmentunsealed in New York today.
The accused hackers, six Estonian nationals and a Russian national, rerouted the internet traffic illegally on the infected computers for the last four years in order to reap profits from internet advertisement deals, the indictment said. The FBI busted up the alleged international cyber ring after a two-year investigation called Operation Ghost Click.
"The global reach of these cyber thieves demonstrates that the criminal world is... flat," said Janice Fedarcyk, the FBI Assistant Director in charge of the New York field office. "The Internet is pervasive because it is such a useful tool, but it is a tool that can be exploited by those with bad intentions and a little know-how."
Though they operated out of their home countries, the alleged hackers used entities in the U.S. and all over the world -- including Estonia-based software company Rove Digital from which the group apparently gets its name -- to carry out the plot.
According to the indictment, the suspects entered into deals with various internet advertisers in which they would be paid for generating traffic to certain websites or advertisements. But instead of earning the money legitimately, the FBI said the defendants used malware to force infected computers to unwillingly visit the target sites or advertisements -- pumping up click results and, therefore, ill-gotten profits to the tune of $14 million.
The malware was also designed to prevent users from installing anti-virus software that may have been able to free the infected computers.
The six Estonian nationals have been arrested on cyber crime charges while the Russian national remains at large.
"Today, with the flip of a switch, the FBI and our partners dismantled the Rove criminal enterprise," Fedarcyk said. "Thanks to the collective effort across the U.S. and in Estonia, six leaders of the criminal enterprise have been arrested and numerous servers operated by the criminal organization have been disabled."
The malware allegedly used in the "massive and sophisticated scheme" also managed to infect computers in U.S. government agencies including NASA and targeted the websites for major institutions like iTunes, Netflix and the IRS -- forcing users attempting to get to those sites to different websites entirely, according to a federal indictmentunsealed in New York today.
The six Estonian nationals have been arrested on cyber crime charges while the Russian national remains at large.
How the Fraud Worked, According to the FBI
The indictment describes several examples of alleged cyber fraud including two principle strategies: traffic redirection and ad replacement.
In the first case, if a user searched for the websites of major institutions like iTunes, Netflix or the IRS, the search results would return normally. However, if the user tried to click on the link to the websites, the malware on the computer would force a redirect to a different website where the criminals would profit in their advertisement deal.
In the second, when an infected computer visited a major website -- like Amazon.com -- the malware would be able to simply replace regular advertisements on that page with advertisements of their own making.
Wells Fargo Customer Info Exposed
Wells Fargo Customer Info Exposed
Bank Account Details Revealed in Statement Mailing Mistake
Tracy Kitten
October 24, 2011
Wells Fargo Bank says a printer malfunction is at the root of a bank statement mix-up that resulted in the exposure of account details for what could turn out to be thousands of Wells customers.
Josh Dunn, corporate communications manager for Wells Fargo in Charlotte, N.C., says customers with accounts opened in South Carolina and Florida "may have received, in error, pages from other customer accounts," though the printing malfunction only affected September statements.
The malfunctioning printer is no longer in service and is being analyzed, Wells says. The printing error is not believed to be connected to Wells Fargo & Company's [$1.4 trillion in assets] merger with Wachovia Corp., a conversion that was completed in January 2009.
"Though we believe the risk of compromising a customer's account is low, we are providing all customers whose statements were printed by the malfunctioning printer with one year's worth of free ID theft protection," Dunn says. "We don't know how many accounts were affected, but even one is one too many."
Corrected statements are being mailed to all potentially affected customers.
ID Theft: Concerns Mount
With so much attention now being paid to incidents of identity theft and the exposure of personally identifiable information, the Wells case is likely to raise more questions than answers.
ID theft, in recent weeks, has been top of mind. On Oct. 13, Georgia authorities announced the arrests of two men who are suspected of being behind an ID theft scam that lasted 15 years and resulted in fraud totaling $9 million. The Criminal Intelligence Unit of the Cherokee County Sheriff's Office in Georgia says the scheme targeted consumers throughout the U.S. [See $9 Million ID Theft Scheme Alleged.]
And earlier this month, the U.S. District Attorney's Office in Queens, N.Y., announced closure of the biggest ID theft takedown in U.S. history. [See Biggest ID Theft Bust in History.]
That scheme involved five organized crime rings with ties to Europe, Asia, Africa and the Middle East and resulted in financial losses exceeding $13 million over a 16-month period.
Phil Blank, managing director of security, risk and fraud for Javelin Strategy & Research, calls the Wells incident astonishing. "It represents a failure in basic 'block and tackling,'" he says.
The cause of what Wells has defined as a printer malfunction is concerning. A system's upgrade, such as the one Bank of America in recent weeks pointed to as the catalyst for online-banking interruptions its customers faced, could be to blame.
"It could have been some new piece of code that was introduced that obviously did not work as planned," Blank says. "Another part of me can't help but wonder if perhaps it is the result of a piece of malicious software introduced somehow into the Wells network. It could also have been as simple as human error not caught by a process check."
It will likely take weeks before causes for the printing malfunction are discovered and revealed. For now, Wells must focus on the customers it has exposed to potential fraud. "They should immediately reach out to those affected, assuming that they can figure out exactly what happened here and who was affected, and set them up with new accounts," Blank says.
Bank Account Details Revealed in Statement Mailing Mistake
Tracy Kitten
October 24, 2011
Wells Fargo Bank says a printer malfunction is at the root of a bank statement mix-up that resulted in the exposure of account details for what could turn out to be thousands of Wells customers.
Josh Dunn, corporate communications manager for Wells Fargo in Charlotte, N.C., says customers with accounts opened in South Carolina and Florida "may have received, in error, pages from other customer accounts," though the printing malfunction only affected September statements.
The malfunctioning printer is no longer in service and is being analyzed, Wells says. The printing error is not believed to be connected to Wells Fargo & Company's [$1.4 trillion in assets] merger with Wachovia Corp., a conversion that was completed in January 2009.
"Though we believe the risk of compromising a customer's account is low, we are providing all customers whose statements were printed by the malfunctioning printer with one year's worth of free ID theft protection," Dunn says. "We don't know how many accounts were affected, but even one is one too many."
Corrected statements are being mailed to all potentially affected customers.
ID Theft: Concerns Mount
With so much attention now being paid to incidents of identity theft and the exposure of personally identifiable information, the Wells case is likely to raise more questions than answers.
ID theft, in recent weeks, has been top of mind. On Oct. 13, Georgia authorities announced the arrests of two men who are suspected of being behind an ID theft scam that lasted 15 years and resulted in fraud totaling $9 million. The Criminal Intelligence Unit of the Cherokee County Sheriff's Office in Georgia says the scheme targeted consumers throughout the U.S. [See $9 Million ID Theft Scheme Alleged.]
And earlier this month, the U.S. District Attorney's Office in Queens, N.Y., announced closure of the biggest ID theft takedown in U.S. history. [See Biggest ID Theft Bust in History.]
That scheme involved five organized crime rings with ties to Europe, Asia, Africa and the Middle East and resulted in financial losses exceeding $13 million over a 16-month period.
Phil Blank, managing director of security, risk and fraud for Javelin Strategy & Research, calls the Wells incident astonishing. "It represents a failure in basic 'block and tackling,'" he says.
The cause of what Wells has defined as a printer malfunction is concerning. A system's upgrade, such as the one Bank of America in recent weeks pointed to as the catalyst for online-banking interruptions its customers faced, could be to blame.
"It could have been some new piece of code that was introduced that obviously did not work as planned," Blank says. "Another part of me can't help but wonder if perhaps it is the result of a piece of malicious software introduced somehow into the Wells network. It could also have been as simple as human error not caught by a process check."
It will likely take weeks before causes for the printing malfunction are discovered and revealed. For now, Wells must focus on the customers it has exposed to potential fraud. "They should immediately reach out to those affected, assuming that they can figure out exactly what happened here and who was affected, and set them up with new accounts," Blank says.
TRICARE Hit With $4.9 Billion Lawsuit
TRICARE Hit With $4.9 Billion Lawsuit
Damages Sought for Privacy Violations in Breach Incident
Howard Anderson
October 14, 2011
A class action lawsuit is seeking $4.9 billion in damages as a result of alleged privacy violations stemming from a recent health information breach affecting beneficiaries of the TRICARE military health program.
The breach occurred when unencrypted backup tapes were stolen from the parked car of an employee of a TRICARE business associate, Science Applications International Corp. The lawsuit does not list SAIC as a defendant. Instead it names TRICARE, the Department of Defense and Defense Secretary Leon Panetta.
A TRICARE spokesman declined to comment on the lawsuit. Earlier, TRICARE confirmed that the tapes may have included Social Security numbers, names, addresses, phone numbers and some personal health data, such as clinical notes, lab tests and prescriptions. The tapes did not contain any financial data.
The suit, filed by the law firm Shulman, Rogers, Gandal, Pordy & Ecker, seeks $1,000 in damages for each of the 4.9 million TRICARE beneficiaries who had information on the tapes, alleging violations of the Privacy Act of 1974 and the federal Administrative Procedures Act. It alleges "intentional, willful and reckless violations of the privacy rights" of the beneficiaries.
The defendants' "inexplicably failed to properly encrypt the information," the suit states. It also alleges that TRICARE "authorized an untrained or improperly trained individual to take the highly confidential information off of government premises and to leave the unencrypted information in an unguarded car parked in a public location, from which it was stolen..."
Credit Monitoring Sought
In addition to seeking $4.9 billion in damages, the lawsuit asks the court to require the defendants to offer the affected beneficiaries free credit monitoring.
When it recently announced plans to notify those affected by the breach, TRICARE noted that it did not plan to offer free credit monitoring. "Reading the tapes takes special machinery," a TRICARE statement noted. "Moreover, it takes a highly skilled individual to interpret the data on the tapes. Since we do not believe the tapes were taken with malicious intent, we believe the risk to beneficiaries is low."
The lawsuit asks the court to bar DoD and TRICARE from transferring any records subject to the Privacy Act "until an independent panel of experts finds that adequate information security has been established and implemented."
In addition, the suit asks the court to prohibit DoD and TRICARE from transporting any confidential records off government property "unless the records are fully and properly encrypted." It also asks the court to prevent the defendants from transporting confidential records "by any non-secure means, including unprotected cars." And it asks that SAIC be prohibited from accessing or transporting confidential TRICARE information until an independent panel confirms the company has taken adequate security precautions.
Damages Sought for Privacy Violations in Breach Incident
Howard Anderson
October 14, 2011
A class action lawsuit is seeking $4.9 billion in damages as a result of alleged privacy violations stemming from a recent health information breach affecting beneficiaries of the TRICARE military health program.
The breach occurred when unencrypted backup tapes were stolen from the parked car of an employee of a TRICARE business associate, Science Applications International Corp. The lawsuit does not list SAIC as a defendant. Instead it names TRICARE, the Department of Defense and Defense Secretary Leon Panetta.
A TRICARE spokesman declined to comment on the lawsuit. Earlier, TRICARE confirmed that the tapes may have included Social Security numbers, names, addresses, phone numbers and some personal health data, such as clinical notes, lab tests and prescriptions. The tapes did not contain any financial data.
The suit, filed by the law firm Shulman, Rogers, Gandal, Pordy & Ecker, seeks $1,000 in damages for each of the 4.9 million TRICARE beneficiaries who had information on the tapes, alleging violations of the Privacy Act of 1974 and the federal Administrative Procedures Act. It alleges "intentional, willful and reckless violations of the privacy rights" of the beneficiaries.
The defendants' "inexplicably failed to properly encrypt the information," the suit states. It also alleges that TRICARE "authorized an untrained or improperly trained individual to take the highly confidential information off of government premises and to leave the unencrypted information in an unguarded car parked in a public location, from which it was stolen..."
Credit Monitoring Sought
In addition to seeking $4.9 billion in damages, the lawsuit asks the court to require the defendants to offer the affected beneficiaries free credit monitoring.
When it recently announced plans to notify those affected by the breach, TRICARE noted that it did not plan to offer free credit monitoring. "Reading the tapes takes special machinery," a TRICARE statement noted. "Moreover, it takes a highly skilled individual to interpret the data on the tapes. Since we do not believe the tapes were taken with malicious intent, we believe the risk to beneficiaries is low."
The lawsuit asks the court to bar DoD and TRICARE from transferring any records subject to the Privacy Act "until an independent panel of experts finds that adequate information security has been established and implemented."
In addition, the suit asks the court to prohibit DoD and TRICARE from transporting any confidential records off government property "unless the records are fully and properly encrypted." It also asks the court to prevent the defendants from transporting confidential records "by any non-secure means, including unprotected cars." And it asks that SAIC be prohibited from accessing or transporting confidential TRICARE information until an independent panel confirms the company has taken adequate security precautions.
SEC Mandates Cyber Incident Reporting
SEC Mandates Cyber Incident Reporting
Securities and Exchange Commission issues its first guidance for how and when companies should report cybersecurity or other incidents that pose a cyber risk.
By Elizabeth Montalbano, InformationWeek
October 14, 2011
URL: http://www.informationweek.com/news/government/policy/231900861
The Securities and Exchange Commission (SEC) has issued its first official guidance for how companies should report cybersecurity incidents that could have a negative impact on operations or their financial status.
The SEC's division of corporate finance this week presented several specific criteria for the disclosure of cyber incidents, according to guidance presented on its website.
The SEC long has required companies to report any incidents that could impact their financial performance, but to date has not outlined requirements for disclosing cybersecurity or other cyber incidents in particular.
[What are government IT pros' most pressing problems? Read our original research on the Federal Government's IT Priorities.]
However, with the growing dependence on the Internet and other digital communications for business functions, companies as well as their accountants and lawyers have asked the SEC to provide a framework for disclosing cyber incidents, according to the commission.
"As a result, we determined that it would be beneficial to provide guidance that assists registrants in assessing what, if any, disclosures should be provided about cybersecurity matters in light of each registrant's specific facts and circumstances," the SEC said.
According to the SEC, companies should disclose the risk of cyber incidents if "these issues are among the most significant factors that make an investment in the company speculative or risky." Companies should consider prior cyber incidents and the severity and frequency of those incidents to determine if they need to report a cyber risk, according to the guidance.
The SEC also advises companies to take into account the actions they take to prevent and reduce risks in the context of their particular industry, as well as risks to that security. To put risks reported under these criteria in context, the SEC said a company may need to disclose "known or threatened cyber incidents."
Companies also should address cybersecurity risks in their management, discussion, and analysis (MD&A) reporting if costs or consequences of a known risk will have a material impact on the company, according to the SEC.
Moreover, cyber incidents that could materially affect products, services, relationships with customers or suppliers, or competitive conditions also should be reported. This should be done in a company's "description of business" reporting, according to the SEC.
Cybersecurity incidents also may need to be reported on a company's financial statements, "depending on the nature and severity of the potential or actual incident," the commission said.
Securities and Exchange Commission issues its first guidance for how and when companies should report cybersecurity or other incidents that pose a cyber risk.
By Elizabeth Montalbano, InformationWeek
October 14, 2011
URL: http://www.informationweek.com/news/government/policy/231900861
The Securities and Exchange Commission (SEC) has issued its first official guidance for how companies should report cybersecurity incidents that could have a negative impact on operations or their financial status.
The SEC's division of corporate finance this week presented several specific criteria for the disclosure of cyber incidents, according to guidance presented on its website.
The SEC long has required companies to report any incidents that could impact their financial performance, but to date has not outlined requirements for disclosing cybersecurity or other cyber incidents in particular.
[What are government IT pros' most pressing problems? Read our original research on the Federal Government's IT Priorities.]
However, with the growing dependence on the Internet and other digital communications for business functions, companies as well as their accountants and lawyers have asked the SEC to provide a framework for disclosing cyber incidents, according to the commission.
"As a result, we determined that it would be beneficial to provide guidance that assists registrants in assessing what, if any, disclosures should be provided about cybersecurity matters in light of each registrant's specific facts and circumstances," the SEC said.
According to the SEC, companies should disclose the risk of cyber incidents if "these issues are among the most significant factors that make an investment in the company speculative or risky." Companies should consider prior cyber incidents and the severity and frequency of those incidents to determine if they need to report a cyber risk, according to the guidance.
The SEC also advises companies to take into account the actions they take to prevent and reduce risks in the context of their particular industry, as well as risks to that security. To put risks reported under these criteria in context, the SEC said a company may need to disclose "known or threatened cyber incidents."
Companies also should address cybersecurity risks in their management, discussion, and analysis (MD&A) reporting if costs or consequences of a known risk will have a material impact on the company, according to the SEC.
Moreover, cyber incidents that could materially affect products, services, relationships with customers or suppliers, or competitive conditions also should be reported. This should be done in a company's "description of business" reporting, according to the SEC.
Cybersecurity incidents also may need to be reported on a company's financial statements, "depending on the nature and severity of the potential or actual incident," the commission said.
Akamai employee tried to sell secrets to Israel
Akamai employee tried to sell secrets to Israel
A staffer in the finance department tried to sell client information, contracts and even an employee list
Robert McMillan
August 30, 2011 (IDG News Service)
A 43-year-old former Akamai employee has pleaded guilty to espionage charges after offering to hand over confidential information about the Web acceleration company to an agent posing as an Israeli consular official in Boston.
Starting in September 2007, Elliot Doxer played an elaborate 18-month-long game of cloak-and-dagger with James Cromer, a man he thought was an Israeli intelligence officer. He handed over pages and pages of confidential data to Cromer, providing a list of Akamai's clients and contracts, information about the company's security practices, and even a list of 1,300 Akamai employees, including mobile numbers, departments and e-mail addresses.
Doxer delivered the information to a dead drop box, a predetermined location set up by Cromer where both of them could drop off documents for each other without actually meeting.
His motivation was to help Israel and to get information on his son and estranged wife, who lived outside the U.S., prosecutors said in court filings.
Unbeknownst to Doxer, his Israeli spy was actually a special agent with the counterintelligence squad at the U.S. Federal Bureau of Investigation's Pittsburgh field office. In October 2010, Doxer was arrested and charged with committing foreign economic espionage. He pleaded guilty on Tuesday, becoming only the eighth person ever to be prosecuted in the U.S. for trying to sell corporate secrets to foreign governments.
According to Akamai, there's no evidence that Doxer ever managed to sell his secrets to anyone other than federal agents. Doxer's lawyer didn't immediately respond to messages seeking comment Tuesday.
Doxer worked in the finance department at Akamai's Boston headquarters. Apparently out of the blue, he decided to send an e-mail to Israel's Boston consulate on June 22, 2006, writing, "I am a jewish american who lives in Boston. I know you are always looking for information and i am offering the little i may have."
When Cromer contacted him a few years later, Doxer quickly began delivering information. He visited the dead drop box 62 times in the next 18 months, authorities said. He asked for $3,000 for the data.
He also asked for information about his son, and he made this rather ominous comment about his estranged wife: "His mother is a terrible human being and has caused me tremendous suffering. Not enough bad things can happen to her if you know what I mean."
Doxer faces 15 years in prison on the charges.
A staffer in the finance department tried to sell client information, contracts and even an employee list
Robert McMillan
August 30, 2011 (IDG News Service)
A 43-year-old former Akamai employee has pleaded guilty to espionage charges after offering to hand over confidential information about the Web acceleration company to an agent posing as an Israeli consular official in Boston.
Starting in September 2007, Elliot Doxer played an elaborate 18-month-long game of cloak-and-dagger with James Cromer, a man he thought was an Israeli intelligence officer. He handed over pages and pages of confidential data to Cromer, providing a list of Akamai's clients and contracts, information about the company's security practices, and even a list of 1,300 Akamai employees, including mobile numbers, departments and e-mail addresses.
Doxer delivered the information to a dead drop box, a predetermined location set up by Cromer where both of them could drop off documents for each other without actually meeting.
His motivation was to help Israel and to get information on his son and estranged wife, who lived outside the U.S., prosecutors said in court filings.
Unbeknownst to Doxer, his Israeli spy was actually a special agent with the counterintelligence squad at the U.S. Federal Bureau of Investigation's Pittsburgh field office. In October 2010, Doxer was arrested and charged with committing foreign economic espionage. He pleaded guilty on Tuesday, becoming only the eighth person ever to be prosecuted in the U.S. for trying to sell corporate secrets to foreign governments.
According to Akamai, there's no evidence that Doxer ever managed to sell his secrets to anyone other than federal agents. Doxer's lawyer didn't immediately respond to messages seeking comment Tuesday.
Doxer worked in the finance department at Akamai's Boston headquarters. Apparently out of the blue, he decided to send an e-mail to Israel's Boston consulate on June 22, 2006, writing, "I am a jewish american who lives in Boston. I know you are always looking for information and i am offering the little i may have."
When Cromer contacted him a few years later, Doxer quickly began delivering information. He visited the dead drop box 62 times in the next 18 months, authorities said. He asked for $3,000 for the data.
He also asked for information about his son, and he made this rather ominous comment about his estranged wife: "His mother is a terrible human being and has caused me tremendous suffering. Not enough bad things can happen to her if you know what I mean."
Doxer faces 15 years in prison on the charges.
Patient Data Landed Online After a Series of Missteps
Patient Data Landed Online After a Series of Missteps
By KEVIN SACK
Private medical data for nearly 20,000 emergency room patients at California’s prestigious Stanford Hospital were exposed to public view for nearly a year because a billing contractor’s marketing agent sent the electronic spreadsheet to a job prospect as part of a skills test, the hospital and contractors confirmed this week. The applicant then sought help by unwittingly posting the confidential data on a tutoring Web site.
In an e-mail sent to a victim of the breach, the billing contractor, Joe Anthony Reyna, president of Multi-Specialty Collection Services in Los Angeles, explained that his marketing vendor, Frank Corcino, had received the data directly from Stanford Hospital, converted it to a new spreadsheet and then forwarded it to a woman he was considering for a short-term job.
The position was with Mr. Corcino’s one-man shop, Corcino & Associates, Mr. Reyna wrote in the e-mail, which was authenticated by his lawyer, Ellyn L. Sternfield. The job applicant apparently was challenged to convert the spreadsheet — which included names, admission dates, diagnosis codes and billing charges — into a bar graph and charts, Stanford Hospital officials said.
Not knowing that she had been given real patient data, the applicant posted it as an attachment to a request for help on studentoffortune.com, which allows students to solicit paid assistance with their work. First posted on Sept. 9, 2010, the spreadsheet remained on the site until a patient discovered it on Aug. 22 and notified Stanford.
The hospital, located on the campus of Stanford University in Palo Alto, demanded that the spreadsheet be removed, and the Web site quickly complied. Pressed for time, the job prospect wound up completing the assignment herself and, in the end, did not get hired, Ms. Sternfield said.
Mr. Corcino, in his first public statement, attributed the breach to “a chain of mistakes which are far too easy to make when handling electronic data.”
When the breach was first reported by The New York Times on Sept. 8, it was not clear how the data had made it to the Web.
Breaches of private medical data have become distressingly commonplace, with two substantial ones disclosed in the last week alone.
In Orlando, officials with Florida Hospital reported that three employees had improperly combed through emergency department records of 2,252 patients, apparently to forward information about accident victims to lawyers. The employees were fired, and law enforcement officials are investigating.
Meanwhile, Science Applications International Corporation disclosed that computer backup tapes containing medical data for 4.9 million military patients had been stolen from an employee’s car in San Antonio. The data included Social Security numbers, clinical notes, laboratory test results and prescriptions. The company said the risk of harm was low because retrieving data from the tapes would require specialized knowledge, software and hardware.
The Texas breach is by far the largest since September 2009, when a new federal law began requiring disclosures of medical privacy violations involving at least 500 people. Some 330 such episodes have been tallied, including four others that affected more than one million people each.
Officials at the Department of Health and Human Services said the new reporting requirements had exposed deep vulnerabilities and encouraged renewed vigilance.
“We’re moving in the right direction in terms of a culture of compliance,” said Leon Rodriguez, director of the department’s Office for Civil Rights, which investigates medical privacy cases. “Are there still a lot of problems out there? Yeah, my sense is there are still a lot of problems.”
The Stanford breach was notable for the duration of public exposure, and for spotlighting the vulnerability created by a medical provider’s business relationships with outside parties.
Last week, lawyers filed suit in state court in Los Angeles, seeking certification as a class action and $20 million in damages from Stanford Hospital & Clinics and Multi-Specialty Collection Services, which is known as MSCS. The threat of liability set off a predictable round of finger-pointing.
In written responses to questions, Lisa Lapin, Stanford University’s assistant vice president for university communications, said, “MSCS bears the complete and sole responsibility for the breach.”
Ms. Lapin said the hospital had sent the data in encrypted form to Mr. Corcino, who requested it on behalf of MSCS to analyze a strategy for improving billing collections. She said Mr. Corcino had regularly represented himself as MSCS’s executive vice president and had been Stanford’s “primary contact” during a seven-year relationship. MSCS, a five-person firm that audits hospital accounts to maximize reimbursement, possessed the passwords to unencrypt the data, she said.
“This mishandling of private patient information was in complete contravention of the law and of the requirements of MSCS’s contract and is shockingly irresponsible,” the hospital said in a statement.
Ms. Sternfield, Mr. Reyna’s lawyer, said Mr. Corcino had never been an MSCS employee, but rather was paid a monthly fee to drum up business, typically in face-to-face meetings with health care executives. Mr. Reyna, she said, had no knowledge that the Stanford data had been sent to Mr. Corcino, or that he had passed it on.
Mr. Corcino was not authorized to use an MSCS title, Ms. Sternfield said, but she declined to say whether Mr. Reyna was aware of the practice. She acknowledged that Mr. Corcino sometimes used an MSCS e-mail account.
In his e-mail to the breach victim, who shared it with The Times, Mr. Reyna wrote that Stanford had sent the file to Mr. Corcino “for a potential MSCS project that would audit paid accounts to verify that the reimbursement was correct.”
For his part, Mr. Corcino said in a statement that he was an independent contractor but was “the marketing face of the company,” and that MSCS “allowed me to use the title of executive vice president.” He wrote: “Stanford sent the file to me at MSCS, and I imported the data into a spreadsheet that was forwarded to the job applicant as part of a skills test. I did not intend to provide any personal health information in the file. This was a marketing project.”
Without explaining how or why he sent the data to the applicant, Mr. Corcino said MSCS had not trained him properly and faulted Stanford for sending him private information that he did not need. That, he said, was the “first link in a chain of mistakes.”
“I regret that Stanford released a file containing unnecessary information,” Mr. Corcino said, “that MSCS did not have an appropriate training and audit system for the handling of electronic data and that I was not more careful with the file. While Stanford and MSCS left the information in the file I received, it was my mistake to not catch its inclusion and remove the data.”
The hospital has terminated its relationship with MSCS, and Mr. Reyna has done the same with Mr. Corcino.
Stanford Hospital has reassured affected patients that the posted spreadsheet did not contain Social Security numbers, birthdates or credit card numbers, and has offered free identity theft protection services. The hospital said it had not uncovered any misuse of the exposed data.
By KEVIN SACK
Private medical data for nearly 20,000 emergency room patients at California’s prestigious Stanford Hospital were exposed to public view for nearly a year because a billing contractor’s marketing agent sent the electronic spreadsheet to a job prospect as part of a skills test, the hospital and contractors confirmed this week. The applicant then sought help by unwittingly posting the confidential data on a tutoring Web site.
In an e-mail sent to a victim of the breach, the billing contractor, Joe Anthony Reyna, president of Multi-Specialty Collection Services in Los Angeles, explained that his marketing vendor, Frank Corcino, had received the data directly from Stanford Hospital, converted it to a new spreadsheet and then forwarded it to a woman he was considering for a short-term job.
The position was with Mr. Corcino’s one-man shop, Corcino & Associates, Mr. Reyna wrote in the e-mail, which was authenticated by his lawyer, Ellyn L. Sternfield. The job applicant apparently was challenged to convert the spreadsheet — which included names, admission dates, diagnosis codes and billing charges — into a bar graph and charts, Stanford Hospital officials said.
Not knowing that she had been given real patient data, the applicant posted it as an attachment to a request for help on studentoffortune.com, which allows students to solicit paid assistance with their work. First posted on Sept. 9, 2010, the spreadsheet remained on the site until a patient discovered it on Aug. 22 and notified Stanford.
The hospital, located on the campus of Stanford University in Palo Alto, demanded that the spreadsheet be removed, and the Web site quickly complied. Pressed for time, the job prospect wound up completing the assignment herself and, in the end, did not get hired, Ms. Sternfield said.
Mr. Corcino, in his first public statement, attributed the breach to “a chain of mistakes which are far too easy to make when handling electronic data.”
When the breach was first reported by The New York Times on Sept. 8, it was not clear how the data had made it to the Web.
Breaches of private medical data have become distressingly commonplace, with two substantial ones disclosed in the last week alone.
In Orlando, officials with Florida Hospital reported that three employees had improperly combed through emergency department records of 2,252 patients, apparently to forward information about accident victims to lawyers. The employees were fired, and law enforcement officials are investigating.
Meanwhile, Science Applications International Corporation disclosed that computer backup tapes containing medical data for 4.9 million military patients had been stolen from an employee’s car in San Antonio. The data included Social Security numbers, clinical notes, laboratory test results and prescriptions. The company said the risk of harm was low because retrieving data from the tapes would require specialized knowledge, software and hardware.
The Texas breach is by far the largest since September 2009, when a new federal law began requiring disclosures of medical privacy violations involving at least 500 people. Some 330 such episodes have been tallied, including four others that affected more than one million people each.
Officials at the Department of Health and Human Services said the new reporting requirements had exposed deep vulnerabilities and encouraged renewed vigilance.
“We’re moving in the right direction in terms of a culture of compliance,” said Leon Rodriguez, director of the department’s Office for Civil Rights, which investigates medical privacy cases. “Are there still a lot of problems out there? Yeah, my sense is there are still a lot of problems.”
The Stanford breach was notable for the duration of public exposure, and for spotlighting the vulnerability created by a medical provider’s business relationships with outside parties.
Last week, lawyers filed suit in state court in Los Angeles, seeking certification as a class action and $20 million in damages from Stanford Hospital & Clinics and Multi-Specialty Collection Services, which is known as MSCS. The threat of liability set off a predictable round of finger-pointing.
In written responses to questions, Lisa Lapin, Stanford University’s assistant vice president for university communications, said, “MSCS bears the complete and sole responsibility for the breach.”
Ms. Lapin said the hospital had sent the data in encrypted form to Mr. Corcino, who requested it on behalf of MSCS to analyze a strategy for improving billing collections. She said Mr. Corcino had regularly represented himself as MSCS’s executive vice president and had been Stanford’s “primary contact” during a seven-year relationship. MSCS, a five-person firm that audits hospital accounts to maximize reimbursement, possessed the passwords to unencrypt the data, she said.
“This mishandling of private patient information was in complete contravention of the law and of the requirements of MSCS’s contract and is shockingly irresponsible,” the hospital said in a statement.
Ms. Sternfield, Mr. Reyna’s lawyer, said Mr. Corcino had never been an MSCS employee, but rather was paid a monthly fee to drum up business, typically in face-to-face meetings with health care executives. Mr. Reyna, she said, had no knowledge that the Stanford data had been sent to Mr. Corcino, or that he had passed it on.
Mr. Corcino was not authorized to use an MSCS title, Ms. Sternfield said, but she declined to say whether Mr. Reyna was aware of the practice. She acknowledged that Mr. Corcino sometimes used an MSCS e-mail account.
In his e-mail to the breach victim, who shared it with The Times, Mr. Reyna wrote that Stanford had sent the file to Mr. Corcino “for a potential MSCS project that would audit paid accounts to verify that the reimbursement was correct.”
For his part, Mr. Corcino said in a statement that he was an independent contractor but was “the marketing face of the company,” and that MSCS “allowed me to use the title of executive vice president.” He wrote: “Stanford sent the file to me at MSCS, and I imported the data into a spreadsheet that was forwarded to the job applicant as part of a skills test. I did not intend to provide any personal health information in the file. This was a marketing project.”
Without explaining how or why he sent the data to the applicant, Mr. Corcino said MSCS had not trained him properly and faulted Stanford for sending him private information that he did not need. That, he said, was the “first link in a chain of mistakes.”
“I regret that Stanford released a file containing unnecessary information,” Mr. Corcino said, “that MSCS did not have an appropriate training and audit system for the handling of electronic data and that I was not more careful with the file. While Stanford and MSCS left the information in the file I received, it was my mistake to not catch its inclusion and remove the data.”
The hospital has terminated its relationship with MSCS, and Mr. Reyna has done the same with Mr. Corcino.
Stanford Hospital has reassured affected patients that the posted spreadsheet did not contain Social Security numbers, birthdates or credit card numbers, and has offered free identity theft protection services. The hospital said it had not uncovered any misuse of the exposed data.
Mozilla Wants Answers After Digital Certificate Hacks
Mozilla Wants Answers After Digital Certificate Hacks
ARTICLE DATE : September 8, 2011
By Chloe Albanesius
In the wake of the recent digital certificate hacks, Mozilla is not taking any chances, and has asked all companies that issue these certificates to be on high alert for suspicious activity.
Specifically, the browser maker wants all Certificate Authorities (CA) to complete a series of security checks by September 16 to make sure they too won't fall prey to a cyber attack like the one that hit DigiNotar. The requests are mostly technical in nature, but basically boil down to: Have you been hacked? Are you sure?
Mozilla also wants "a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed," Kathleen Wilson, module owner of Mozilla's CA Certificates Module, wrote in a Thursday note to CAs.
"Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe," Wilson wrote. "Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve."
How does this affect you? Mozilla wants to make sure that when you navigate to a Web site via Firefox, you're actually hitting a legitimate Web site and not a spoofed version that will steal your personal information. This became an issue recently when Netherlands-based DigiNotar, which issues certificates that validate Web sites as legitimate, disclosed that it had been hacked. An investigation into the effect of the intrusion found that, among other things, the hack possibly compromised the Google accounts of more than 300,000 Iranians.
A hacker known as Comodo Hacker, who got his name thanks to a March hack of Comodo, has also taken credit for the DigiNotar job. He also claims to have accessed GlobalSign, prompting the company to temporarily stop issuing digital certificates.
Like Mozilla, Google and Microsoft have taken similar steps with their respective browsers. Microsoft revoked the trust of five DigiNotar root certificates, while Google rejected all of the Certificate Authorities operated by DigiNotar. An analyst today, however, called out Apple for not yet doing the same with Safari.
ARTICLE DATE : September 8, 2011
By Chloe Albanesius
In the wake of the recent digital certificate hacks, Mozilla is not taking any chances, and has asked all companies that issue these certificates to be on high alert for suspicious activity.
Specifically, the browser maker wants all Certificate Authorities (CA) to complete a series of security checks by September 16 to make sure they too won't fall prey to a cyber attack like the one that hit DigiNotar. The requests are mostly technical in nature, but basically boil down to: Have you been hacked? Are you sure?
Mozilla also wants "a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed," Kathleen Wilson, module owner of Mozilla's CA Certificates Module, wrote in a Thursday note to CAs.
"Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe," Wilson wrote. "Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve."
How does this affect you? Mozilla wants to make sure that when you navigate to a Web site via Firefox, you're actually hitting a legitimate Web site and not a spoofed version that will steal your personal information. This became an issue recently when Netherlands-based DigiNotar, which issues certificates that validate Web sites as legitimate, disclosed that it had been hacked. An investigation into the effect of the intrusion found that, among other things, the hack possibly compromised the Google accounts of more than 300,000 Iranians.
A hacker known as Comodo Hacker, who got his name thanks to a March hack of Comodo, has also taken credit for the DigiNotar job. He also claims to have accessed GlobalSign, prompting the company to temporarily stop issuing digital certificates.
Like Mozilla, Google and Microsoft have taken similar steps with their respective browsers. Microsoft revoked the trust of five DigiNotar root certificates, while Google rejected all of the Certificate Authorities operated by DigiNotar. An analyst today, however, called out Apple for not yet doing the same with Safari.
Comodohacker: I can issue fake Windows updates
Following his recent attack against Dutch security company DigiNotar, the hacker known as Comodohacker is now threatening to exploit Microsoft's Windows Update service.
In another message posted on Pastebin last week touting his cyberattacks, the infamous hacker claims that he's able to issue phony Windows updates despite Microsoft's assertion to the contrary.
"I'm able to issue Windows update--Microsoft's statement about Windows Update and that I can't issue such update is totally false," proclaimed Comodohacker. "I already reversed ENTIRE Windows update protocol, how it reads XMLs via SSL which includes URL, KB no, SHA-1 hash of file for each update, how it verifies that downloaded file is signed using WinVerifyTrust API, and...Simply I can issue updates via Windows update! You see? I'm so smart, sharp, dangerous, powerful, etc. huh?"
If Comodohacker were able to compromise Windows Update, then he would essentially be capable of delivering malware to any Windows PC running the service.
In an earlier post on its Security Research & Defense blog, Microsoft said it was aware that some of the fake certificates released by DigiNotar were issued for such domains as Microsoft.com, Windowsupdate.com, and Update.microsoft.com. As a result, the company designated all DigiNotar certificates as untrustworthy and issued a Windows security update that can be installed manually and would be automatically installed for all users with automatic updates turned on.
But despite its actions, Microsoft contends that its Windows Update is protected from any threats from false security certificates.
"Attackers are not able to leverage a fraudulent Windows Update certificate to install malware via the Windows Update servers," Microsoft engineer Jonathan Ness wrote in the blog. "The Windows Update client will only install binary payloads signed by the actual Microsoft root CA certificate, which is issued and secured by Microsoft. Also, Windows Update itself is not at risk, even to an attacker with a fraudulent certificate."
Comodohacker's recent attack against DigiNotar caused the Dutch certificate authority to issue fake Secure Sockets Layer (SSL) certificates for Google, Microsoft, Skype, Twitter, and a host of other organizations. The hacker has also been threatening to release phony certificates for other companies.
SSL certificates authenticate secure Web sites to verify that users are connecting to the intended site. Phony certificates are especially alarming, as they can redirect Internet users to the wrong Web sites, often as a way of delivering malware, and can easily destroy confidence in the CAs (certificate authorities).
Trying to justify his actions against DigiNotar, Comodohacker blamed the Dutch government's failure to prevent the 2002 Srebrenica genocide, a massacre in which up to 8,000 men and boys were killed by Bosnian Serb forces. The hacker earned his nickname after breaching network security for a reseller of security firm Comodo.
In another message posted on Pastebin last week touting his cyberattacks, the infamous hacker claims that he's able to issue phony Windows updates despite Microsoft's assertion to the contrary.
"I'm able to issue Windows update--Microsoft's statement about Windows Update and that I can't issue such update is totally false," proclaimed Comodohacker. "I already reversed ENTIRE Windows update protocol, how it reads XMLs via SSL which includes URL, KB no, SHA-1 hash of file for each update, how it verifies that downloaded file is signed using WinVerifyTrust API, and...Simply I can issue updates via Windows update! You see? I'm so smart, sharp, dangerous, powerful, etc. huh?"
If Comodohacker were able to compromise Windows Update, then he would essentially be capable of delivering malware to any Windows PC running the service.
In an earlier post on its Security Research & Defense blog, Microsoft said it was aware that some of the fake certificates released by DigiNotar were issued for such domains as Microsoft.com, Windowsupdate.com, and Update.microsoft.com. As a result, the company designated all DigiNotar certificates as untrustworthy and issued a Windows security update that can be installed manually and would be automatically installed for all users with automatic updates turned on.
But despite its actions, Microsoft contends that its Windows Update is protected from any threats from false security certificates.
"Attackers are not able to leverage a fraudulent Windows Update certificate to install malware via the Windows Update servers," Microsoft engineer Jonathan Ness wrote in the blog. "The Windows Update client will only install binary payloads signed by the actual Microsoft root CA certificate, which is issued and secured by Microsoft. Also, Windows Update itself is not at risk, even to an attacker with a fraudulent certificate."
Comodohacker's recent attack against DigiNotar caused the Dutch certificate authority to issue fake Secure Sockets Layer (SSL) certificates for Google, Microsoft, Skype, Twitter, and a host of other organizations. The hacker has also been threatening to release phony certificates for other companies.
SSL certificates authenticate secure Web sites to verify that users are connecting to the intended site. Phony certificates are especially alarming, as they can redirect Internet users to the wrong Web sites, often as a way of delivering malware, and can easily destroy confidence in the CAs (certificate authorities).
Trying to justify his actions against DigiNotar, Comodohacker blamed the Dutch government's failure to prevent the 2002 Srebrenica genocide, a massacre in which up to 8,000 men and boys were killed by Bosnian Serb forces. The hacker earned his nickname after breaching network security for a reseller of security firm Comodo.
FISMA Mandates Monthly Security Reports For Agencies
Federal agencies must begin reporting security data to an online compliance tool as part of fiscal year 2011 requirements for the Federal Information Security Management Act (FISMA).
The Department of Homeland Security (DHS) outlined new requirements for FISMA, the National Institute of Standards and Technology (NIST) security standard for federal IT solutions. One of them calls for agencies to establish monthly data feeds to CyberScope, a compliance tool developed to help the feds to better and more actively monitor cybersecurity.
The tool was announced in late 2009 under then U.S. CIO Vivek Kundra, who at the time said it would help the feds not merely "collect information for information's sake," but work to actively improve its security posture.
Indeed, CyberScope represents a major shift in the way federal agencies report FISMA compliance in that it replaces once-a-year compliance reporting with a more operational, consistent approach.
Previously, agency auditors would have to sift through mounds of paper-based reports to do security analysis. The new tool will make this analysis more efficient and less expensive, as well as provide a more accurate picture of agency security.
Agencies, too, will benefit from a lighter reporting burden and can submit security information more nimbly and in real time through CyberScope.
Other requirements outlined in the memo include response to a set of monthly security posture questions presented in the tool. The questions address areas of risk and are aimed at assessing the implementation of security capabilities and measure their effectiveness, according to the DHS.
Agencies also must engage in CyberStat accountability review sessions and interviews to help them develop "focused action plans for improving their information security posture," according to the memo.
CyberStat sessions will feature representatives from the DHS, Office of Management and Budget, the National Security Staff (NSS), and teams from each agency to examine security program data and help solve any problems identified in the sessions. The goal of the sessions is to bolster overall security performance, according to the memo.
The sessions will do that by highlighting capability areas where agencies must put more focus on security; help them remove any stumbling blocks that may exist to meeting FISMA requirements; and give kudos to agencies in areas where they're meeting their goals for compliance, according to the DHS.
The Department of Homeland Security (DHS) outlined new requirements for FISMA, the National Institute of Standards and Technology (NIST) security standard for federal IT solutions. One of them calls for agencies to establish monthly data feeds to CyberScope, a compliance tool developed to help the feds to better and more actively monitor cybersecurity.
The tool was announced in late 2009 under then U.S. CIO Vivek Kundra, who at the time said it would help the feds not merely "collect information for information's sake," but work to actively improve its security posture.
Indeed, CyberScope represents a major shift in the way federal agencies report FISMA compliance in that it replaces once-a-year compliance reporting with a more operational, consistent approach.
Previously, agency auditors would have to sift through mounds of paper-based reports to do security analysis. The new tool will make this analysis more efficient and less expensive, as well as provide a more accurate picture of agency security.
Agencies, too, will benefit from a lighter reporting burden and can submit security information more nimbly and in real time through CyberScope.
Other requirements outlined in the memo include response to a set of monthly security posture questions presented in the tool. The questions address areas of risk and are aimed at assessing the implementation of security capabilities and measure their effectiveness, according to the DHS.
Agencies also must engage in CyberStat accountability review sessions and interviews to help them develop "focused action plans for improving their information security posture," according to the memo.
CyberStat sessions will feature representatives from the DHS, Office of Management and Budget, the National Security Staff (NSS), and teams from each agency to examine security program data and help solve any problems identified in the sessions. The goal of the sessions is to bolster overall security performance, according to the memo.
The sessions will do that by highlighting capability areas where agencies must put more focus on security; help them remove any stumbling blocks that may exist to meeting FISMA requirements; and give kudos to agencies in areas where they're meeting their goals for compliance, according to the DHS.
Researchers uncover first active BIOS rootkit attack
Researchers uncover first active BIOS rootkit attack
Dan KaplanSeptember 14 2011
Researchers have discovered what is believed to be the first in-the-wild rootkit that targets BIOS, the built-in software responsible for booting up a computer and managing communication between the machine and its attached devices.
The discovery of Mebromi is notable not because any widespread infections are anticipated – the complexity of a successful attack on the motherboard is high – but because it appears to be the first malware written for the BIOS in at least four years, Webroot researcher Marco Giuliani, who studied the threat, said in a blog post Tuesday.
The potent malware cocktail, consisting of a BIOS rootkit, an MBR (master boot record) rootkit, a kernel-mode rookit, a PE (portable executable) file infector and a trojan downloader, is designed to evade anti-virus detection.
Right now, the active attack exclusively is targeting Chinese users, Giuliani said. The trojan dropper is designed to first infect Award BIOS, manufactured by Phoenix Technologies. Once the BIOS is infected, the malicious code compromises the master boot record, a small program initiated when a computer starts up.
Anti-virus technologies likely will struggle against the threat.
"Storing the malicious code inside the BIOS ROM [chip] could actually become more than just a problem for security software, [given] the fact that even if an anti-virus product [can] detect and clean the MBR (master boot record) infection, it will be restored at the next system start-up when the malicious BIOS payload would overwrite the MBR code again," Giuliani wrote. "Developing an anti-virus utility able to clean the BIOS code is a challenge because it needs to be totally error-proof to avoid rendering the system unbootable at all."
Still, he doubts the threat will become far-reaching because the rootkit only works with one type of BIOS, likely because it is fashioned after the IceLord BIOS proof-of-concept from 2007, which also targeted Award.
"Although this kind of infection is potentially one of the most persistent infections known out there in the wild, it will hardly become a major threat because of the level of complexity needed to achieve the goal," Giuliani wrote.
The Chinese security firm Qihoo 360 first detected the attack, according to Webroot.
Dan KaplanSeptember 14 2011
Researchers have discovered what is believed to be the first in-the-wild rootkit that targets BIOS, the built-in software responsible for booting up a computer and managing communication between the machine and its attached devices.
The discovery of Mebromi is notable not because any widespread infections are anticipated – the complexity of a successful attack on the motherboard is high – but because it appears to be the first malware written for the BIOS in at least four years, Webroot researcher Marco Giuliani, who studied the threat, said in a blog post Tuesday.
The potent malware cocktail, consisting of a BIOS rootkit, an MBR (master boot record) rootkit, a kernel-mode rookit, a PE (portable executable) file infector and a trojan downloader, is designed to evade anti-virus detection.
Right now, the active attack exclusively is targeting Chinese users, Giuliani said. The trojan dropper is designed to first infect Award BIOS, manufactured by Phoenix Technologies. Once the BIOS is infected, the malicious code compromises the master boot record, a small program initiated when a computer starts up.
Anti-virus technologies likely will struggle against the threat.
"Storing the malicious code inside the BIOS ROM [chip] could actually become more than just a problem for security software, [given] the fact that even if an anti-virus product [can] detect and clean the MBR (master boot record) infection, it will be restored at the next system start-up when the malicious BIOS payload would overwrite the MBR code again," Giuliani wrote. "Developing an anti-virus utility able to clean the BIOS code is a challenge because it needs to be totally error-proof to avoid rendering the system unbootable at all."
Still, he doubts the threat will become far-reaching because the rootkit only works with one type of BIOS, likely because it is fashioned after the IceLord BIOS proof-of-concept from 2007, which also targeted Award.
"Although this kind of infection is potentially one of the most persistent infections known out there in the wild, it will hardly become a major threat because of the level of complexity needed to achieve the goal," Giuliani wrote.
The Chinese security firm Qihoo 360 first detected the attack, according to Webroot.
Researcher discloses zero-day flaws in SCADA systems
Computerworld - An Italian security researcher this week disclosed details of several zero-day vulnerabilities he discovered in Supervisory Control and Data Acquisition (SCADA) products from multiple vendors, a disclosure that's likely to reinforce concerns about critical infrastructure weaknesses.
This is the second such disclosure by researcher Luigi Auriemma this year. In March, he disclosed similar vulnerabilities in SCADA products from Siemens, Iconics, 7-Technologies and Datac. His disclosure prompted the US-Computer Emergency Response Team (US-CERT) to issue four alerts warning about the vulnerabilities.
The most recent flaws discovered by Auriemma affect SCADA products from six vendors, including Rockwell Automation, Cogent Datahub, Measuresoft and Progea. Several of the flaws could enable remote execution attacks and denial-of-service attacks against the vulnerable systems.
In emailed comments, Auriemma said that almost all of the vulnerabilities he discovered are remote code execution flaws that allow attackers to run code of their choice on the vulnerable systems. Only one of the flaws is a denial-of-service vulnerability. It's still unclear whether the flaw in Rockwell's product could allow code execution, Auriemma said.
The researcher described some of the flaws as being easy to exploit. With "one of them, [it] is just enough to type the command you want to execute remotely while the others are classical easy-to-exploit bugs. In some cases, the exploitation is a bit more difficult," Auriemma said.
Auriemma said that he has not contacted any of the vendors about his findings. "This was only a quick experiment in which I dedicated some minutes for each product." At least three of the vendors have already issued fixes, while Rockwell is working on one, he said.
The disclosures prompted US-CERT's Industrial Control Systems Cyber Emergency Response Team to issue advisories about the flaws.
SCADA systems are used to control critical equipment at power companies, manufacturing facilities, water treatment plants and elsewhere. Security analysts fear that attacks against such systems could cripple critical infrastructure services such as electricity and public water supplies.
The Stuxnet worm, which exploited a weakness in a Siemens control system to disrupt operations at an Iranian nuclear plant is often cited as an example of the kind of damage that can be wreaked via vulnerable SCADA systems.
The latest vulnerabilities mostly exist in free or low-cost Windows-based engineering workstations that are used as interfaces to backend control systems, according to an analysis by Digital Bond, a consulting firm specializing in control system security.
One of the vulnerable products -- Rockwell's RSLogix system -- was described by Digital Bond as a workstation used to configure industrial control systems that are deployed widely in critical infrastructure. Most of the others are smaller, add-on and data transfer products that are "used in either very small systems or as an addition/accessory to a larger system," Digital Bond said.
All of the vulnerabilities disclosed by Auriemma exist in the so-called Human Machine Interface (HMI) systems used to manage industrial control systems, said Joseph Weiss, managing partner at Applied Control Systems LLC and author of the book Protecting Industrial Control Systems from Electronic Threat.
"Vulnerabilities in HMI systems are not novel," but they should not be minimized, he said. Such vulnerabilities can be used to get at the downstream control system, he said.
"You can use the HMI to get to the control device and you can use the control device to get to the HMI," he said. Without further analysis, it is too soon to say whether the flaws discovered by Auriemma are really critical or not, he said. A lot depends on the kind of applications for which the affected systems are used, he said.
"Rockwell is a major manufacturer. They make a lot of systems, some of which are used in really critical applications," he added.
A spokesman from Rockwell said the company would release a statement soon.
This is the second such disclosure by researcher Luigi Auriemma this year. In March, he disclosed similar vulnerabilities in SCADA products from Siemens, Iconics, 7-Technologies and Datac. His disclosure prompted the US-Computer Emergency Response Team (US-CERT) to issue four alerts warning about the vulnerabilities.
The most recent flaws discovered by Auriemma affect SCADA products from six vendors, including Rockwell Automation, Cogent Datahub, Measuresoft and Progea. Several of the flaws could enable remote execution attacks and denial-of-service attacks against the vulnerable systems.
In emailed comments, Auriemma said that almost all of the vulnerabilities he discovered are remote code execution flaws that allow attackers to run code of their choice on the vulnerable systems. Only one of the flaws is a denial-of-service vulnerability. It's still unclear whether the flaw in Rockwell's product could allow code execution, Auriemma said.
The researcher described some of the flaws as being easy to exploit. With "one of them, [it] is just enough to type the command you want to execute remotely while the others are classical easy-to-exploit bugs. In some cases, the exploitation is a bit more difficult," Auriemma said.
Auriemma said that he has not contacted any of the vendors about his findings. "This was only a quick experiment in which I dedicated some minutes for each product." At least three of the vendors have already issued fixes, while Rockwell is working on one, he said.
The disclosures prompted US-CERT's Industrial Control Systems Cyber Emergency Response Team to issue advisories about the flaws.
SCADA systems are used to control critical equipment at power companies, manufacturing facilities, water treatment plants and elsewhere. Security analysts fear that attacks against such systems could cripple critical infrastructure services such as electricity and public water supplies.
The Stuxnet worm, which exploited a weakness in a Siemens control system to disrupt operations at an Iranian nuclear plant is often cited as an example of the kind of damage that can be wreaked via vulnerable SCADA systems.
The latest vulnerabilities mostly exist in free or low-cost Windows-based engineering workstations that are used as interfaces to backend control systems, according to an analysis by Digital Bond, a consulting firm specializing in control system security.
One of the vulnerable products -- Rockwell's RSLogix system -- was described by Digital Bond as a workstation used to configure industrial control systems that are deployed widely in critical infrastructure. Most of the others are smaller, add-on and data transfer products that are "used in either very small systems or as an addition/accessory to a larger system," Digital Bond said.
All of the vulnerabilities disclosed by Auriemma exist in the so-called Human Machine Interface (HMI) systems used to manage industrial control systems, said Joseph Weiss, managing partner at Applied Control Systems LLC and author of the book Protecting Industrial Control Systems from Electronic Threat.
"Vulnerabilities in HMI systems are not novel," but they should not be minimized, he said. Such vulnerabilities can be used to get at the downstream control system, he said.
"You can use the HMI to get to the control device and you can use the control device to get to the HMI," he said. Without further analysis, it is too soon to say whether the flaws discovered by Auriemma are really critical or not, he said. A lot depends on the kind of applications for which the affected systems are used, he said.
"Rockwell is a major manufacturer. They make a lot of systems, some of which are used in really critical applications," he added.
A spokesman from Rockwell said the company would release a statement soon.
3 indicted in sophisticated hacking, theft scheme
By Gene Johnson
updated 9/22/2011 11:37:07 AM ET
SEATTLE — Soon after his office was burglarized — twice — Jeff Eby walked in and found a payroll report sitting on his printer. He hadn't printed it, and as his company's chief financial officer, he's the only person who would have.
That's how he came to learn his organization had been hit by what prosecutors describe as a small team of sophisticated thieves and hackers that hit dozens of businesses over the past few years. In some cases, they chose their victims simply by driving around and picking up their wireless Internet signals; in others, they broke in the old-fashioned way, mainly for the purpose of installing malicious computer software on company networks, prosecutors said.
Joshuah Allen Witt, Brad Eugene Lowe and John Earl Griffin are charged in a 10-count federal indictment unsealed this week accusing them of aggravated identity theft and other charges. Lowe and Griffin have pleaded not guilty; Witt is in state custody and is expected to soon be transferred to federal custody.
At least 53 Puget Sound-area companies were hit, with losses well into the hundreds of thousands of dollars. Investigators are still tallying, Seattle U.S. Attorney Jenny Durkan told a news conference Wednesday.
In some cases, prosecutors say that once the men hacked into the wireless hotspots or burglarized the businesses, they obtained financial data, hijacked payroll systems, stole the identities of employees and routed pay checks to accounts they'd set up in the employees' names.
Then, they gave themselves raises.
"Once the hackers are in the system, they have a smorgasbord" — and can use the information to open bank accounts, compromise the personal credit information of employees and access PayPal, Amazon and eBay accounts, said Assistant U.S. Attorney Kathryn Warma.
The defendants were so ingenious at masking their trail and destroying electronic evidence of their intrusions that sometimes employees of the victimized companies wound up being questioned as potential suspects, investigators said. And according to the indictment, they took over some companies' networks in such a way that they were able "to monitor the victim business's discovery and response to the network intrusion, to include eavesdropping on communications with law enforcement agents."
The men used the money on items including a Rolex watch and car engines, prosecutors said. They're also accused of buying a wealth of computer equipment — including powerful antennas — that could be used to further their hacking activities.
It wasn't immediately clear how police first linked the three to the hacking, but documents filed in federal and state court said the investigation began by August 2008, and the three were identified as suspects by late 2010, when all three were initially arrested. Two — Lowe and Witt — were charged with various burglaries in King County Superior Court. Griffin was arrested at a local wine bar when police said he tried to use stolen gift cards, but that case was never referred for prosecution, said Dan Donohoe, a spokesman for the county prosecutor's office.
Investigators said it helped that the businesses reported the intrusions promptly, and the U.S. Secret Service Electronic Crimes Task Force in the region was able to connect the dots among cases that seemed unrelated.
Witt, who has a criminal history involving escape, theft and other convictions, was also arrested for investigation of stolen property in 2007, but ignored orders to appear in court in that case. Nevertheless, when he was arrested again last December, the court gave him a 24-hour release in which to post bond. He didn't post bond or show up in court as ordered, and was taken back into custody in February.
After being released from custody in late 2010, Witt and Lowe continued burglarizing businesses, prosecutors said. They were rearrested last Friday.
Lowe's attorney, Brent Hart, said it was too early to comment on the case.
An attorney for Griffin could not immediately be reached for comment.
No attorney has appeared on Witt's behalf in federal court.
The victimized companies included Eby's, a firm that helps universities capitalize on technologies they develop, and a downtown property management firm run by Mark Houtchens. Both said the costs of fixing the damage caused by the intrusions — figuring out what happened and securing their computer networks anew — have been severe.
"It's a pain in the neck, if not quite a bit lower," Houtchens said.
Copyright 2011 The Associated Press. All rights reserved. This material may not be published, broadcast, rewritten or redistributed.
updated 9/22/2011 11:37:07 AM ET
SEATTLE — Soon after his office was burglarized — twice — Jeff Eby walked in and found a payroll report sitting on his printer. He hadn't printed it, and as his company's chief financial officer, he's the only person who would have.
That's how he came to learn his organization had been hit by what prosecutors describe as a small team of sophisticated thieves and hackers that hit dozens of businesses over the past few years. In some cases, they chose their victims simply by driving around and picking up their wireless Internet signals; in others, they broke in the old-fashioned way, mainly for the purpose of installing malicious computer software on company networks, prosecutors said.
Joshuah Allen Witt, Brad Eugene Lowe and John Earl Griffin are charged in a 10-count federal indictment unsealed this week accusing them of aggravated identity theft and other charges. Lowe and Griffin have pleaded not guilty; Witt is in state custody and is expected to soon be transferred to federal custody.
At least 53 Puget Sound-area companies were hit, with losses well into the hundreds of thousands of dollars. Investigators are still tallying, Seattle U.S. Attorney Jenny Durkan told a news conference Wednesday.
In some cases, prosecutors say that once the men hacked into the wireless hotspots or burglarized the businesses, they obtained financial data, hijacked payroll systems, stole the identities of employees and routed pay checks to accounts they'd set up in the employees' names.
Then, they gave themselves raises.
"Once the hackers are in the system, they have a smorgasbord" — and can use the information to open bank accounts, compromise the personal credit information of employees and access PayPal, Amazon and eBay accounts, said Assistant U.S. Attorney Kathryn Warma.
The defendants were so ingenious at masking their trail and destroying electronic evidence of their intrusions that sometimes employees of the victimized companies wound up being questioned as potential suspects, investigators said. And according to the indictment, they took over some companies' networks in such a way that they were able "to monitor the victim business's discovery and response to the network intrusion, to include eavesdropping on communications with law enforcement agents."
The men used the money on items including a Rolex watch and car engines, prosecutors said. They're also accused of buying a wealth of computer equipment — including powerful antennas — that could be used to further their hacking activities.
It wasn't immediately clear how police first linked the three to the hacking, but documents filed in federal and state court said the investigation began by August 2008, and the three were identified as suspects by late 2010, when all three were initially arrested. Two — Lowe and Witt — were charged with various burglaries in King County Superior Court. Griffin was arrested at a local wine bar when police said he tried to use stolen gift cards, but that case was never referred for prosecution, said Dan Donohoe, a spokesman for the county prosecutor's office.
Investigators said it helped that the businesses reported the intrusions promptly, and the U.S. Secret Service Electronic Crimes Task Force in the region was able to connect the dots among cases that seemed unrelated.
Witt, who has a criminal history involving escape, theft and other convictions, was also arrested for investigation of stolen property in 2007, but ignored orders to appear in court in that case. Nevertheless, when he was arrested again last December, the court gave him a 24-hour release in which to post bond. He didn't post bond or show up in court as ordered, and was taken back into custody in February.
After being released from custody in late 2010, Witt and Lowe continued burglarizing businesses, prosecutors said. They were rearrested last Friday.
Lowe's attorney, Brent Hart, said it was too early to comment on the case.
An attorney for Griffin could not immediately be reached for comment.
No attorney has appeared on Witt's behalf in federal court.
The victimized companies included Eby's, a firm that helps universities capitalize on technologies they develop, and a downtown property management firm run by Mark Houtchens. Both said the costs of fixing the damage caused by the intrusions — figuring out what happened and securing their computer networks anew — have been severe.
"It's a pain in the neck, if not quite a bit lower," Houtchens said.
Copyright 2011 The Associated Press. All rights reserved. This material may not be published, broadcast, rewritten or redistributed.
Calif. Law Beefs Up Breach Notices
Calif. Law Beefs Up Breach Notices
Law Requires Providing Specific Details to Individuals Affected
Jeffrey Roman
September 2, 2011
A new California law requires that organizations experiencing a data breach provide more detailed information to the individuals affected.
California Gov. Jerry Brown has signed into law Senate Bill 24. The bill, introduced by Sen. Joe Simitian, D-Palo Alto, establishes standards for the details to be included in data breach notifications, including a general description of the incident, the type of information breached and the time of the breach. It also requires, in certain circumstances, providing consumers with the toll-free telephone numbers and addresses of the major credit reporting agencies in California.
The law, which affects notification of breaches involving financial, healthcare and other personal information, goes into effect Jan. 1, 2012.
On Sept. 29, 2010, then-Governor Arnold Schwarzenegger vetoed SB 1166, Sen. Simitian's previous effort to enact stronger data breach notification requirements [See California Eyes Stronger Privacy Law].
This new law updates AB 700, or SB 1386, adopted in 2003, which requires organizations to notify individuals after a breach of personal information. The landmark law - one of the first state breach notification laws in the nation - didn't indicate what information needed to be included in the notification. But it required breaches to be reported to individuals affected "in the most expedient time possible and without unreasonable delay, consistent with the legitimate needs of law enforcement ... or any measures necessary to determine the scope of the breach and restore the reasonable integrity of the data system."
Another California law requires healthcare organizations to report breaches to the state within five days.
"Senate Bill 24 is the logical next step to ensure consumers have the specific information they need to protect themselves after a data breach," Simitian stated in a press release.
SB 24 also requires organizations that have experienced a breach to send an electronic copy of the notification to the state attorney general if a single breach affects more than 500 Californians. Simitian says this requirement will "give law enforcement the ability to see the big picture and better understand the patterns and practices of identity theft statewide."
Personal information, as defined in SB 24, includes: Social Security numbers; driver's license numbers or California identification card numbers; bank account numbers; credit or debit card numbers, in combination with any required security code; access code or password; medical information and health insurance information.
Philip Alexander, information security officer for Wells Fargo Bank and author of the book Data Breach Disclosure Laws - a State by State Perspective, sees the new law as being a "common-sense requirement."
While Alexander doesn't see the new law as making things tougher for organizations that have experienced a breach, he says it will help ensure that individuals affected by breaches receive helpful information, such as how to contact credit reporting agencies.
Breach Notification Requirements
The new law requires organizations that experience a breach to provide more detailed information to breach victims. The law requires that breach notifications: •Be written in plain language;
•Include the name and contact information of the agency breached;
•Provide a list of the personal information reasonably believed to have been subject to the breach;
•Spell out the date of the breach, the estimated date of the breach or the date range within which the breach occurred;
•Specify whether the notification was delayed as a result of a law enforcement investigation;
•Offer a general description of the breach incident;
•Provide toll-free telephone numbers and addresses of the major credit reporting agencies, if the breach exposed a Social Security number or a driver's license or California identification card number;
•Include information about what the organization has done to protect individuals whose information was breached;
and •Outline steps individuals may take to protect himself or herself.
Law Requires Providing Specific Details to Individuals Affected
Jeffrey Roman
September 2, 2011
A new California law requires that organizations experiencing a data breach provide more detailed information to the individuals affected.
California Gov. Jerry Brown has signed into law Senate Bill 24. The bill, introduced by Sen. Joe Simitian, D-Palo Alto, establishes standards for the details to be included in data breach notifications, including a general description of the incident, the type of information breached and the time of the breach. It also requires, in certain circumstances, providing consumers with the toll-free telephone numbers and addresses of the major credit reporting agencies in California.
The law, which affects notification of breaches involving financial, healthcare and other personal information, goes into effect Jan. 1, 2012.
On Sept. 29, 2010, then-Governor Arnold Schwarzenegger vetoed SB 1166, Sen. Simitian's previous effort to enact stronger data breach notification requirements [See California Eyes Stronger Privacy Law].
This new law updates AB 700, or SB 1386, adopted in 2003, which requires organizations to notify individuals after a breach of personal information. The landmark law - one of the first state breach notification laws in the nation - didn't indicate what information needed to be included in the notification. But it required breaches to be reported to individuals affected "in the most expedient time possible and without unreasonable delay, consistent with the legitimate needs of law enforcement ... or any measures necessary to determine the scope of the breach and restore the reasonable integrity of the data system."
Another California law requires healthcare organizations to report breaches to the state within five days.
"Senate Bill 24 is the logical next step to ensure consumers have the specific information they need to protect themselves after a data breach," Simitian stated in a press release.
SB 24 also requires organizations that have experienced a breach to send an electronic copy of the notification to the state attorney general if a single breach affects more than 500 Californians. Simitian says this requirement will "give law enforcement the ability to see the big picture and better understand the patterns and practices of identity theft statewide."
Personal information, as defined in SB 24, includes: Social Security numbers; driver's license numbers or California identification card numbers; bank account numbers; credit or debit card numbers, in combination with any required security code; access code or password; medical information and health insurance information.
Philip Alexander, information security officer for Wells Fargo Bank and author of the book Data Breach Disclosure Laws - a State by State Perspective, sees the new law as being a "common-sense requirement."
While Alexander doesn't see the new law as making things tougher for organizations that have experienced a breach, he says it will help ensure that individuals affected by breaches receive helpful information, such as how to contact credit reporting agencies.
Breach Notification Requirements
The new law requires organizations that experience a breach to provide more detailed information to breach victims. The law requires that breach notifications: •Be written in plain language;
•Include the name and contact information of the agency breached;
•Provide a list of the personal information reasonably believed to have been subject to the breach;
•Spell out the date of the breach, the estimated date of the breach or the date range within which the breach occurred;
•Specify whether the notification was delayed as a result of a law enforcement investigation;
•Offer a general description of the breach incident;
•Provide toll-free telephone numbers and addresses of the major credit reporting agencies, if the breach exposed a Social Security number or a driver's license or California identification card number;
•Include information about what the organization has done to protect individuals whose information was breached;
and •Outline steps individuals may take to protect himself or herself.
POS Breach Spans 2 Years
POS Breach Spans 2 Years
Experts: Duration Points to Significant Security Gaps
Tracy Kitten
September 14, 2011
Little has been reported about POS fraud since the Michaels craft store breach made headlines in May, after point of sale terminals at 90 of Michaels' 964 U.S. stores were reportedly compromised as part of a POS-swap scam waged by an organized crime ring.
But now a new payment card breach, this time striking a company that supplies vending machines and games to entertainment venues, has reignited concerns about POS system security.
Wisconsin-based Vacationland Vendors recently posted an alert on its website, warning consumers that a POS breach at one of the venues it serves likely exposed credit and debit card details. The breach at Wilderness Resorts in Wisconsin and Tennessee could have exposed card details related to transaction made between Dec. 12, 2008 and May 25, 2011. Vacationland did not say when the breach was discovered, the number of cards suspected exposed, or if the breach affected only vending transactions.
"Vacationland Vendors recently discovered that an unauthorized person wrongfully accessed certain parts of the point of sales systems that Vacationland Vendors uses to process credit and debit transactions at the Wilderness Resorts," the statement reads. "Based upon its investigation to date, Vacationland Vendors reasonably believes that a computer hacker improperly acquired credit card and debit information. This incident did not involve an internal security issue within the Wilderness Resort. Vacationland Vendors has learned that other businesses just like its own have been affected by this computer hacker."
One estimate suggests 40,000 cardholders could be affected.
A Long Time
John Buzzard, who tracks card transaction anomalies for FICO's Card Alert Service, says it's too early to know how many cards truly were exposed, how many have been hit with fraudulent transactions and whether the breach at Wilderness Resorts is linked to any other entertainment-park or merchant POS attacks. What is telling, however, is the duration of the compromise.
"The window of exposure is Dec. 12, 2008, through May 25, 2011," he says. "That's a long time for malware or some other method to continually compromise a merchant without being detected," suggesting some other type attack likely led to the breach.
George Tubin, a banking and payments fraud analyst, says the hack is likely connected to a POS skimming attack, which could be similar to the scheme that hit Michaels stores or that could have been aimed only at Vacationland vending machines. A physical attack would explain how the exposure spanned a two-and-a-half year period without being detected.
"Hacking into these systems is easy," Tubin says. "If someone has complete access, it's fairly easy to put a card-skimming device in that looks like it's integrated into the POS system. With a little more effort, they can also capture PINs if they're used. So, it's not necessary to hack into the network when they can get the information with brute force. Vendors have developed tamper proof readers, so that any attempt to alter them is caught."
The same method of POS device swapping was used more than year ago against Hancock Fabrics, which led to card fraud that affected more than 140 customers in three states.
Most industry experts, however, say POS swapping schemes are rare. It's risky for fraudsters to physically switch or swap POS devices, especially when the devices are located at manned checkout lanes, as was the case in the incidents that hit Michaels and Hancock.
In the Wilderness Resorts breach, McAfee Consultant Robert Siciliano suggests the breach more likely was linked to unmanned, self-service terminals that could have been physically attacked, but were probably remotely hacked.
"In this situation, it doesn't seem like it was a hardware breach, like Michaels, but more of a software breach," he says. "Many of these kiosk-based systems still rely on WindowsXP. We know XP is fraught with vulnerabilities that, if not patched, make it a big target. Most kiosks, including many ATMs, have remote access technologies allowing for service. These systems are live, connected to the Internet, and have a port accessible online for service. Bad guys scan these known channels and perform brute-force attacks. Anytime you meld remote access and WindowsXP, you are vulnerable."
In August 2010, during a Black Hat convention in Las Vegas, ethical hacker Barnaby Jack, formerly of Juniper Networks, demonstrated how easily a hacker could infect an ATM without physical contact. During the event, Jack attacked two common retail ATM models with malware, giving him control to collect card details and manipulate the machines to spit out cash on cue. Jack bypassed the remote authentication system using a homemade rootkit that attacked one of the ATM's Windows operating system, giving him undetected system-administrative privileges.
Siciliano says the industry is aware of the vulnerabilities unattended self-service payment terminals pose, and is working to address those security gaps with centralized monitoring. "Over the next year there will be more cloud-based kiosks and ATMs that will allow for central monitoring and security," he says. "These devices will lack many of the internal physical components that the current ones have," ultimately making them more secure.
Experts: Duration Points to Significant Security Gaps
Tracy Kitten
September 14, 2011
Little has been reported about POS fraud since the Michaels craft store breach made headlines in May, after point of sale terminals at 90 of Michaels' 964 U.S. stores were reportedly compromised as part of a POS-swap scam waged by an organized crime ring.
But now a new payment card breach, this time striking a company that supplies vending machines and games to entertainment venues, has reignited concerns about POS system security.
Wisconsin-based Vacationland Vendors recently posted an alert on its website, warning consumers that a POS breach at one of the venues it serves likely exposed credit and debit card details. The breach at Wilderness Resorts in Wisconsin and Tennessee could have exposed card details related to transaction made between Dec. 12, 2008 and May 25, 2011. Vacationland did not say when the breach was discovered, the number of cards suspected exposed, or if the breach affected only vending transactions.
"Vacationland Vendors recently discovered that an unauthorized person wrongfully accessed certain parts of the point of sales systems that Vacationland Vendors uses to process credit and debit transactions at the Wilderness Resorts," the statement reads. "Based upon its investigation to date, Vacationland Vendors reasonably believes that a computer hacker improperly acquired credit card and debit information. This incident did not involve an internal security issue within the Wilderness Resort. Vacationland Vendors has learned that other businesses just like its own have been affected by this computer hacker."
One estimate suggests 40,000 cardholders could be affected.
A Long Time
John Buzzard, who tracks card transaction anomalies for FICO's Card Alert Service, says it's too early to know how many cards truly were exposed, how many have been hit with fraudulent transactions and whether the breach at Wilderness Resorts is linked to any other entertainment-park or merchant POS attacks. What is telling, however, is the duration of the compromise.
"The window of exposure is Dec. 12, 2008, through May 25, 2011," he says. "That's a long time for malware or some other method to continually compromise a merchant without being detected," suggesting some other type attack likely led to the breach.
George Tubin, a banking and payments fraud analyst, says the hack is likely connected to a POS skimming attack, which could be similar to the scheme that hit Michaels stores or that could have been aimed only at Vacationland vending machines. A physical attack would explain how the exposure spanned a two-and-a-half year period without being detected.
"Hacking into these systems is easy," Tubin says. "If someone has complete access, it's fairly easy to put a card-skimming device in that looks like it's integrated into the POS system. With a little more effort, they can also capture PINs if they're used. So, it's not necessary to hack into the network when they can get the information with brute force. Vendors have developed tamper proof readers, so that any attempt to alter them is caught."
The same method of POS device swapping was used more than year ago against Hancock Fabrics, which led to card fraud that affected more than 140 customers in three states.
Most industry experts, however, say POS swapping schemes are rare. It's risky for fraudsters to physically switch or swap POS devices, especially when the devices are located at manned checkout lanes, as was the case in the incidents that hit Michaels and Hancock.
In the Wilderness Resorts breach, McAfee Consultant Robert Siciliano suggests the breach more likely was linked to unmanned, self-service terminals that could have been physically attacked, but were probably remotely hacked.
"In this situation, it doesn't seem like it was a hardware breach, like Michaels, but more of a software breach," he says. "Many of these kiosk-based systems still rely on WindowsXP. We know XP is fraught with vulnerabilities that, if not patched, make it a big target. Most kiosks, including many ATMs, have remote access technologies allowing for service. These systems are live, connected to the Internet, and have a port accessible online for service. Bad guys scan these known channels and perform brute-force attacks. Anytime you meld remote access and WindowsXP, you are vulnerable."
In August 2010, during a Black Hat convention in Las Vegas, ethical hacker Barnaby Jack, formerly of Juniper Networks, demonstrated how easily a hacker could infect an ATM without physical contact. During the event, Jack attacked two common retail ATM models with malware, giving him control to collect card details and manipulate the machines to spit out cash on cue. Jack bypassed the remote authentication system using a homemade rootkit that attacked one of the ATM's Windows operating system, giving him undetected system-administrative privileges.
Siciliano says the industry is aware of the vulnerabilities unattended self-service payment terminals pose, and is working to address those security gaps with centralized monitoring. "Over the next year there will be more cloud-based kiosks and ATMs that will allow for central monitoring and security," he says. "These devices will lack many of the internal physical components that the current ones have," ultimately making them more secure.
Certificate Breach: 3 Lessons
Certificate Breach: 3 Lessons
DigiNotar Collapse Exposes Fundamental Security Flaws
Tracy Kitten
September 27, 2011
The collapse of Netherlands-based certificate authority DigiNotar raises surprising revelations about fundamental flaws in browsing security practices.
Although not the first certificate authority host to be hacked - Comodo was hit in March - DigiNotar's breach reveals security gaps and gaffes that could have been avoided.
A 13-page audit of DigiNotar conducted by IT security firm Fox-IT notes lax monitoring controls and breach-reporting delays that magnified the compromise. Fox-IT is quick to point out, however, that the audit report does not aim to offer suggestions for improving or changing certificate-issuing practices. Because the investigation into the DigiNotar breach is ongoing, Fox-IT was only willing to comment about facts and findings contained within the report, which is public.
DigiNotar: What Happened
Hackers targeted DigiNotar, like Comodo, to issue counterfeit certificates for common sites such Google and Skype. With these fraudulent certificates, hackers allegedly directed Web users to ghost sites that mimicked those sites users trust.
Under common Internet browsing behavior and standards, it's difficult for the average Web user to spot a counterfeit site. And browsers, based on the faith they have for the companies that issue certificates, often trust a certificate if it appears to come from a respected issuer.
In all, 531 counterfeit certificates were issued, and more than 50 common names found in certificates are believed to have been copied by hackers in the DigiNotar case. Among the list of those 50 or so names are Google, Skype, Microsoft, blog-provider Wordpress, Equifax, Mozilla, CA Thawte and WindowsUpdate.
Given the use of common names like Google and Skype, it seems logical that the hackers tried to infiltrate Gmail e-mail accounts and perhaps listen to calls made via Skype. The audit also notes the use of Microsoft.com and WindowsUpdate, which could be used to issue malicious software.
Fox-IT also tracked the certificates and found that most of the online users who were being rerouted to counterfeit sites resided in Iran. [A map of the online usage tracked by Fox-It may be viewed here.]
"It is very likely that people in Iran were going to websites where the fake certificates were installed," says Joost Bij, CISSP and marketing manager at Fox-IT. "A logical explanation is that the government rerouted the traffic from Google and other sites so that they could eavesdrop ... but there is no proof."
3 Lessons Learned
The DigiNotar breach should serve as the proverbial wake-up call, industry experts say.
"For a CA company, your whole business is based on issuing certificates that browsers trust," says Mike Smith, an online security expert at Akamai. "When the browsers took DigiNotar's CAs out of their CA lists, that put them out of business. If all the browsers take the CA certificate out of their lists, then any certificate that DigiNotar signs will not be recognized by the browser. So why would I get a certificate from you if it doesn't work anywhere?"
Among the lessons from the DigiNotar case:
1.Immediate breach notification is a necessity. "Comodo was also hacked, but they announced it right away and people took actions to mitigate the risks of the certificates that were issued fraudulently," says Fox-IT's Bijl. "In the case of DigiNotar, they put their trust in the balance by not telling that they were hacked."
Several weeks passed between the time hackers infiltrated the DigiNotar system in June and when Dutch authorities and browsers were alerted to the problem, after an Iranian user mentioned a fraudulent G-mail certificate on the Google mailing listing, in August. "That was the big issue," Bijl says. "The government publicly revoked trust in DigiNotar and then, quickly thereafter, Google, Firefox, Microsoft and the others revoked their trust, too."
2.Because hacks are unavoidable, heightened security and monitoring are a must. "The problem is not so much that they were hacked, because that can happen," Bijl says. "But the problem is that they did not deal with it on time."
More immediate notification of the breach would have made a difference, obviously. But monitoring and security also posed concerns during the audit. "Disconnecting the core PKI-systems from the Internet is an industry best practice," Bijl says. "Those systems should not have been connected to the Internet."
In the audit, IT-Fox notes the rogue certificate found by Google was issued by the DigiNotar Public CA 2025. But that serial number did not exist in DigiNotar's CA systems records. "This leads to the conclusion that it is unknown how many certificates were issued without any record present," Fox-IT says. To identify unknown certificates, Fox-IT recommended DigiNotar set up monitoring requests.
Those monitoring requests were set up Sept. 1, two months after hackers first hit DigiNotar. It's likely many counterfeits got through.
Fox-IT notes the only way a certificate would be flagged by browser is if the CA sends a response to the browser saying the certificate has been revoked. Even if the serial number of the certificate presented is unknown, unless revoked, the CA response to the browser typically says the certificate is good.
3.The current system is flawed. The good news is: lingering or unknown losses associated with a breach like DigiNotar's are unlikely, since tracking post-breach activity is relatively easy. Unknown serial number requests can be reviewed and analyzed during a post-breach investigation. And when a large number of requests to are linked to a single serial number, that raises a red flag.
The bad news is: The fundamental way certificate approval works is flawed. Most of that trust hinges on the relationship browsers have with certificate issuers. No single enforcement or regulatory body has been charged with setting a standard. "You could reasonably say ICANN [the organization that assigns Internet addresses] could be a body that might take that on, but so far, it's been the CAs policing themselves," says Akamai's Smith. "This is why the DigiNotar thing is so big, because the browser manufacturers are agreeing amongst themselves to block DigiNotar."
DigiNotar Collapse Exposes Fundamental Security Flaws
Tracy Kitten
September 27, 2011
The collapse of Netherlands-based certificate authority DigiNotar raises surprising revelations about fundamental flaws in browsing security practices.
Although not the first certificate authority host to be hacked - Comodo was hit in March - DigiNotar's breach reveals security gaps and gaffes that could have been avoided.
A 13-page audit of DigiNotar conducted by IT security firm Fox-IT notes lax monitoring controls and breach-reporting delays that magnified the compromise. Fox-IT is quick to point out, however, that the audit report does not aim to offer suggestions for improving or changing certificate-issuing practices. Because the investigation into the DigiNotar breach is ongoing, Fox-IT was only willing to comment about facts and findings contained within the report, which is public.
DigiNotar: What Happened
Hackers targeted DigiNotar, like Comodo, to issue counterfeit certificates for common sites such Google and Skype. With these fraudulent certificates, hackers allegedly directed Web users to ghost sites that mimicked those sites users trust.
Under common Internet browsing behavior and standards, it's difficult for the average Web user to spot a counterfeit site. And browsers, based on the faith they have for the companies that issue certificates, often trust a certificate if it appears to come from a respected issuer.
In all, 531 counterfeit certificates were issued, and more than 50 common names found in certificates are believed to have been copied by hackers in the DigiNotar case. Among the list of those 50 or so names are Google, Skype, Microsoft, blog-provider Wordpress, Equifax, Mozilla, CA Thawte and WindowsUpdate.
Given the use of common names like Google and Skype, it seems logical that the hackers tried to infiltrate Gmail e-mail accounts and perhaps listen to calls made via Skype. The audit also notes the use of Microsoft.com and WindowsUpdate, which could be used to issue malicious software.
Fox-IT also tracked the certificates and found that most of the online users who were being rerouted to counterfeit sites resided in Iran. [A map of the online usage tracked by Fox-It may be viewed here.]
"It is very likely that people in Iran were going to websites where the fake certificates were installed," says Joost Bij, CISSP and marketing manager at Fox-IT. "A logical explanation is that the government rerouted the traffic from Google and other sites so that they could eavesdrop ... but there is no proof."
3 Lessons Learned
The DigiNotar breach should serve as the proverbial wake-up call, industry experts say.
"For a CA company, your whole business is based on issuing certificates that browsers trust," says Mike Smith, an online security expert at Akamai. "When the browsers took DigiNotar's CAs out of their CA lists, that put them out of business. If all the browsers take the CA certificate out of their lists, then any certificate that DigiNotar signs will not be recognized by the browser. So why would I get a certificate from you if it doesn't work anywhere?"
Among the lessons from the DigiNotar case:
1.Immediate breach notification is a necessity. "Comodo was also hacked, but they announced it right away and people took actions to mitigate the risks of the certificates that were issued fraudulently," says Fox-IT's Bijl. "In the case of DigiNotar, they put their trust in the balance by not telling that they were hacked."
Several weeks passed between the time hackers infiltrated the DigiNotar system in June and when Dutch authorities and browsers were alerted to the problem, after an Iranian user mentioned a fraudulent G-mail certificate on the Google mailing listing, in August. "That was the big issue," Bijl says. "The government publicly revoked trust in DigiNotar and then, quickly thereafter, Google, Firefox, Microsoft and the others revoked their trust, too."
2.Because hacks are unavoidable, heightened security and monitoring are a must. "The problem is not so much that they were hacked, because that can happen," Bijl says. "But the problem is that they did not deal with it on time."
More immediate notification of the breach would have made a difference, obviously. But monitoring and security also posed concerns during the audit. "Disconnecting the core PKI-systems from the Internet is an industry best practice," Bijl says. "Those systems should not have been connected to the Internet."
In the audit, IT-Fox notes the rogue certificate found by Google was issued by the DigiNotar Public CA 2025. But that serial number did not exist in DigiNotar's CA systems records. "This leads to the conclusion that it is unknown how many certificates were issued without any record present," Fox-IT says. To identify unknown certificates, Fox-IT recommended DigiNotar set up monitoring requests.
Those monitoring requests were set up Sept. 1, two months after hackers first hit DigiNotar. It's likely many counterfeits got through.
Fox-IT notes the only way a certificate would be flagged by browser is if the CA sends a response to the browser saying the certificate has been revoked. Even if the serial number of the certificate presented is unknown, unless revoked, the CA response to the browser typically says the certificate is good.
3.The current system is flawed. The good news is: lingering or unknown losses associated with a breach like DigiNotar's are unlikely, since tracking post-breach activity is relatively easy. Unknown serial number requests can be reviewed and analyzed during a post-breach investigation. And when a large number of requests to are linked to a single serial number, that raises a red flag.
The bad news is: The fundamental way certificate approval works is flawed. Most of that trust hinges on the relationship browsers have with certificate issuers. No single enforcement or regulatory body has been charged with setting a standard. "You could reasonably say ICANN [the organization that assigns Internet addresses] could be a body that might take that on, but so far, it's been the CAs policing themselves," says Akamai's Smith. "This is why the DigiNotar thing is so big, because the browser manufacturers are agreeing amongst themselves to block DigiNotar."
Breach Reported 18 Months Later
Breach Reported 18 Months Later
Online Gambling Site Exposes 2.3 Million Payment Cards
Tracy Kitten
October 6, 2011
The breach of online gambling site Betfair is alarming to banking institutions and security experts because the company waited 18 months to report the incident.
Betfair's systems breach, which occurred in March and April 2010, was not uncovered until this past May, when a server crashed. Now Betfair says cyberattackers likely gained access to the credit and debit details affiliated with 2.3 million customers.
Around 3.15 million usernames also were exposed, as were security questions. And 2.9 million of those usernames had physical addresses associated with them. Approximately 90,000 had bank account details attached.
In its annual report, Betfair notes that it has "experienced a limited number of security breaches in the past (which have not had a significant effect on Betfair's reputation, operations, financial performance and prospects and in respect of which remedial action has been taken)."
The company also says it must comply with data protection and privacy laws in markets where it operates. "If Betfair or any of the third party service providers on which it relies fails to transmit customer information and payment details online in a secure manner or if any such theft or loss of personal customer data were otherwise to occur, Betfair could face liability under data protection laws."
Despite those data-protection laws, Betfair sat on the breach, a decision that is likely to have a more devastating impact in the long run. In fact, cybercrime and identity theft expert Neal O'Farrell says the Betfair breach will become the poster child for how a company completely fails in security and breach response.
"It should also provide fuel for anyone calling for data breach legislation to include criminal sanctions against management teams that respond to a breach in this way," says O'Farrell, founder of the Identity Theft Council. "This was nothing short of a clumsy cover-up."
What Harm?
Betfair says it kept the breach under wraps because it had determined internally that no customer data had been harmed. But this attitude reflects negligence, experts say.
O'Farrell says it's also disappointing that law enforcement may have exacerbated the problem by recommending Betfair not disclose the breach, fearing public knowledge might jeopardize the investigation. "Another reason why law enforcement should not dictate breach response," O'Farrell says.
Gartner analyst Avivah Litan says depending on how transactions are conducted, card information may not have been compromised.
"It's likely that MasterCard and Visa would have detected the breach well before the six-month period transpired," Litan says. But that would only be the case if card issuers noticed fraud or anomalous behavior and notified the card brands. If fraud was detected by other e-commerce retailers and service providers, then it would not likely be reported to MasterCard or Visa.
That said, Litan has more concerns about the breach of personally identifiable information and bank account details. "There is no entity that is looking out for the point-of-compromise of stolen bank accounts, as a matter of practice and routine, as exists with payment cards where Visa, MasterCard and the other card brands have a vested interest in detecting the point of compromise," she says.
Inadequate Security
The deeper concern is that Betfair's security measures for protecting cardholder data and sensitive PII about its users were wholly inadequate.
Kevin Lee, CEO of cloud-based payments security provider CRE Secure, says Betfair does not appear to have adhered to any mandates outlined by the Payment Card Industry Data Security Standard, which call for the encryption of cardholder data during transactions. And if data was being stored, which is not yet clear, that obviously violates PCI's basic tenets as well.
"I'm not what sure happened in this case - how the hackers got in," Lee says. "But we do know that the most common form of hack that gets big chunks of card data is malware," he says. "So, the malware is launched and the business doesn't notice anything different."
Betfair, like a majority of merchants, could have been compliant long enough to pass a PCI audit, but perhaps not maintain that compliance. [See Why Merchants Struggle with PCI.]
Verizon's updated Payment Card Industry Compliance Report showed that of the 100 or so global organizations reviewed, only 21 percent have successfully maintained PCI compliance.
Jen Mack, director of PCI Consulting Services for Verizon, says the need for regular risk assessments is the most striking compliance gap. "Many companies are falling in and out of compliance throughout the year," she says. "And if they fall in an out of compliance throughout the year, they're going to remain targets for hackers."
That gap could be addressed by vendors, through the introduction of security solutions that are easy for the merchants to implement and deploy. But merchants have to bear responsibility when gaps and breaches occur.
Online Gambling Site Exposes 2.3 Million Payment Cards
Tracy Kitten
October 6, 2011
The breach of online gambling site Betfair is alarming to banking institutions and security experts because the company waited 18 months to report the incident.
Betfair's systems breach, which occurred in March and April 2010, was not uncovered until this past May, when a server crashed. Now Betfair says cyberattackers likely gained access to the credit and debit details affiliated with 2.3 million customers.
Around 3.15 million usernames also were exposed, as were security questions. And 2.9 million of those usernames had physical addresses associated with them. Approximately 90,000 had bank account details attached.
In its annual report, Betfair notes that it has "experienced a limited number of security breaches in the past (which have not had a significant effect on Betfair's reputation, operations, financial performance and prospects and in respect of which remedial action has been taken)."
The company also says it must comply with data protection and privacy laws in markets where it operates. "If Betfair or any of the third party service providers on which it relies fails to transmit customer information and payment details online in a secure manner or if any such theft or loss of personal customer data were otherwise to occur, Betfair could face liability under data protection laws."
Despite those data-protection laws, Betfair sat on the breach, a decision that is likely to have a more devastating impact in the long run. In fact, cybercrime and identity theft expert Neal O'Farrell says the Betfair breach will become the poster child for how a company completely fails in security and breach response.
"It should also provide fuel for anyone calling for data breach legislation to include criminal sanctions against management teams that respond to a breach in this way," says O'Farrell, founder of the Identity Theft Council. "This was nothing short of a clumsy cover-up."
What Harm?
Betfair says it kept the breach under wraps because it had determined internally that no customer data had been harmed. But this attitude reflects negligence, experts say.
O'Farrell says it's also disappointing that law enforcement may have exacerbated the problem by recommending Betfair not disclose the breach, fearing public knowledge might jeopardize the investigation. "Another reason why law enforcement should not dictate breach response," O'Farrell says.
Gartner analyst Avivah Litan says depending on how transactions are conducted, card information may not have been compromised.
"It's likely that MasterCard and Visa would have detected the breach well before the six-month period transpired," Litan says. But that would only be the case if card issuers noticed fraud or anomalous behavior and notified the card brands. If fraud was detected by other e-commerce retailers and service providers, then it would not likely be reported to MasterCard or Visa.
That said, Litan has more concerns about the breach of personally identifiable information and bank account details. "There is no entity that is looking out for the point-of-compromise of stolen bank accounts, as a matter of practice and routine, as exists with payment cards where Visa, MasterCard and the other card brands have a vested interest in detecting the point of compromise," she says.
Inadequate Security
The deeper concern is that Betfair's security measures for protecting cardholder data and sensitive PII about its users were wholly inadequate.
Kevin Lee, CEO of cloud-based payments security provider CRE Secure, says Betfair does not appear to have adhered to any mandates outlined by the Payment Card Industry Data Security Standard, which call for the encryption of cardholder data during transactions. And if data was being stored, which is not yet clear, that obviously violates PCI's basic tenets as well.
"I'm not what sure happened in this case - how the hackers got in," Lee says. "But we do know that the most common form of hack that gets big chunks of card data is malware," he says. "So, the malware is launched and the business doesn't notice anything different."
Betfair, like a majority of merchants, could have been compliant long enough to pass a PCI audit, but perhaps not maintain that compliance. [See Why Merchants Struggle with PCI.]
Verizon's updated Payment Card Industry Compliance Report showed that of the 100 or so global organizations reviewed, only 21 percent have successfully maintained PCI compliance.
Jen Mack, director of PCI Consulting Services for Verizon, says the need for regular risk assessments is the most striking compliance gap. "Many companies are falling in and out of compliance throughout the year," she says. "And if they fall in an out of compliance throughout the year, they're going to remain targets for hackers."
That gap could be addressed by vendors, through the introduction of security solutions that are easy for the merchants to implement and deploy. But merchants have to bear responsibility when gaps and breaches occur.
Friday, September 23, 2011
The key to data security: Separation of duties
The key to data security: Separation of duties
This control works in finance, and it will work in information security
Kevin Coleman
August 27, 2008 (CSO)
Separation of duties is a key concept of internal controls. This objective is achieved by disseminating the tasks and associated privileges for a specific security process among multiple people.
The term SoD is widely used in financial accounting systems. Companies in all sizes understand the importance of not combining roles such as receiving checks (payment on account), approving write-offs, depositing cash and reconciling bank statements, approving time cards, and having custody of paychecks.
Separation of duties is a common policy when people are handling money so that fraud requires collusion of two or more parties. This greatly reduces the likelihood of crime. Information should be handled in the same way. It is therefore imperative that an organization be designed so that no person acting alone can compromise security controls.
SoD is fairly new to the IT organization, but it's not a surprise that concerns are being raised about separation of duties in IT given that a very high portion of Sarbanes-Oxley Act internal control issues come from or rely on IT. Separation of duties is a fundamental principle of many regulatory mandates such as Sarbanes-Oxley and the Gramm-Leach-Bliley Act. As a result, IT organizations must now place greater emphasis on separation of duties across all IT functions, especially security.
Separation of duties, as it relates to security, has two primary objectives. The first is the prevention of conflict of interest, the appearance of conflict of interest, wrongful acts, fraud, abuse and errors. The second is the detection of control failures that include security breaches, information theft and circumvention of security controls. (Security controls are measures taken to safeguard an information system from attacks against the confidentiality, integrity and availability of computer systems, networks and the data they use.)
Separation of duties restricts the amount of power or influence held by any individual. It also ensures that people don't have conflicting responsibilities and are not responsible for reporting on themselves or their superiors.
There is an easy test for separation of duties. First, ask if any one person can alter or destroy your financial data without being detected. Then ask if any one person can steal or exfiltrate sensitive information. Finally, ask if any one person has influence over controls design and implementation as well as over reporting of the effectiveness of the controls. If the answer to any of these questions is yes, then you need to take a hard look at the separation of duties.
The individual responsible for designing and implementing security can't be the same person as the person responsible for testing security, conducting security audits, or monitoring and reporting on security. Therefore, the individual responsible for information security should not report to the chief information officer.
There are five primary options for achieving separation of duties in information security. This list is in order of acceptability based on my experience.
Option 1: Have the individual responsible for information security report to chief security officer, who takes care of information and physical security. Have the CSO report directly to CEO.
Option 2: Have the individual responsible for information security report to chairman of the audit committee.
Option 3: Use a third party to monitor security, perform surprise security audits and do security testing, and have that party report to the board of directors or the chairman of the audit committee.
Option 4: Have the individual responsible for information security report to the board of directors.
Option 5: Have the individual responsible for information security report to internal audit as long as internal audit does not report to the executive in charge of finances.
The issue of separation of duties is growing in importance. A lack of clear and concise responsibilities for the CSO and chief information security officer has fueled confusion. It is imperative that there be separation between the development, operation and testing of security and all controls. Responsibilities must be assigned to individuals in such a way as to establish checks and balances within the system and minimize the opportunity for unauthorized access and fraud.
Remember, control techniques surrounding separation of duties are subject to review by external auditors. Auditors have in the past listed SoD failures as a material deficiency on audit reports when they determine the risks are great enough. It is just a matter of time before this is done for IT security, so why not have a discussion about separation of duties with your external auditors now? Getting their views early can save you a lot of cost and political infighting.
This control works in finance, and it will work in information security
Kevin Coleman
August 27, 2008 (CSO)
Separation of duties is a key concept of internal controls. This objective is achieved by disseminating the tasks and associated privileges for a specific security process among multiple people.
The term SoD is widely used in financial accounting systems. Companies in all sizes understand the importance of not combining roles such as receiving checks (payment on account), approving write-offs, depositing cash and reconciling bank statements, approving time cards, and having custody of paychecks.
Separation of duties is a common policy when people are handling money so that fraud requires collusion of two or more parties. This greatly reduces the likelihood of crime. Information should be handled in the same way. It is therefore imperative that an organization be designed so that no person acting alone can compromise security controls.
SoD is fairly new to the IT organization, but it's not a surprise that concerns are being raised about separation of duties in IT given that a very high portion of Sarbanes-Oxley Act internal control issues come from or rely on IT. Separation of duties is a fundamental principle of many regulatory mandates such as Sarbanes-Oxley and the Gramm-Leach-Bliley Act. As a result, IT organizations must now place greater emphasis on separation of duties across all IT functions, especially security.
Separation of duties, as it relates to security, has two primary objectives. The first is the prevention of conflict of interest, the appearance of conflict of interest, wrongful acts, fraud, abuse and errors. The second is the detection of control failures that include security breaches, information theft and circumvention of security controls. (Security controls are measures taken to safeguard an information system from attacks against the confidentiality, integrity and availability of computer systems, networks and the data they use.)
Separation of duties restricts the amount of power or influence held by any individual. It also ensures that people don't have conflicting responsibilities and are not responsible for reporting on themselves or their superiors.
There is an easy test for separation of duties. First, ask if any one person can alter or destroy your financial data without being detected. Then ask if any one person can steal or exfiltrate sensitive information. Finally, ask if any one person has influence over controls design and implementation as well as over reporting of the effectiveness of the controls. If the answer to any of these questions is yes, then you need to take a hard look at the separation of duties.
The individual responsible for designing and implementing security can't be the same person as the person responsible for testing security, conducting security audits, or monitoring and reporting on security. Therefore, the individual responsible for information security should not report to the chief information officer.
There are five primary options for achieving separation of duties in information security. This list is in order of acceptability based on my experience.
Option 1: Have the individual responsible for information security report to chief security officer, who takes care of information and physical security. Have the CSO report directly to CEO.
Option 2: Have the individual responsible for information security report to chairman of the audit committee.
Option 3: Use a third party to monitor security, perform surprise security audits and do security testing, and have that party report to the board of directors or the chairman of the audit committee.
Option 4: Have the individual responsible for information security report to the board of directors.
Option 5: Have the individual responsible for information security report to internal audit as long as internal audit does not report to the executive in charge of finances.
The issue of separation of duties is growing in importance. A lack of clear and concise responsibilities for the CSO and chief information security officer has fueled confusion. It is imperative that there be separation between the development, operation and testing of security and all controls. Responsibilities must be assigned to individuals in such a way as to establish checks and balances within the system and minimize the opportunity for unauthorized access and fraud.
Remember, control techniques surrounding separation of duties are subject to review by external auditors. Auditors have in the past listed SoD failures as a material deficiency on audit reports when they determine the risks are great enough. It is just a matter of time before this is done for IT security, so why not have a discussion about separation of duties with your external auditors now? Getting their views early can save you a lot of cost and political infighting.