Monday, February 04, 2008
Computer security problems found at IRS
Computer security problems found at IRS
Employees provided computer data without questioning identity
By Jim Abrams
The Associated Press
updated 10:53 a.m. CT, Fri., Aug. 3, 2007
WASHINGTON - IRS employees ignored security rules and turned over sensitive computer information to a caller posing as a technical support person, according to a government study.
Sixty-one of the 102 people who got the test calls, including managers and a contractor, complied with a request that the employee provide his or her user name and temporarily change his or her password to one the caller suggested, according to the Treasury Inspector General for Tax Administration, an office that does oversight of Internal Revenue Service.
The caller asked for assistance to correct a computer problem.
The report said that by failing to question the identity of the caller the employees were putting the IRS at risk of providing unauthorized people access to taxpayer data that could be used for identity theft and other fraudulent schemes.
"This is especially disturbing because the IRS has taken many steps to raise employee awareness of the importance of protecting their computers and passwords," said Inspector General J. Russell George.
Only eight of the 102 employees contacted either the inspector general's office or IRS security offices to validate the legitimacy of the caller.
The report said the IRS took measures to improve security after two similar test telephone calls in 2001 and 2004. "However, the corrective actions have not been effective," it said.
The IRS agreed with recommendations from the inspector general that it should take steps to make employees more aware of hacker tactics such as posing as an internal employee and to remind people to report such incidents to security officials.
The IRS has nearly 100,000 employees and contractors with access to tax return information processed on about 240 computer systems and more than 1,500 databases.
Employees provided computer data without questioning identity
By Jim Abrams
The Associated Press
updated 10:53 a.m. CT, Fri., Aug. 3, 2007
WASHINGTON - IRS employees ignored security rules and turned over sensitive computer information to a caller posing as a technical support person, according to a government study.
Sixty-one of the 102 people who got the test calls, including managers and a contractor, complied with a request that the employee provide his or her user name and temporarily change his or her password to one the caller suggested, according to the Treasury Inspector General for Tax Administration, an office that does oversight of Internal Revenue Service.
The caller asked for assistance to correct a computer problem.
The report said that by failing to question the identity of the caller the employees were putting the IRS at risk of providing unauthorized people access to taxpayer data that could be used for identity theft and other fraudulent schemes.
"This is especially disturbing because the IRS has taken many steps to raise employee awareness of the importance of protecting their computers and passwords," said Inspector General J. Russell George.
Only eight of the 102 employees contacted either the inspector general's office or IRS security offices to validate the legitimacy of the caller.
The report said the IRS took measures to improve security after two similar test telephone calls in 2001 and 2004. "However, the corrective actions have not been effective," it said.
The IRS agreed with recommendations from the inspector general that it should take steps to make employees more aware of hacker tactics such as posing as an internal employee and to remind people to report such incidents to security officials.
The IRS has nearly 100,000 employees and contractors with access to tax return information processed on about 240 computer systems and more than 1,500 databases.
Labels: IRS
Surge in U.S., Canadian Bank Hacking Incidents
Surge in U.S., Canadian Bank Hacking Incidents
PR Newswire
Aug 07 2007 : North American banks experienced an 81 percent increase in hacking attacks in the first six months of 2007 versus the last six months of 2006, according to U.S-based IT security firm SecureWorks. During the same period, hacking attacks against North American credit unions rose by 62 percent.
SecureWorks’ data is based on actual attacks against its North American banking and credit union clients. "In June 2006 to December of 2006, we were blocking attacks from approximately 808 hackers per bank per month," Allen Wilson, VP of Research for SecureWorks, says in a statement. "Since the beginning of 2007 up until June, the average number of hackers launching attacks at each of our banks is 1,462.”
A SecureWorks spokesperson tells ePaynews that attacks against financial institutions outside North America are also likely to have increased between the last half of 2006 and the first six months of 2007.
Wilson said that in the last half of 2006, SecureWorks was blocking attacks against its North American credit union clients from 1,110 hackers per credit union per month. “That number has risen to 1,799 hackers per credit union per month," he says.
In the last 30 days alone, SecureWorks blocked a total of 167 million hacker attacks against banks and credit unions, the company says.
"Most of the hackers we see stealing financial data are located in Russia and Eastern Europe,” Wilson says. “However, we are witnessing a growing number coming out of China. These countries have large numbers of talented young people who are extremely computer literate.”
According to Wilson, hackers are attracted by the minimal risks that they face in perpetrating crimes against financial institutions.
"The amount of stolen financial data we have found since the first of the year has been daunting," Don Jackson, a security researcher for SecureWorks, says. "We are finding new caches of stolen data everyday, evidence that more andmore criminals are getting into the game." According to Johnson, these data caches contained thousands of bank account and credit card numbers, social security numbers, online payment accounts and user names and passwords.
PR Newswire
Aug 07 2007 : North American banks experienced an 81 percent increase in hacking attacks in the first six months of 2007 versus the last six months of 2006, according to U.S-based IT security firm SecureWorks. During the same period, hacking attacks against North American credit unions rose by 62 percent.
SecureWorks’ data is based on actual attacks against its North American banking and credit union clients. "In June 2006 to December of 2006, we were blocking attacks from approximately 808 hackers per bank per month," Allen Wilson, VP of Research for SecureWorks, says in a statement. "Since the beginning of 2007 up until June, the average number of hackers launching attacks at each of our banks is 1,462.”
A SecureWorks spokesperson tells ePaynews that attacks against financial institutions outside North America are also likely to have increased between the last half of 2006 and the first six months of 2007.
Wilson said that in the last half of 2006, SecureWorks was blocking attacks against its North American credit union clients from 1,110 hackers per credit union per month. “That number has risen to 1,799 hackers per credit union per month," he says.
In the last 30 days alone, SecureWorks blocked a total of 167 million hacker attacks against banks and credit unions, the company says.
"Most of the hackers we see stealing financial data are located in Russia and Eastern Europe,” Wilson says. “However, we are witnessing a growing number coming out of China. These countries have large numbers of talented young people who are extremely computer literate.”
According to Wilson, hackers are attracted by the minimal risks that they face in perpetrating crimes against financial institutions.
"The amount of stolen financial data we have found since the first of the year has been daunting," Don Jackson, a security researcher for SecureWorks, says. "We are finding new caches of stolen data everyday, evidence that more andmore criminals are getting into the game." According to Johnson, these data caches contained thousands of bank account and credit card numbers, social security numbers, online payment accounts and user names and passwords.
Labels: Canadian Banks
TD Ameritrade Breach Affects 6.3M Customers
TD Ameritrade Breach Affects 6.3M Customers
Brokerage firm uncovers data-sucking malware during system audit
SEPTEMBER 14, 2007 | 3:42 PM
By Tim Wilson
Site Editor, Dark Reading
Malware found on an internal database may have allowed spammers to steal names, addresses, phone numbers, and email addresses from as many as 6.3 million customers of TD Ameritrade, the brokerage firm revealed today.
In a press release, TD Ameritrade this morning confirmed reports that it has been informing customers of a potential security breach. The release does not confirm the figure of 6.3 million customers, but a company spokesperson did give that number to reporters in interviews.
The company uncovered the malicious code in one of its databases during an audit, which is part of a stock spam investigation. Sources familiar with the breach said the code is not unlike the code used to steal data on 1.3 million users at Monster.com.
TD Ameritrade has not closed its investigation, but early results indicate that the attack was designed not to penetrate users' accounts, but to collect addresses for spam campaigns. In addition to names and email addresses, the breached database also contains Social Security numbers, account numbers, and dates of birth, but there is no indication that the thieves stole any of this latter information, the brokerage firm said.
TD Ameritrade customers' user IDs, PINs, and passwords are stored in a separate database that was not penetrated in this attack, according to the company.
"While the financial assets our clients hold with us were never touched, and there is no evidence that our clients' Social Security numbers were taken, we understand that this issue has increased unwanted SPAM, which is annoying and inconvenient for them," said Joe Moglia, CEO of TD Ameritrade. "We sincerely apologize for that and any added concern this may have caused."
TD Ameritrade hired a third party, ID Analytics Inc., to investigate and monitor for potential identity theft. An initial evaluation by ID Analytics found no evidence of identity theft.
The brokerage firm says it is confident that it has identified the method in which the information was stolen and has taken the appropriate steps to prevent it from recurring.
"This issue is not unique to TD Ameritrade. It's something that all companies involved in e-commerce should be aware of and prepared to address," Moglia said. "We participate in industry peer groups to share information on these types of threats in the interest of protecting all clients."
A spokesperson declined to give further information on the malware, or how it penetrated the TD Ameritrade, until the investigation is complete.
Brokerage firm uncovers data-sucking malware during system audit
SEPTEMBER 14, 2007 | 3:42 PM
By Tim Wilson
Site Editor, Dark Reading
Malware found on an internal database may have allowed spammers to steal names, addresses, phone numbers, and email addresses from as many as 6.3 million customers of TD Ameritrade, the brokerage firm revealed today.
In a press release, TD Ameritrade this morning confirmed reports that it has been informing customers of a potential security breach. The release does not confirm the figure of 6.3 million customers, but a company spokesperson did give that number to reporters in interviews.
The company uncovered the malicious code in one of its databases during an audit, which is part of a stock spam investigation. Sources familiar with the breach said the code is not unlike the code used to steal data on 1.3 million users at Monster.com.
TD Ameritrade has not closed its investigation, but early results indicate that the attack was designed not to penetrate users' accounts, but to collect addresses for spam campaigns. In addition to names and email addresses, the breached database also contains Social Security numbers, account numbers, and dates of birth, but there is no indication that the thieves stole any of this latter information, the brokerage firm said.
TD Ameritrade customers' user IDs, PINs, and passwords are stored in a separate database that was not penetrated in this attack, according to the company.
"While the financial assets our clients hold with us were never touched, and there is no evidence that our clients' Social Security numbers were taken, we understand that this issue has increased unwanted SPAM, which is annoying and inconvenient for them," said Joe Moglia, CEO of TD Ameritrade. "We sincerely apologize for that and any added concern this may have caused."
TD Ameritrade hired a third party, ID Analytics Inc., to investigate and monitor for potential identity theft. An initial evaluation by ID Analytics found no evidence of identity theft.
The brokerage firm says it is confident that it has identified the method in which the information was stolen and has taken the appropriate steps to prevent it from recurring.
"This issue is not unique to TD Ameritrade. It's something that all companies involved in e-commerce should be aware of and prepared to address," Moglia said. "We participate in industry peer groups to share information on these types of threats in the interest of protecting all clients."
A spokesperson declined to give further information on the malware, or how it penetrated the TD Ameritrade, until the investigation is complete.
Labels: TD Ameritrade Holding Corp.
What Not to Do After a Security Breach
What Not to Do After a Security Breach
Expert familiar with TD Ameritrade, TJX cases discusses the mistakes enterprises often make following a breach
OCTOBER 26, 2007 | 4:00 PM
By Kelly Jackson Higgins
Senior Editor, Dark Reading
Step number one after a security breach: Don't immediately bring in the outside forensics team --- get your attorney up to speed on the attack first. And don't assume just because you had a break-in that you have to disclose it publicly -- it all depends on whether data covered under regulatory mandates was exposed.
These are two bits of advice to the security-breached from Kevin Mandia, a forensics expert who has worked on the front line of the TD Ameritrade investigation and is serving as an expert in the TJX breach case. Mandia will testify as an expert witness for the credit- and debit-card issuers if the TJX case goes to trial.
Mandia takes a different view than some breach experts, who encourage enterprises to make swift disclosure of suspected breaches. (See What to Do When Your Security's Breached.)
"Only 'the need to know' should be 'in the know,'" says Mandia, CEO of Mandiant, who for the past 15 years has worked on over 100 computer security breaches with the Fortune 500, FBI, and military. He's seen a lot of mistakes made by victims over the years, he says, as well as major shifts in how companies must respond in today's regulatory and disclosure environment.
Mandia, who couldn't comment directly on the Ameritrade or TJX cases, says over half of the cases that his firm responds to don't actually require public disclosure at all. "This happens a lot -- a database gets compromised and the systems admin pushes back his chair and says 'our database has been compromised,' and the rumor mill starts," he says. "Even if there's no 'covered' [regulated] data on the database, people start talking about it, the Wall Street Journal [reports it]."
"I still believe that in over 50 percent of the [incidents] we respond to, disclosure is not required," Mandia says. "Even if there's 'covered' data in the system, it could be encrypted, for instance, and it's unreasonable to think it was compromised."
Attorney-client privilege goes a long way. "The need for counsel is one of the biggest changes I've seen in incident response in the past two years," he says. "But it's very important to have counsel involved before we are -- for attorney-client privilege."
Another big misstep is misjudging whether sensitive data covered by regulatory requirements has been breached. "If I have a computer that's been compromised, I don't have to disclose that my computer has been breached," says Mandia, who will be presenting some of his findings in forensic investigations at the SecTor security conference in Toronto next month. Only if the data that falls under HIPAA, SOX, PCI, FTC safeguards, and state privacy laws, for instance, has been breached, he says.
Typically, the IT or security technicians in the trenches have to respond and provide their opinions to upper management and counsel on whether data was exposed. "The biggest challenge is technicians are not very good with gray areas, and they're not suited for making opinions" on this, he says. "It's actually better for a layperson to do it."
Another common error companies make is assuming that the attack was an inside job, and focusing only on that attack vector. "Nine of out 10 think it's an insider... that there's no way their crown jewels could be compromised [by an outsider]," Mandia says. "The catch is that insider investigations are 10 times more costly than external ones because [they must work] surreptitiously -- it's us versus us."
So it can take months to investigate, and it may be all for naught if the breach actually came from outside, he says. Not to mention lost time in catching the real perpetrators on the outside. "Firms need to move as fast as they can for the first five days... If they do that, they are more successful," he says. "But most are making their decisions too damn slowly."
Part of the problem is in most cases, there isn't just one "owner" of the incident response in an organization. The internal investigation often has people going off in different directions and not coordinating their findings, which leads to mistakes and inefficiencies. "You need one guy who handles it appropriately and has enough clout to be a leader," Mandia says. "It needs to be someone no less than two rungs from the top."
Meanwhile, the process of forensic data collection has changed: Due to the nature of today's malware, companies now must also acquire and analyze system memory as well during their investigations, he says. "You have to inspect within the memory," he says.
And most organizations today are running in fear of kernel-level rootkits, he says. "Everyone is chasing that ghost, although they are not finding a lot of them," he says. "Everyone wants to do rootkit detection when responding" to a breach, he says.
The attack techniques, however, are basically same old, same old, he says. "The vulnerabilities are generally going to be in Office and PowerPoint and they are still coming in via email," he says, and users are still being duped into clicking infected attachments with trojans and keyloggers, for instance.
Expert familiar with TD Ameritrade, TJX cases discusses the mistakes enterprises often make following a breach
OCTOBER 26, 2007 | 4:00 PM
By Kelly Jackson Higgins
Senior Editor, Dark Reading
Step number one after a security breach: Don't immediately bring in the outside forensics team --- get your attorney up to speed on the attack first. And don't assume just because you had a break-in that you have to disclose it publicly -- it all depends on whether data covered under regulatory mandates was exposed.
These are two bits of advice to the security-breached from Kevin Mandia, a forensics expert who has worked on the front line of the TD Ameritrade investigation and is serving as an expert in the TJX breach case. Mandia will testify as an expert witness for the credit- and debit-card issuers if the TJX case goes to trial.
Mandia takes a different view than some breach experts, who encourage enterprises to make swift disclosure of suspected breaches. (See What to Do When Your Security's Breached.)
"Only 'the need to know' should be 'in the know,'" says Mandia, CEO of Mandiant, who for the past 15 years has worked on over 100 computer security breaches with the Fortune 500, FBI, and military. He's seen a lot of mistakes made by victims over the years, he says, as well as major shifts in how companies must respond in today's regulatory and disclosure environment.
Mandia, who couldn't comment directly on the Ameritrade or TJX cases, says over half of the cases that his firm responds to don't actually require public disclosure at all. "This happens a lot -- a database gets compromised and the systems admin pushes back his chair and says 'our database has been compromised,' and the rumor mill starts," he says. "Even if there's no 'covered' [regulated] data on the database, people start talking about it, the Wall Street Journal [reports it]."
"I still believe that in over 50 percent of the [incidents] we respond to, disclosure is not required," Mandia says. "Even if there's 'covered' data in the system, it could be encrypted, for instance, and it's unreasonable to think it was compromised."
Attorney-client privilege goes a long way. "The need for counsel is one of the biggest changes I've seen in incident response in the past two years," he says. "But it's very important to have counsel involved before we are -- for attorney-client privilege."
Another big misstep is misjudging whether sensitive data covered by regulatory requirements has been breached. "If I have a computer that's been compromised, I don't have to disclose that my computer has been breached," says Mandia, who will be presenting some of his findings in forensic investigations at the SecTor security conference in Toronto next month. Only if the data that falls under HIPAA, SOX, PCI, FTC safeguards, and state privacy laws, for instance, has been breached, he says.
Typically, the IT or security technicians in the trenches have to respond and provide their opinions to upper management and counsel on whether data was exposed. "The biggest challenge is technicians are not very good with gray areas, and they're not suited for making opinions" on this, he says. "It's actually better for a layperson to do it."
Another common error companies make is assuming that the attack was an inside job, and focusing only on that attack vector. "Nine of out 10 think it's an insider... that there's no way their crown jewels could be compromised [by an outsider]," Mandia says. "The catch is that insider investigations are 10 times more costly than external ones because [they must work] surreptitiously -- it's us versus us."
So it can take months to investigate, and it may be all for naught if the breach actually came from outside, he says. Not to mention lost time in catching the real perpetrators on the outside. "Firms need to move as fast as they can for the first five days... If they do that, they are more successful," he says. "But most are making their decisions too damn slowly."
Part of the problem is in most cases, there isn't just one "owner" of the incident response in an organization. The internal investigation often has people going off in different directions and not coordinating their findings, which leads to mistakes and inefficiencies. "You need one guy who handles it appropriately and has enough clout to be a leader," Mandia says. "It needs to be someone no less than two rungs from the top."
Meanwhile, the process of forensic data collection has changed: Due to the nature of today's malware, companies now must also acquire and analyze system memory as well during their investigations, he says. "You have to inspect within the memory," he says.
And most organizations today are running in fear of kernel-level rootkits, he says. "Everyone is chasing that ghost, although they are not finding a lot of them," he says. "Everyone wants to do rootkit detection when responding" to a breach, he says.
The attack techniques, however, are basically same old, same old, he says. "The vulnerabilities are generally going to be in Office and PowerPoint and they are still coming in via email," he says, and users are still being duped into clicking infected attachments with trojans and keyloggers, for instance.
Labels: TD Ameritrade Holding Corp., TJX Companies Inc.
What to do when your securities breached.
What to Do When Your Security's Breached
Experts offer a quick primer on how to respond to security incidents – and how not to
MARCH 23, 2007 | Well, it's finally happened. Despite all your efforts to stop both internal and external attackers, someone has penetrated your defenses and stolen or damaged your data.
You've got a full-blown security incident on your hands. What are you going to do about it?
If you've been smart, experts say, you'll already have a computer security incident response team -- and a plan -- in place. You'll even have tested the team and plan in some sort of live simulation.
But many companies are too resource-stretched -- or too small -- to have a full-blown, fully-tested incident response strategy. Others don't have top executives who are forward-thinking enough to approve the development of such a plan. What happens then? Is there an "in case of fire, break glass" answer?
Not exactly, experts say. But if you've discovered a potential security breach, there are some steps you can take to stop the threat and seal it off. Just as importantly, there's some advice on what not to do, so that you can protect the "crime scene" and preserve your chances of catching the crooks.
The following are six steps you should take if you encounter a possible security breach. Some experts recommend eight, some have 10, but these are the ones that most authorities agree on. Oh, and they also agree on this: You should have done the first three steps before you had the breach.
1. Assemble an incident response team.
Before you can do anything, you need to make sure you have the right people in the room. A security breach typically isn't handled only by the IT department -- it may involve legal experts, top executives, public relations people, and representatives from all of the business lines affected. If the breach involves insiders, you may need someone from human resources. If it involves money, you may need a financial officer.
One of the biggest mistakes companies make is allowing one "cowboy" to handle an incident alone, says Brian Contos, CTO of ArcSight and author of Enemy at the Water Cooler, a book that analyzes many real-life computer incidents. "There's always one person that steps up and thinks they can take it on, but critical incidents usually need the attention of the whole group."
Ultimately, the computer security incident response team (CSIRT) -- including external consultants or forensics experts -- should be selected prior to an event, experts say. And the teams may vary according to the nature of the incident. If you don't already have a team in place, choose it quick, and make sure all the stakeholders are there.
2. Assess the initial damage and the risk for more.
Your response to a security breach will be commensurate with the risks to your business. An external attack on your public Website might not hurt much if you're a local machine shop, but it can break your business if you're Amazon.com. Likewise, an insider attack on the personnel database carries a different type of impact than the theft of a customer database.
According to BackGrounD Software, a Canadian forensics firm that does security breach damage assessment, the costs of a breach should include not only the technical costs associated with finding and fixing the breach, but also loss of productivity and loss of business. You'll need a plan that not only outlines your strategy for recovering your systems, but that includes steps for recovering customers.
Indeed, brand loss can be the most damaging element in a customer-facing breach, experts say. In a study published earlier this month, Javelin Strategy and Research reported that 78 percent of consumers would stop shopping with a retailer that lost or compromised their data. (See Banks, Retailers Seek to Regain User Trust.)
Next Page: Page Two
What to Do When Your Security's Breached
MARCH 23, 2007 | 3. Develop a notification plan.
Now that your team has a grip on the incident and its potential impact, you need to decide who to tell, and in what order. If a potential crime has been committed, law enforcement might be one of your first calls. If you are planning to bring in third-party consultants, such as security experts or a computer forensics firm, you should bring them in as early as possible.
Notifying employees may require some training, experts say. You'll have to tell them how their systems may be impacted, and what to do -- or not do -- to protect them. You'll have to tell them what they can and can't say to customers or others outside the company.
"When the breach comes from some hacker in Romania, this process is pretty simple," Contos observes. "But when you suspect it's your boss who's the leak, it's a lot more difficult. Who you tell and when you tell them can make a difference in whether you're able to quickly find and fix the problem."
Most states today have specific deadlines for informing customers and others who may be affected by the breach. In most cases, these laws allow up to 30 days for disclosure, so in most cases, you will have time to work on the problem before you make a public statement.
4. Begin remediating the problem.
Experts can never stress it enough: Never begin remediation until you fully understand the problem and its potential impact. Many experts say you shouldn't touch anything until a forensics team has been called in, lest you damage the evidence or make the problem worse.
But if the breach is actively hurting your business, this rule of thumb may not make sense. In some cases, you will want to unplug the servers or storage systems that are being infected or penetrated in order to limit the damage. In the case of an Internet-borne breach, turning off Port 80 might help.
"Disconnect your server(s) from the network," recommends BackGrounD Software. "If there is a potentially malicious code running, disconnect media devices as quickly as possible (i.e. disks, SAN, NAS). You never know how far the intruder has managed to get, so the faster you disconnect the equipment, the more of a chance you have to save your data."
After that, however, the steps you should take will depend on the skills you have in house. "For a small company, I would say hold on and wait for the experts," Contos says. "But a large enterprise could have people trained to handle this sort of incident. It's a skill set. You can learn it." Some companies, such as Target, maintain a fully-trained forensics staff that may even be offered to other companies, he observes.
Some problems don't immediately present themselves as security incidents, and IT staff may have already treated them with everyday troubleshooting measures. "It's not like there's a special beeper that goes off when it's security-related," Contos notes. "The key is that when you realize it's a security problem, you stop and consider what you're doing. Don't keep making configuration changes."
5. Document everything.
Lack of documentation can not only make it difficult to rebuild your systems after an incident -- it can also hurt your chances to make a case against an attacker in court, experts say. Throughout the assessment and remediation process, you should record everything, from how the incident was first detected to how the various members of the CSIRT team responded.
In some cases -- particularly in the case of attacks from outside the company -- the documentation will be done automatically, through log files from firewalls, IDS/IPS systems, and/or security information management tools. These tools should record the intrusion, the subsequent infections or downloads, and the configuration changes that were made to halt the attack.
Insider attacks are a different story. "In a lot of cases, an insider attack isn't detected initially through traditional security tools, but because someone noticed unusual or suspicious behavior," Contos says. In these cases, it's important to document the reports and log the behavior in addition to using monitoring tools to track computer activity, he advises.
Experts agree that documentation is one of the most frequently overlooked and difficult tasks to execute during a security incident. In many cases, the players don't have time to record what they're doing, or don't feel it's important. In the end, however, the documentation can be the key to reconstituting systems that have been rewired to stop an incident -- or to making a legal case against an intruder.
6. Develop a strategy for stopping the next attack.
Doing a post-mortem on a security incident -- or developing a plan for responding to the next one -- may seem like longer-term activities. But if one attacker finds a vulnerability, there's a good chance that he may have accomplices -- or that another attacker might find the same vulnerability.
It's not unusual for attacks to come in bunches, so it's important to permanently seal off your leaks and decide how you will alter your response process if an incident occurs again, experts say.
"Review what you've done and decide how you could have done it better," Contos says. "More importantly, consider all of the subsequent risks and, if you don't already have plans in place, get them in place. If you had trouble getting top management to listen before, you won't now."
— Tim Wilson, Site Editor, Dark Reading
Experts offer a quick primer on how to respond to security incidents – and how not to
MARCH 23, 2007 | Well, it's finally happened. Despite all your efforts to stop both internal and external attackers, someone has penetrated your defenses and stolen or damaged your data.
You've got a full-blown security incident on your hands. What are you going to do about it?
If you've been smart, experts say, you'll already have a computer security incident response team -- and a plan -- in place. You'll even have tested the team and plan in some sort of live simulation.
But many companies are too resource-stretched -- or too small -- to have a full-blown, fully-tested incident response strategy. Others don't have top executives who are forward-thinking enough to approve the development of such a plan. What happens then? Is there an "in case of fire, break glass" answer?
Not exactly, experts say. But if you've discovered a potential security breach, there are some steps you can take to stop the threat and seal it off. Just as importantly, there's some advice on what not to do, so that you can protect the "crime scene" and preserve your chances of catching the crooks.
The following are six steps you should take if you encounter a possible security breach. Some experts recommend eight, some have 10, but these are the ones that most authorities agree on. Oh, and they also agree on this: You should have done the first three steps before you had the breach.
1. Assemble an incident response team.
Before you can do anything, you need to make sure you have the right people in the room. A security breach typically isn't handled only by the IT department -- it may involve legal experts, top executives, public relations people, and representatives from all of the business lines affected. If the breach involves insiders, you may need someone from human resources. If it involves money, you may need a financial officer.
One of the biggest mistakes companies make is allowing one "cowboy" to handle an incident alone, says Brian Contos, CTO of ArcSight and author of Enemy at the Water Cooler, a book that analyzes many real-life computer incidents. "There's always one person that steps up and thinks they can take it on, but critical incidents usually need the attention of the whole group."
Ultimately, the computer security incident response team (CSIRT) -- including external consultants or forensics experts -- should be selected prior to an event, experts say. And the teams may vary according to the nature of the incident. If you don't already have a team in place, choose it quick, and make sure all the stakeholders are there.
2. Assess the initial damage and the risk for more.
Your response to a security breach will be commensurate with the risks to your business. An external attack on your public Website might not hurt much if you're a local machine shop, but it can break your business if you're Amazon.com. Likewise, an insider attack on the personnel database carries a different type of impact than the theft of a customer database.
According to BackGrounD Software, a Canadian forensics firm that does security breach damage assessment, the costs of a breach should include not only the technical costs associated with finding and fixing the breach, but also loss of productivity and loss of business. You'll need a plan that not only outlines your strategy for recovering your systems, but that includes steps for recovering customers.
Indeed, brand loss can be the most damaging element in a customer-facing breach, experts say. In a study published earlier this month, Javelin Strategy and Research reported that 78 percent of consumers would stop shopping with a retailer that lost or compromised their data. (See Banks, Retailers Seek to Regain User Trust.)
Next Page: Page Two
What to Do When Your Security's Breached
MARCH 23, 2007 | 3. Develop a notification plan.
Now that your team has a grip on the incident and its potential impact, you need to decide who to tell, and in what order. If a potential crime has been committed, law enforcement might be one of your first calls. If you are planning to bring in third-party consultants, such as security experts or a computer forensics firm, you should bring them in as early as possible.
Notifying employees may require some training, experts say. You'll have to tell them how their systems may be impacted, and what to do -- or not do -- to protect them. You'll have to tell them what they can and can't say to customers or others outside the company.
"When the breach comes from some hacker in Romania, this process is pretty simple," Contos observes. "But when you suspect it's your boss who's the leak, it's a lot more difficult. Who you tell and when you tell them can make a difference in whether you're able to quickly find and fix the problem."
Most states today have specific deadlines for informing customers and others who may be affected by the breach. In most cases, these laws allow up to 30 days for disclosure, so in most cases, you will have time to work on the problem before you make a public statement.
4. Begin remediating the problem.
Experts can never stress it enough: Never begin remediation until you fully understand the problem and its potential impact. Many experts say you shouldn't touch anything until a forensics team has been called in, lest you damage the evidence or make the problem worse.
But if the breach is actively hurting your business, this rule of thumb may not make sense. In some cases, you will want to unplug the servers or storage systems that are being infected or penetrated in order to limit the damage. In the case of an Internet-borne breach, turning off Port 80 might help.
"Disconnect your server(s) from the network," recommends BackGrounD Software. "If there is a potentially malicious code running, disconnect media devices as quickly as possible (i.e. disks, SAN, NAS). You never know how far the intruder has managed to get, so the faster you disconnect the equipment, the more of a chance you have to save your data."
After that, however, the steps you should take will depend on the skills you have in house. "For a small company, I would say hold on and wait for the experts," Contos says. "But a large enterprise could have people trained to handle this sort of incident. It's a skill set. You can learn it." Some companies, such as Target, maintain a fully-trained forensics staff that may even be offered to other companies, he observes.
Some problems don't immediately present themselves as security incidents, and IT staff may have already treated them with everyday troubleshooting measures. "It's not like there's a special beeper that goes off when it's security-related," Contos notes. "The key is that when you realize it's a security problem, you stop and consider what you're doing. Don't keep making configuration changes."
5. Document everything.
Lack of documentation can not only make it difficult to rebuild your systems after an incident -- it can also hurt your chances to make a case against an attacker in court, experts say. Throughout the assessment and remediation process, you should record everything, from how the incident was first detected to how the various members of the CSIRT team responded.
In some cases -- particularly in the case of attacks from outside the company -- the documentation will be done automatically, through log files from firewalls, IDS/IPS systems, and/or security information management tools. These tools should record the intrusion, the subsequent infections or downloads, and the configuration changes that were made to halt the attack.
Insider attacks are a different story. "In a lot of cases, an insider attack isn't detected initially through traditional security tools, but because someone noticed unusual or suspicious behavior," Contos says. In these cases, it's important to document the reports and log the behavior in addition to using monitoring tools to track computer activity, he advises.
Experts agree that documentation is one of the most frequently overlooked and difficult tasks to execute during a security incident. In many cases, the players don't have time to record what they're doing, or don't feel it's important. In the end, however, the documentation can be the key to reconstituting systems that have been rewired to stop an incident -- or to making a legal case against an intruder.
6. Develop a strategy for stopping the next attack.
Doing a post-mortem on a security incident -- or developing a plan for responding to the next one -- may seem like longer-term activities. But if one attacker finds a vulnerability, there's a good chance that he may have accomplices -- or that another attacker might find the same vulnerability.
It's not unusual for attacks to come in bunches, so it's important to permanently seal off your leaks and decide how you will alter your response process if an incident occurs again, experts say.
"Review what you've done and decide how you could have done it better," Contos says. "More importantly, consider all of the subsequent risks and, if you don't already have plans in place, get them in place. If you had trouble getting top management to listen before, you won't now."
— Tim Wilson, Site Editor, Dark Reading
Labels: What do to after breach
How TJX Became a Lesson In Proper Security
How TJX Became a Lesson In Proper Security
By Andy Patrizio
The TJX security breach is threatening to rank as one of the most expensive lessons in corporate data security policies.
With the retailer facing anywhere from $500 million to nearly $1 billion in expenses, not to mention a black eye with the public over how their credit card data is secured, this experience should serve as a lesson to other retail outlets on securing their networks. How well they are learning is the question.
The latest chapter in this still-unfinished book is a settlement between TJX Companies and Visa U.S.A. Under the agreement, TJX will pay a maximum of $40.9 million to fund an alternative recovery payments program for customers affected by the breach. TJX has already taken the charge for the settlement, and by settling with Visa holders, staves of potential lawsuits.
Additionally, Visa will suspend and rescind a portion of the data breach fines it levied on TJX's U.S. acquirer that remain eligible for appeal. Visa and TJX agreed to the suspended and rescinded fines in part because it would increase the funds available in the alternative recovery program.
Not that the company is in the clear. According to a report from Merchant Link, which provides secure systems for retail outlets, the breach has cost the company more than $130 million to secure its infrastructure, there have been 19 lawsuits filed and there are investigations underway by the Federal Trade Commission and 37 state Attorneys General.
All this seems to have driven the message home to retailers, including TJX itself. "TJX accelerated their security program and implemented the improvements needed to become PCI (Payment Card Industry)-compliant, including upgrading their wireless security and eliminating the storage of sensitive authentication data. In fact there is some discussion about TJX becoming a 'spokescompany' for PCI security," said Avivah Litan, senior security analyst for Gartner.
Perhaps, but TJX was not keen on discussing its new security plans in detail, as it did not respond to repeated requests for an interview. TJX is the parent company of T.J. Maxx, Marshalls, HomeGoods and A.J. Wright stores in the U.S., as well as Winners and HomeSense in Canada. Revenue for its most recent fiscal year ended January 2007 was $17.4 billion. For so large a company, though, the breach started small, with crackers hacking into wireless networks at two U.S. stores.
The stores were using the relatively weak Wired Equivalent Privacy (WEP) protocol instead of the stronger Wi-Fi Protected Access (WAP) protocol, but what really hurt is that the intruders were able to access the TJX internal systems and move around freely for almost two years. The breaches occurred from mid-2005 and ran through December 2006. It is estimated 47.5 million records were stolen.
That was TJX's bigger problem, letting the intruders roam freely for 18 months. Dr. Anton Chuvakin, a security expert with LogLogic, said TJX didn't have decent traffic logs. "What took TJX months was looking at all their systems and determining who took what data, from where, where it was sent, etc. The investigation took them months. They likely didn't have any logs, because they had to do system forensics rather than log analysis to arrive at their conclusions about who stole the data and how. If they had collected and analyzed log data centrally, the investigation would have been a piece of cake," he said in an e-mailed comment to InternetNews.com.
Brian Cleary, vice president of marketing for the enterprise access governance firm Aveksa, concurred. "They didn't have good access controls, they were not auditing access on a regular basis and not checking log files and access. It was really poor security governance," he said.
TJX's second mistake was storing vital credit card information, such as the data hidden in the card's magnetic strip, on local machines. This is particularly frustrating to banks, according to Litan, because it allows counterfeiters to make perfect duplicate cards.
Merchant Link's report specifically recommends to all clients that they eliminate the storage of sensitive personal data wherever possible by using secure third party services to keep the point of sale clean, and "certainly" do not store the data collected from a credit card's magnetic stripe.
Litan said TJX was certainly at fault for storing the magnetic stripe information but she also think banks have a bigger role to play in the design of the payment systems. "They rolled [payment systems] out before there were cybertheives and no one thought about security," she said. "The payment system architecture is legacy, outdated. They could update the arch and make them more secure or just require a PIN on every transaction. Instead, they'd rather keep it as business as usual and keep collecting revenue streams."
She explained that banks make more money on standard credit card transactions instead of PIN-based transactions, such as with a debit card. PINs are always encrypted and never stored when used, and would eliminate a majority of the potential problems because without a PIN, a card is useless.
John Livingston, chairman and CEO of asset management firm Absolute, concurred that companies need to smarten up about business in the Internet era. "As we adopt new technologies, there's a whole set of new procedures, policies and practices that need to take place," he told InternetNews.com. "The companies that are doing these transactions need to be educated. But there are solutions to all these things. It's not impossible to transmit secure data, it just takes dollars and a commitment from the company to make it happen."
Absolute recommends a layered approach of technologies and policies. "You want to identify and control all the sensitive data. You need to make sure it's stored in a secure facility, you need to put the policy and procedure in place to make sure it's safe," said Livingstone.
Litan said some companies have not learned the lesson of TJX's experience and have been reluctant to make significant investments in such security measures because they see no return on investment. "It's a calculated risk, I guess. They just don't want to spend time on boring security projects. There's no ROI in security, it's basically cost avoidance," she said.
But Cleary said some firms got the message. "The ones that value their brand and are a bit more forward thinking are willing to do what it takes," he said. "When you look at cost containment, you wouldn't make decisions on your home insurance that way. Why you would risk the business to that degree makes no sense and is not in the shareholder's best interests."
He added "I think there were a lot of pages of publications [covering the story] that were ripped out and handed to CIOs and Chief Security Officers and asked 'This won't happen to us, right?' This has elevated the concerns about having good security governance in place all the way to the board level."
By Andy Patrizio
The TJX security breach is threatening to rank as one of the most expensive lessons in corporate data security policies.
With the retailer facing anywhere from $500 million to nearly $1 billion in expenses, not to mention a black eye with the public over how their credit card data is secured, this experience should serve as a lesson to other retail outlets on securing their networks. How well they are learning is the question.
The latest chapter in this still-unfinished book is a settlement between TJX Companies and Visa U.S.A. Under the agreement, TJX will pay a maximum of $40.9 million to fund an alternative recovery payments program for customers affected by the breach. TJX has already taken the charge for the settlement, and by settling with Visa holders, staves of potential lawsuits.
Additionally, Visa will suspend and rescind a portion of the data breach fines it levied on TJX's U.S. acquirer that remain eligible for appeal. Visa and TJX agreed to the suspended and rescinded fines in part because it would increase the funds available in the alternative recovery program.
Not that the company is in the clear. According to a report from Merchant Link, which provides secure systems for retail outlets, the breach has cost the company more than $130 million to secure its infrastructure, there have been 19 lawsuits filed and there are investigations underway by the Federal Trade Commission and 37 state Attorneys General.
All this seems to have driven the message home to retailers, including TJX itself. "TJX accelerated their security program and implemented the improvements needed to become PCI (Payment Card Industry)-compliant, including upgrading their wireless security and eliminating the storage of sensitive authentication data. In fact there is some discussion about TJX becoming a 'spokescompany' for PCI security," said Avivah Litan, senior security analyst for Gartner.
Perhaps, but TJX was not keen on discussing its new security plans in detail, as it did not respond to repeated requests for an interview. TJX is the parent company of T.J. Maxx, Marshalls, HomeGoods and A.J. Wright stores in the U.S., as well as Winners and HomeSense in Canada. Revenue for its most recent fiscal year ended January 2007 was $17.4 billion. For so large a company, though, the breach started small, with crackers hacking into wireless networks at two U.S. stores.
The stores were using the relatively weak Wired Equivalent Privacy (WEP) protocol instead of the stronger Wi-Fi Protected Access (WAP) protocol, but what really hurt is that the intruders were able to access the TJX internal systems and move around freely for almost two years. The breaches occurred from mid-2005 and ran through December 2006. It is estimated 47.5 million records were stolen.
That was TJX's bigger problem, letting the intruders roam freely for 18 months. Dr. Anton Chuvakin, a security expert with LogLogic, said TJX didn't have decent traffic logs. "What took TJX months was looking at all their systems and determining who took what data, from where, where it was sent, etc. The investigation took them months. They likely didn't have any logs, because they had to do system forensics rather than log analysis to arrive at their conclusions about who stole the data and how. If they had collected and analyzed log data centrally, the investigation would have been a piece of cake," he said in an e-mailed comment to InternetNews.com.
Brian Cleary, vice president of marketing for the enterprise access governance firm Aveksa, concurred. "They didn't have good access controls, they were not auditing access on a regular basis and not checking log files and access. It was really poor security governance," he said.
TJX's second mistake was storing vital credit card information, such as the data hidden in the card's magnetic strip, on local machines. This is particularly frustrating to banks, according to Litan, because it allows counterfeiters to make perfect duplicate cards.
Merchant Link's report specifically recommends to all clients that they eliminate the storage of sensitive personal data wherever possible by using secure third party services to keep the point of sale clean, and "certainly" do not store the data collected from a credit card's magnetic stripe.
Litan said TJX was certainly at fault for storing the magnetic stripe information but she also think banks have a bigger role to play in the design of the payment systems. "They rolled [payment systems] out before there were cybertheives and no one thought about security," she said. "The payment system architecture is legacy, outdated. They could update the arch and make them more secure or just require a PIN on every transaction. Instead, they'd rather keep it as business as usual and keep collecting revenue streams."
She explained that banks make more money on standard credit card transactions instead of PIN-based transactions, such as with a debit card. PINs are always encrypted and never stored when used, and would eliminate a majority of the potential problems because without a PIN, a card is useless.
John Livingston, chairman and CEO of asset management firm Absolute, concurred that companies need to smarten up about business in the Internet era. "As we adopt new technologies, there's a whole set of new procedures, policies and practices that need to take place," he told InternetNews.com. "The companies that are doing these transactions need to be educated. But there are solutions to all these things. It's not impossible to transmit secure data, it just takes dollars and a commitment from the company to make it happen."
Absolute recommends a layered approach of technologies and policies. "You want to identify and control all the sensitive data. You need to make sure it's stored in a secure facility, you need to put the policy and procedure in place to make sure it's safe," said Livingstone.
Litan said some companies have not learned the lesson of TJX's experience and have been reluctant to make significant investments in such security measures because they see no return on investment. "It's a calculated risk, I guess. They just don't want to spend time on boring security projects. There's no ROI in security, it's basically cost avoidance," she said.
But Cleary said some firms got the message. "The ones that value their brand and are a bit more forward thinking are willing to do what it takes," he said. "When you look at cost containment, you wouldn't make decisions on your home insurance that way. Why you would risk the business to that degree makes no sense and is not in the shareholder's best interests."
He added "I think there were a lot of pages of publications [covering the story] that were ripped out and handed to CIOs and Chief Security Officers and asked 'This won't happen to us, right?' This has elevated the concerns about having good security governance in place all the way to the board level."
Labels: TJX Companies Inc.
Internet outages overseas prompt business continuity awareness
Internet outages overseas prompt business continuity awareness
Dan KaplanJanuary 31 2008
Major internet disruptions occurring today across the Middle East and parts of Asia and Africa after two undersea cables were sliced should prompt global businesses of all sizes to review their business continuity and disaster recovery strategies, experts said today.
The slowdowns and outages continue to affect a number of countries including Egypt and the United Arab Emirates. But it is the disruption being felt in India that may have the most impact on U.S.-based firms, which heavily rely on the Asian nation for outsourcing services, experts said.
Indian businesses who contract with upstream providers that provide connectivity in both directions to the United States, not just the direction that was impacted by the severed cables, may be able to stave off a complete disruption – although bandwidth on those channels should also suffer, said Earl Zmijewski, general manager of the Internet Data Division at Renesys, an global internet monitoring firm.
Bu he said businesses should be prepared for these types of incidents. A similar event occurred in December 2006 after an earthquake damaged cables near Taiwan.
“They are going to happen,” Zmijewski told SCMagazineUS.com on Thursday. “They are going to happen. Sometimes they're just quicker to recover. Sometimes they're very long. I think people just have to think in terms of what happens if, or not even if, when, I lose critical connectivity.”
Joe Hicks, product manager at F5 Networks, a network appliance provider, told SCMagazineUS.com on Thursday that many entities affected, such as Dubai's stock exchange, face challenges because they depend on a limited set of cables.
“They didn't have infrastructure or a piece of equipment that allowed them to detect failures that were not right there in their own facilities,” he said.
Satellites are an alternative to fiber-optic cables, but they often are riddled with latency and cost concerns and are therefore not suitable for organizations conducting real-time financial transactions, Zmijewski said.
Business continuity and disaster recovery comes down to conducting a cost-benefit analysis and determining risk, Hicks said.
Companies intent on spending the money should consider buying multiple egress lines from upstream providers and deploying redundant servers and “fail-over” equipment to protect fiber-optic lines.
Depending on how quickly crews can repair the severed cables, sluggish internet may persist for a few weeks, Zmijewski said.
Rough weather and seas had prevented crews from getting to the scene of the accident on Thursday, according to published reports.
Dan KaplanJanuary 31 2008
Major internet disruptions occurring today across the Middle East and parts of Asia and Africa after two undersea cables were sliced should prompt global businesses of all sizes to review their business continuity and disaster recovery strategies, experts said today.
The slowdowns and outages continue to affect a number of countries including Egypt and the United Arab Emirates. But it is the disruption being felt in India that may have the most impact on U.S.-based firms, which heavily rely on the Asian nation for outsourcing services, experts said.
Indian businesses who contract with upstream providers that provide connectivity in both directions to the United States, not just the direction that was impacted by the severed cables, may be able to stave off a complete disruption – although bandwidth on those channels should also suffer, said Earl Zmijewski, general manager of the Internet Data Division at Renesys, an global internet monitoring firm.
Bu he said businesses should be prepared for these types of incidents. A similar event occurred in December 2006 after an earthquake damaged cables near Taiwan.
“They are going to happen,” Zmijewski told SCMagazineUS.com on Thursday. “They are going to happen. Sometimes they're just quicker to recover. Sometimes they're very long. I think people just have to think in terms of what happens if, or not even if, when, I lose critical connectivity.”
Joe Hicks, product manager at F5 Networks, a network appliance provider, told SCMagazineUS.com on Thursday that many entities affected, such as Dubai's stock exchange, face challenges because they depend on a limited set of cables.
“They didn't have infrastructure or a piece of equipment that allowed them to detect failures that were not right there in their own facilities,” he said.
Satellites are an alternative to fiber-optic cables, but they often are riddled with latency and cost concerns and are therefore not suitable for organizations conducting real-time financial transactions, Zmijewski said.
Business continuity and disaster recovery comes down to conducting a cost-benefit analysis and determining risk, Hicks said.
Companies intent on spending the money should consider buying multiple egress lines from upstream providers and deploying redundant servers and “fail-over” equipment to protect fiber-optic lines.
Depending on how quickly crews can repair the severed cables, sluggish internet may persist for a few weeks, Zmijewski said.
Rough weather and seas had prevented crews from getting to the scene of the accident on Thursday, according to published reports.
Swedish Bank Stops Attempt to Take Control of Computer and Transfer Millions
Swedish Bank Stops Attempt to Take Control of Computer and Transfer Millions
STOCKHOLM, Sweden (AP) -- A gang of Swedish criminals was seconds away from completing a digital bank heist when an alert employee literally pulled the plug on their brazen scam, investigators said Wednesday.
The would be bank robbers had placed "advanced technical equipment" under the employee's desk that allowed them to take control of his computer remotely, prosecutor Thomas Balter Nordenman said in a statement.
The employee discovered the device shortly after he realized his computer had started an operation to transfer "millions" from the bank into another account, Nordenman said.
"By pulling out the cable to the device, the employee managed to stop the intended transfer at the last second," he said.
The foiled heist happened in August at a bank in Uppland county, north of Stockholm, police said. They announced it only Wednesday after seven suspects, all from the Stockholm region, were arrested this week while allegedly preparing another heist.
Police did not name the suspects, but said many of them have prior fraud and theft convictions. Investigators did not give other details on the device, or how it was placed under the desk.
STOCKHOLM, Sweden (AP) -- A gang of Swedish criminals was seconds away from completing a digital bank heist when an alert employee literally pulled the plug on their brazen scam, investigators said Wednesday.
The would be bank robbers had placed "advanced technical equipment" under the employee's desk that allowed them to take control of his computer remotely, prosecutor Thomas Balter Nordenman said in a statement.
The employee discovered the device shortly after he realized his computer had started an operation to transfer "millions" from the bank into another account, Nordenman said.
"By pulling out the cable to the device, the employee managed to stop the intended transfer at the last second," he said.
The foiled heist happened in August at a bank in Uppland county, north of Stockholm, police said. They announced it only Wednesday after seven suspects, all from the Stockholm region, were arrested this week while allegedly preparing another heist.
Police did not name the suspects, but said many of them have prior fraud and theft convictions. Investigators did not give other details on the device, or how it was placed under the desk.
Florida woman accused of deleting $2.5 million in data
Florida woman accused of deleting $2.5 million in data
Frank Washkuch Jr.January 25 2008
Updated Friday, Jan. 25, 2008, at 4:54 p.m. EST
A Florida woman, fearing she was about to be fired from her job, was arrested this week for allegedly deleting seven year's worth of her employer's architectural data.
Marie Cooley, 41, was arrested after entering the offices of Steven E. Hutchins Associates in Jacksonville, Fla., and deleting $2.5 million in files after seeing an advertisement for a job similar to hers in classified advertisements.
Cooley has been charged with damaging computers in excess of $1,000, a second-degree felony. If convicted, she faces up to five years in prison, according to Ken Jefferson, Jacksonville Sherriff's Office public information officer.
Cooley entered the office to pick up her W-2 file Sunday night when she deleted the data and pulled network cables out of place, Jefferson said.
“The lesson to be learned is not to trust your employees with all of you life's work,” he said. “You have to have a backup.”
Steven Hutchins, the firm's owner, could not be immediately reached for comment today, but he told numerous media that his organization was able to recover the lost data.
Hutchins' firm was not about to fire Cooley at the time of the incident. The job ad was for his wife's business, according to press reports.
Insider threats are a growing concern of executives and IT professionals, according to experts. Earlier this month, Yung-Hsun Lin, 51 of Montville, N.J., was sentenced to 30 months in prison and ordered to pay more than $81,000 in restitution after he planted a “logic bomb” on the network of his former employer, Medco Health Systems.
Ben Rubin, senior consultant at Mandiant, an incident-response and education organization, told SCMagazineUS.com today that companies should limit the access that employees have to important data.
“The best thing to do is to have more control of the domain, where you have certain individuals with more privilege than others and where any one employee can't just log in and do that to such a central part of the business,” he said.
Ted Julian, vice president of marketing at Application Security Inc., told SCMagazineUS.com today employee monitoring can help alleviate the threat from insiders.
“Any organization with sensitive data and intellectual property needs to be monitoring the access to and the use of that data on an ongoing basis,” he said. “Terminations are just a part of it. What about ID theft and insiders getting pulled into those schemes, whether they're getting paid off or bribed or duped by social engineering?”
Frank Washkuch Jr.January 25 2008
Updated Friday, Jan. 25, 2008, at 4:54 p.m. EST
A Florida woman, fearing she was about to be fired from her job, was arrested this week for allegedly deleting seven year's worth of her employer's architectural data.
Marie Cooley, 41, was arrested after entering the offices of Steven E. Hutchins Associates in Jacksonville, Fla., and deleting $2.5 million in files after seeing an advertisement for a job similar to hers in classified advertisements.
Cooley has been charged with damaging computers in excess of $1,000, a second-degree felony. If convicted, she faces up to five years in prison, according to Ken Jefferson, Jacksonville Sherriff's Office public information officer.
Cooley entered the office to pick up her W-2 file Sunday night when she deleted the data and pulled network cables out of place, Jefferson said.
“The lesson to be learned is not to trust your employees with all of you life's work,” he said. “You have to have a backup.”
Steven Hutchins, the firm's owner, could not be immediately reached for comment today, but he told numerous media that his organization was able to recover the lost data.
Hutchins' firm was not about to fire Cooley at the time of the incident. The job ad was for his wife's business, according to press reports.
Insider threats are a growing concern of executives and IT professionals, according to experts. Earlier this month, Yung-Hsun Lin, 51 of Montville, N.J., was sentenced to 30 months in prison and ordered to pay more than $81,000 in restitution after he planted a “logic bomb” on the network of his former employer, Medco Health Systems.
Ben Rubin, senior consultant at Mandiant, an incident-response and education organization, told SCMagazineUS.com today that companies should limit the access that employees have to important data.
“The best thing to do is to have more control of the domain, where you have certain individuals with more privilege than others and where any one employee can't just log in and do that to such a central part of the business,” he said.
Ted Julian, vice president of marketing at Application Security Inc., told SCMagazineUS.com today employee monitoring can help alleviate the threat from insiders.
“Any organization with sensitive data and intellectual property needs to be monitoring the access to and the use of that data on an ongoing basis,” he said. “Terminations are just a part of it. What about ID theft and insiders getting pulled into those schemes, whether they're getting paid off or bribed or duped by social engineering?”
Data of 650,000 customers of JCPenney, retailers at risk
Data of 650,000 customers of JCPenney, retailers at risk
Frank Washkuch Jr.January 18 2008
The personally identifiable information of about 650,000 customers of JCPenney and other retailers is at risk after a data tape went missing from storage vendor Iron Mountain.
The Social Security numbers of 150,000 people were on the backup tape, which vanished last October, according to representatives from GE Money, which handles retail credit card operations.
The backup tape was being stored at an Iron Mountain warehouse when it went missing. The tape was not checked out of the facility, a GE Money spokesman said.
A statement released today by JCPenney said only that GE Money had made the retailer aware of the breach and is notifying customers. The statement referred inquiries to GE Money's public relations department.
GE Money spent two months reconstructing the tape and is paying for one year of credit-monitoring service for affected customers. JCPenney expects to complete the notification process next week, according to published reports.
A representative from GE Money could not be immediately reached for comment.
Iron Mountain spokesman Dan O'Neill said today that there is no evidence that the tape was obtained by an unauthorized person or has been misused. To access the sensitive information on the media, an individual would have to have specialized knowledge, he said.
“An accidental loss of a backup tape is not an identity theft issue or a crime. It is distinctly different from previous cases of malicious hacking or PC theft. Since we notified GE Money of the missing backup tape in October, there has been no evidence to suggest that any person's identity has been compromised as a result,” O'Neill said. “And we don't know of any incident, ever, when a backup tape has resulted in identity theft.”
The most prominent retail breach to date was the 2005 infiltration of the databases of TJX Companies, the parent company of T.J. Maxx and other chains. The hacking is believed to have begun at a Marshalls store in Minnesota, although others have suggested the suspects gained initial access at two Marshalls locations in Florida.
A group of New England banking associations claimed that hackers stole 94 million account numbers in the incident, but TJX maintains that 45.7 million accounts were accessed.
Avivah Litan, Gartner vice president and research director, told SCMagazineUS.com today that JCPenney had likely outsourced its data storage to Iron Mountain believing that the vendor could do a better job with security than the retailer could.
“This is the first documented case where a trusted service provider, like Iron Mountain, has lost a tape, so it's kind of damned if you do and damned if you don't,” she said. “The whole chain of trust is broken now. In the case of TJX, they were doing everything themselves, and up until now, there hadn't been a case like this. So this deflates the hope of finding trusted third parties.”
Gordon Rapkin, president and chief executive of data security vendor Protegrity, told SCMagazineUS.com today that JCPenney is ultimately responsible for making sure their customers' information is secured.
“I always follow the chain of responsibility, and it starts with someone charging his or her credit card data to JCPenney and transacting his or her business with JCPenney,” he said. “For all they know, [consumers] were doing business with JCPenney and not Iron Mountain.”
Popular blog consumerist.com claimed Tuesday that a “major retailer” had suffered a large credit card data breach, resulting in a surge of fraud reports from its readers, although it is unclear whether that has anything to do with the JCPenney incident.
The personal or financial data of more than 217 million Americans has been compromised since the beginning of 2005, according to the nonprofit Privacy Rights Clearinghouse.
Steven Sprague, CEO of Wave Systems, a data-security vendor, told SCMagazineUS.com today that encryption is an easy solution to ensure that personal information is not accessed improperly.
“The need to encrypt all data is reaching the point where it's for everyone,” he said. “Whether [dealing with] Iron Mountain or others, stuff happens, and when you encrypt the data, you don't have to rely on other people as much.”
Frank Washkuch Jr.January 18 2008
The personally identifiable information of about 650,000 customers of JCPenney and other retailers is at risk after a data tape went missing from storage vendor Iron Mountain.
The Social Security numbers of 150,000 people were on the backup tape, which vanished last October, according to representatives from GE Money, which handles retail credit card operations.
The backup tape was being stored at an Iron Mountain warehouse when it went missing. The tape was not checked out of the facility, a GE Money spokesman said.
A statement released today by JCPenney said only that GE Money had made the retailer aware of the breach and is notifying customers. The statement referred inquiries to GE Money's public relations department.
GE Money spent two months reconstructing the tape and is paying for one year of credit-monitoring service for affected customers. JCPenney expects to complete the notification process next week, according to published reports.
A representative from GE Money could not be immediately reached for comment.
Iron Mountain spokesman Dan O'Neill said today that there is no evidence that the tape was obtained by an unauthorized person or has been misused. To access the sensitive information on the media, an individual would have to have specialized knowledge, he said.
“An accidental loss of a backup tape is not an identity theft issue or a crime. It is distinctly different from previous cases of malicious hacking or PC theft. Since we notified GE Money of the missing backup tape in October, there has been no evidence to suggest that any person's identity has been compromised as a result,” O'Neill said. “And we don't know of any incident, ever, when a backup tape has resulted in identity theft.”
The most prominent retail breach to date was the 2005 infiltration of the databases of TJX Companies, the parent company of T.J. Maxx and other chains. The hacking is believed to have begun at a Marshalls store in Minnesota, although others have suggested the suspects gained initial access at two Marshalls locations in Florida.
A group of New England banking associations claimed that hackers stole 94 million account numbers in the incident, but TJX maintains that 45.7 million accounts were accessed.
Avivah Litan, Gartner vice president and research director, told SCMagazineUS.com today that JCPenney had likely outsourced its data storage to Iron Mountain believing that the vendor could do a better job with security than the retailer could.
“This is the first documented case where a trusted service provider, like Iron Mountain, has lost a tape, so it's kind of damned if you do and damned if you don't,” she said. “The whole chain of trust is broken now. In the case of TJX, they were doing everything themselves, and up until now, there hadn't been a case like this. So this deflates the hope of finding trusted third parties.”
Gordon Rapkin, president and chief executive of data security vendor Protegrity, told SCMagazineUS.com today that JCPenney is ultimately responsible for making sure their customers' information is secured.
“I always follow the chain of responsibility, and it starts with someone charging his or her credit card data to JCPenney and transacting his or her business with JCPenney,” he said. “For all they know, [consumers] were doing business with JCPenney and not Iron Mountain.”
Popular blog consumerist.com claimed Tuesday that a “major retailer” had suffered a large credit card data breach, resulting in a surge of fraud reports from its readers, although it is unclear whether that has anything to do with the JCPenney incident.
The personal or financial data of more than 217 million Americans has been compromised since the beginning of 2005, according to the nonprofit Privacy Rights Clearinghouse.
Steven Sprague, CEO of Wave Systems, a data-security vendor, told SCMagazineUS.com today that encryption is an easy solution to ensure that personal information is not accessed improperly.
“The need to encrypt all data is reaching the point where it's for everyone,” he said. “Whether [dealing with] Iron Mountain or others, stuff happens, and when you encrypt the data, you don't have to rely on other people as much.”
Bank robbery con jobs treat incident response as a joke
Bank robbery con jobs treat incident response as a joke
16 Jan 08 -- We all know a few "guy walks into a bar..." jokes. But in this story, it's "guy walks into a bank," and the joke may be on you -- or on an Incident Response Policy that is, well, laughable.
Open on: A branch of BB&T Bank in Maryland, on an average Wednesday morning. A man wearing what resembles the proper uniform tells the bank he is the substitute courier from their armored car vendor, and walks out with a half million dollars in cash. The simple ruse works so well that we... Cut to: A Wachovia bank branch in Washington, D.C., where the social-engineering bank robbers do it again the next day. In fact, the ruse holds up in each case until the real armored car personnel show up for the daily cash deposit -- which the tellers have already given away.
A Brinks guard discovered the second theft an hour after it happened. He waited until he returned to his office to inform his supervisors. Brinks officials contacted the bank branch, where eventually the branch manager contacted the police -- almost 11 hours after the robbery took place. (Somehow I doubt that "giving criminals generous head starts" is what those Wachovia ads mean when they say, "We're here to help.")
These banks must have an Incident Response Policy (IRP) somewhere. They are required to do so, in order to pass audits and federal regulations. Brinks probably has one, too. For that matter, you and I probably have one at our respective workplaces. But clearly the policy failed when the employees who were first-responders had to implement it. What went wrong? We can only speculate, but the likely problems are familiar: The employees were not aware of the policy. Or no one had ever rehearsed implementing the policy. A typical IRP lists who should be notified in an emergency, in the order they should be contacted. Maybe the policies were so out-of-date that the people listed in them no longer worked for the bank, or had changed their phone numbers, or....
Bottom line: If you want your IRP to be taken more seriously than a "guy walks into a bar" joke, you should review it periodically. Verify that it's still realistic, up to date, and familiar to your employees. "Guy walks into a bar" is funny. But what the guy walks out with might be no laughing matter. -- D. Scott Pinzon, CISSP
Copyright© 2008 WatchGuard® Technologies, Inc. You may copy and distribute this article freely in any medium as long as you copy and distribute the entire article without change and preserve this copyright statement and notice.
16 Jan 08 -- We all know a few "guy walks into a bar..." jokes. But in this story, it's "guy walks into a bank," and the joke may be on you -- or on an Incident Response Policy that is, well, laughable.
Open on: A branch of BB&T Bank in Maryland, on an average Wednesday morning. A man wearing what resembles the proper uniform tells the bank he is the substitute courier from their armored car vendor, and walks out with a half million dollars in cash. The simple ruse works so well that we... Cut to: A Wachovia bank branch in Washington, D.C., where the social-engineering bank robbers do it again the next day. In fact, the ruse holds up in each case until the real armored car personnel show up for the daily cash deposit -- which the tellers have already given away.
A Brinks guard discovered the second theft an hour after it happened. He waited until he returned to his office to inform his supervisors. Brinks officials contacted the bank branch, where eventually the branch manager contacted the police -- almost 11 hours after the robbery took place. (Somehow I doubt that "giving criminals generous head starts" is what those Wachovia ads mean when they say, "We're here to help.")
These banks must have an Incident Response Policy (IRP) somewhere. They are required to do so, in order to pass audits and federal regulations. Brinks probably has one, too. For that matter, you and I probably have one at our respective workplaces. But clearly the policy failed when the employees who were first-responders had to implement it. What went wrong? We can only speculate, but the likely problems are familiar: The employees were not aware of the policy. Or no one had ever rehearsed implementing the policy. A typical IRP lists who should be notified in an emergency, in the order they should be contacted. Maybe the policies were so out-of-date that the people listed in them no longer worked for the bank, or had changed their phone numbers, or....
Bottom line: If you want your IRP to be taken more seriously than a "guy walks into a bar" joke, you should review it periodically. Verify that it's still realistic, up to date, and familiar to your employees. "Guy walks into a bar" is funny. But what the guy walks out with might be no laughing matter. -- D. Scott Pinzon, CISSP
Copyright© 2008 WatchGuard® Technologies, Inc. You may copy and distribute this article freely in any medium as long as you copy and distribute the entire article without change and preserve this copyright statement and notice.
Armored Car Guard Impostor Robs Bank
Armored Car Guard Impostor Robs Bank
WASHINGTON -- It took hours for officials at a downtown Washington bank to realize they'd been robbed.
Police said a man impersonating an armored car guard walked out of a Wachovia bank branch on Pennsylvania Avenue Thursday after officials let him sign for a locked bag of cash. About $350,000 was taken, law enforcement sources told News4.
About an hour after the robbery, a real Brinks guard arrived at the bank and was told that another guard had completed the day's cash pickup.
Police said the Brinks driver waited until he returned to his office to tell his supervisors about the failed pickup. Brinks officials contacted the bank, and a branch manager called D.C. police about 8 p.m. -- almost 11 hours after the theft.
"Around 9:30 in the morning, we had a gentleman entered the bank who was dressed in ... maybe a Brinks-type uniform walked in and signed for the money and walked out," said D.C. police Lt. William Farr.
The bank is across the street from the J. Edgar Hoover FBI building. The FBI is investigating.
Authorities don't have a detailed description of the robber and don't know whether he left the bank in a vehicle or on foot.
A similar robbery took place at a BB&T bank in Wheaton, Md., on Wednesday. A man in a uniform resembling an armored guard service uniform went into the bank and presented himself as a substitute courier, saying the regular courier was on leave, according to Montgomery County police. The man picked up an undisclosed amount of deposits and left.
On Thursday, according to police, the regular courier went to the bank. It was then determined that the man who picked up deposits on Wednesday was not authorized to do so.
Authorities are trying to determine if the incidents are related.
WASHINGTON -- It took hours for officials at a downtown Washington bank to realize they'd been robbed.
Police said a man impersonating an armored car guard walked out of a Wachovia bank branch on Pennsylvania Avenue Thursday after officials let him sign for a locked bag of cash. About $350,000 was taken, law enforcement sources told News4.
About an hour after the robbery, a real Brinks guard arrived at the bank and was told that another guard had completed the day's cash pickup.
Police said the Brinks driver waited until he returned to his office to tell his supervisors about the failed pickup. Brinks officials contacted the bank, and a branch manager called D.C. police about 8 p.m. -- almost 11 hours after the theft.
"Around 9:30 in the morning, we had a gentleman entered the bank who was dressed in ... maybe a Brinks-type uniform walked in and signed for the money and walked out," said D.C. police Lt. William Farr.
The bank is across the street from the J. Edgar Hoover FBI building. The FBI is investigating.
Authorities don't have a detailed description of the robber and don't know whether he left the bank in a vehicle or on foot.
A similar robbery took place at a BB&T bank in Wheaton, Md., on Wednesday. A man in a uniform resembling an armored guard service uniform went into the bank and presented himself as a substitute courier, saying the regular courier was on leave, according to Montgomery County police. The man picked up an undisclosed amount of deposits and left.
On Thursday, according to police, the regular courier went to the bank. It was then determined that the man who picked up deposits on Wednesday was not authorized to do so.
Authorities are trying to determine if the incidents are related.
Zero-Day Exploit For Apple's QuickTime Posted
Zero-Day Exploit For Apple's QuickTime Posted
The vulnerability affects both Windows and Mac OS X versions of Apple's QuickTime software.
By Thomas Claburn, InformationWeek
Jan. 10, 2008
URL: http://www.informationweek.com/story/showArticle.jhtml?articleID=205602310
An Italian security researcher has posted a proof-of-concept exploit for a zero-day vulnerability in the most current version of Apple's QuickTime media software (7.3.1).
Luigi Auriemma, noted among other things for discovering a vulnerability in the Unreal Engine in 2004, on Thursday posted details about producing a buffer overflow error in QuickTime. Buffer overflows can often be exploited by attackers to compromise the affected system.
"The bug is a buffer-overflow and the return address can be fully overwritten so a malicious attacker could use it for executing malicious code on the victim," Auriemma said in an e-mail.
According to Auriemma, the vulnerability affects both Windows and Mac OS X versions of Apple's QuickTime software. But other researchers have been unable to successfully use the exploit on Mac OS X and have suggested that the flaw may lie in code specific to Windows.
In his description of the exploit, Auriemma explains that when QuickTime encounters a Real-Time Streaming Protocol (rtsp://) link and port 554 of the server is closed, the application will switch to the HTTP protocol on port 80. The server then sends a long HTTP error message, so long that it causes the buffer to overflow. This allows the attacker to take control the affected system.
Auriemma said that Apple has not been notified of the flaw in advance of its publication.
When Apple updated QuickTime to version 7.3.1 on Dec. 13, it fixed an RTSP buffer overflow bug (CVE-ID: CVE-2007-6166) related to the content-type/content-base header. The vulnerability Auriemma has identified relates to error message handling and remains unpatched.
Alfred Huger, VP of development at Symantec Security Response, said that the exploit appears to be valid. "The proof-of-concept code only managed to crash the product," he said. "But it's a safe assumption that if you can do that you may be able to execute remote code.
"It's very serious," Huger added, noting that it's one of a number of QuickTime vulnerabilities discovered in the past few months.
With the increasing popularity of Mac OS X on both computers and phones, several security researchers have observed that hackers are exploring vulnerabilities in Apple's products with more interest.
On Wednesday, US-CERT warned about a phony iPhone upgrade. And at least one recent malware program, Trojan.DNSChanger, has the potential to affect both Windows and Mac users.
On the Sunbelt Software blog on Monday, security researchers Patrick Jordan and Adam Thomas identified the latest in a series of sites trying to infect visitors with Trojan.DNSChanger by tricking them into installing a purported media codec to enable video viewing.
Huger said that hackers aren't specifically interested in Apple products. Rather, they look for holes in any widely distributed application, like QuickTime, or device to maximize malware distribution.
The vulnerability affects both Windows and Mac OS X versions of Apple's QuickTime software.
By Thomas Claburn, InformationWeek
Jan. 10, 2008
URL: http://www.informationweek.com/story/showArticle.jhtml?articleID=205602310
An Italian security researcher has posted a proof-of-concept exploit for a zero-day vulnerability in the most current version of Apple's QuickTime media software (7.3.1).
Luigi Auriemma, noted among other things for discovering a vulnerability in the Unreal Engine in 2004, on Thursday posted details about producing a buffer overflow error in QuickTime. Buffer overflows can often be exploited by attackers to compromise the affected system.
"The bug is a buffer-overflow and the return address can be fully overwritten so a malicious attacker could use it for executing malicious code on the victim," Auriemma said in an e-mail.
According to Auriemma, the vulnerability affects both Windows and Mac OS X versions of Apple's QuickTime software. But other researchers have been unable to successfully use the exploit on Mac OS X and have suggested that the flaw may lie in code specific to Windows.
In his description of the exploit, Auriemma explains that when QuickTime encounters a Real-Time Streaming Protocol (rtsp://) link and port 554 of the server is closed, the application will switch to the HTTP protocol on port 80. The server then sends a long HTTP error message, so long that it causes the buffer to overflow. This allows the attacker to take control the affected system.
Auriemma said that Apple has not been notified of the flaw in advance of its publication.
When Apple updated QuickTime to version 7.3.1 on Dec. 13, it fixed an RTSP buffer overflow bug (CVE-ID: CVE-2007-6166) related to the content-type/content-base header. The vulnerability Auriemma has identified relates to error message handling and remains unpatched.
Alfred Huger, VP of development at Symantec Security Response, said that the exploit appears to be valid. "The proof-of-concept code only managed to crash the product," he said. "But it's a safe assumption that if you can do that you may be able to execute remote code.
"It's very serious," Huger added, noting that it's one of a number of QuickTime vulnerabilities discovered in the past few months.
With the increasing popularity of Mac OS X on both computers and phones, several security researchers have observed that hackers are exploring vulnerabilities in Apple's products with more interest.
On Wednesday, US-CERT warned about a phony iPhone upgrade. And at least one recent malware program, Trojan.DNSChanger, has the potential to affect both Windows and Mac users.
On the Sunbelt Software blog on Monday, security researchers Patrick Jordan and Adam Thomas identified the latest in a series of sites trying to infect visitors with Trojan.DNSChanger by tricking them into installing a purported media codec to enable video viewing.
Huger said that hackers aren't specifically interested in Apple products. Rather, they look for holes in any widely distributed application, like QuickTime, or device to maximize malware distribution.
Deloitte partner, principal confidential information on stolen laptop
Deloitte partner, principal confidential information on stolen laptop
Dan KaplanDecember 14 2007
A laptop containing the personal information of an undisclosed number of Deloitte & Touche partners, principals and other employees was stolen while in possession of a contractor responsible for scanning the accounting firm's pension fund documents, SCMagazineUS.com learned today.
The computer contained confidential data, including names, Social Security numbers, birth dates, and other personnel information, such as hire and termination dates, according to a Dec. 6 letter Deloitte sent to victims. Some of the information belonged to people working at Deloitte subsidiaries.
The laptop, stolen during Thanksgiving week, was protected by a password but was not encrypted, according to the letter. Deloitte has no evidence any of the data has been used for fraudulent purposes, and police are investigating.
A company spokeswoman, in an email to SCMagazineUS.com, declined to reveal specifics about the incident.
“Yes, a laptop was stolen and Deloitte is working with the company involved and has communicated with its own people to help them limit any potential misuse of their data,” spokeswoman Deborah Harrington said. “That's the extent of our comment.”
Richard Baker, who worked as a manager in management consulting at Deloitte from 1990 to 1995, said he received a notification letter.
“What is particularly egregious about this situation is that Deloitte is a ‘noted' security expert with seminars, whitepapers, service lines, etc.,” he told SCMagazineUS.com in an email today. “One would think there would be security and encryption standards for all sensitive personal data, whether managed internally or by outside vendors.”
Baker said he now oversees the consulting division of a channel partner of Symantec, a major security firm.
Deloitte said in the letter that it has stopped working with the responsible vendor, who was not named, until it “can demonstrate that is has implemented appropriate data security protections. In addition we have an ongoing program to identify vendors who access confidential information regarding our personnel and to confirm that they have implemented appropriate protections.”
Deloitte, based in New York, plans to provide victims with one year of free credit-monitoring services, according to the letter. It also advised victims to notify their banks to be on the lookout for suspicious account activity.
Dan KaplanDecember 14 2007
A laptop containing the personal information of an undisclosed number of Deloitte & Touche partners, principals and other employees was stolen while in possession of a contractor responsible for scanning the accounting firm's pension fund documents, SCMagazineUS.com learned today.
The computer contained confidential data, including names, Social Security numbers, birth dates, and other personnel information, such as hire and termination dates, according to a Dec. 6 letter Deloitte sent to victims. Some of the information belonged to people working at Deloitte subsidiaries.
The laptop, stolen during Thanksgiving week, was protected by a password but was not encrypted, according to the letter. Deloitte has no evidence any of the data has been used for fraudulent purposes, and police are investigating.
A company spokeswoman, in an email to SCMagazineUS.com, declined to reveal specifics about the incident.
“Yes, a laptop was stolen and Deloitte is working with the company involved and has communicated with its own people to help them limit any potential misuse of their data,” spokeswoman Deborah Harrington said. “That's the extent of our comment.”
Richard Baker, who worked as a manager in management consulting at Deloitte from 1990 to 1995, said he received a notification letter.
“What is particularly egregious about this situation is that Deloitte is a ‘noted' security expert with seminars, whitepapers, service lines, etc.,” he told SCMagazineUS.com in an email today. “One would think there would be security and encryption standards for all sensitive personal data, whether managed internally or by outside vendors.”
Baker said he now oversees the consulting division of a channel partner of Symantec, a major security firm.
Deloitte said in the letter that it has stopped working with the responsible vendor, who was not named, until it “can demonstrate that is has implemented appropriate data security protections. In addition we have an ongoing program to identify vendors who access confidential information regarding our personnel and to confirm that they have implemented appropriate protections.”
Deloitte, based in New York, plans to provide victims with one year of free credit-monitoring services, according to the letter. It also advised victims to notify their banks to be on the lookout for suspicious account activity.
SecureWorks: Commercial banking accounts targeted by Prg trojan variant
SecureWorks: Commercial banking accounts targeted by Prg trojan variant
Jim CarrDecember 17 2007
UpLevel, a Russian criminal organization, and its German affiliates are using a version of the Prg trojan to attack commercial banking clients, according to anti-virus vendor SecureWorks.
SecureWorks disclosed that the financially focused version of Prg has been in use for about six months, pilfering the commercial bank accounts of customers from several dozen banks in the United States and Europe.
The variant of the widely used “generic” version of Prg has been customized to perform fraudulent banking transactions, Don Jackson, senior security researcher at SecureWorks, who discovered the original Prg trojan, told SCMagazineUS.com.
"They put a lot of work into this," said Jackson. "They have logs on tens of thousands of victims, and send out targeted emails using information stolen in previous attacks."
The latest attack is being orchestrated by a German group working in conjunction with UpLevel, a Russian malware-developing organization, according to Jackson. He said that the German group purchased the confidential information of thousands of victims of previous Prg attacks from UpLevel, which is also providing hosted servers and various other services for the unnamed group.
The victims' confidential information was gleaned as a result of earlier hacks of online job sites, according to Jackson. UpLevel used the attacks to download trojans onto victims' computers, then collected personal information, such as bank account information.
UpLevel mined the stolen data for victims with commercial banking accounts, according to Jackson. The German group then used that information to send spear phishing emails telling victims to download software, which, in fact, contained the Prg trojan.
Prg runs without the user's knowledge when they log into a commercial account and transfer funds, Jackson said. The money moves to an account compromised in a previous attack, then is relocated again to avoid detection.
The original Prg trojan stole data, including banking URLs that victims entered into their web browsers. That trojan, in circulation for more than a year, was responsible for stealing the Social Security numbers, credit card numbers and other personal data from more than 50,000 victims in previous attacks, according to Jackson.
UpLevel members infected victims with the Prg trojan through spam emails with malicious links, infected websites and malicious ads, SecureWorks researchers said on a company blog.
SecureWorks estimated that the thieves have stolen more than $200,000 in the U.S. since attacks on banks began late last month, Jackson added. The two groups stole a similar total from U.K.-based accounts as well.
“We see only about 10 percent of the attacks," said Jackson. “We expect to see more than $1.2 million in losses."
SecureWorks is working with the US-CERT and the U.S. Secret Service to stop the attacks, Jackson said, warning bank customers to avoid visiting untrusted websites and clicking on emailed links.
Jim CarrDecember 17 2007
UpLevel, a Russian criminal organization, and its German affiliates are using a version of the Prg trojan to attack commercial banking clients, according to anti-virus vendor SecureWorks.
SecureWorks disclosed that the financially focused version of Prg has been in use for about six months, pilfering the commercial bank accounts of customers from several dozen banks in the United States and Europe.
The variant of the widely used “generic” version of Prg has been customized to perform fraudulent banking transactions, Don Jackson, senior security researcher at SecureWorks, who discovered the original Prg trojan, told SCMagazineUS.com.
"They put a lot of work into this," said Jackson. "They have logs on tens of thousands of victims, and send out targeted emails using information stolen in previous attacks."
The latest attack is being orchestrated by a German group working in conjunction with UpLevel, a Russian malware-developing organization, according to Jackson. He said that the German group purchased the confidential information of thousands of victims of previous Prg attacks from UpLevel, which is also providing hosted servers and various other services for the unnamed group.
The victims' confidential information was gleaned as a result of earlier hacks of online job sites, according to Jackson. UpLevel used the attacks to download trojans onto victims' computers, then collected personal information, such as bank account information.
UpLevel mined the stolen data for victims with commercial banking accounts, according to Jackson. The German group then used that information to send spear phishing emails telling victims to download software, which, in fact, contained the Prg trojan.
Prg runs without the user's knowledge when they log into a commercial account and transfer funds, Jackson said. The money moves to an account compromised in a previous attack, then is relocated again to avoid detection.
The original Prg trojan stole data, including banking URLs that victims entered into their web browsers. That trojan, in circulation for more than a year, was responsible for stealing the Social Security numbers, credit card numbers and other personal data from more than 50,000 victims in previous attacks, according to Jackson.
UpLevel members infected victims with the Prg trojan through spam emails with malicious links, infected websites and malicious ads, SecureWorks researchers said on a company blog.
SecureWorks estimated that the thieves have stolen more than $200,000 in the U.S. since attacks on banks began late last month, Jackson added. The two groups stole a similar total from U.K.-based accounts as well.
“We see only about 10 percent of the attacks," said Jackson. “We expect to see more than $1.2 million in losses."
SecureWorks is working with the US-CERT and the U.S. Secret Service to stop the attacks, Jackson said, warning bank customers to avoid visiting untrusted websites and clicking on emailed links.
Blame Canada: passport breach is "that bloody simple"
Blame Canada: passport breach is "that bloody simple"
The Globe and Mail reports that a security flaw in Passport Canada's website rewards a trivial level of effort with enough data to steal the identity of any individual applying for a Canadian passport. The story does not describe the flaw in technical terms, but the layman's description sketches one of the all-time classic flaws in bad web design. When a user applies for a passport, he or she can see a user ID in the URL. Simply changing a character in the user ID reveals all the records of the next user. This "hack" is so simple that an ordinary passport applicant using the site discovered the flaw by accident.
A better approach would have been to design the site without making the user IDs a visible part of the URLs. Same for any kind of database ID; we once wrote a story about a music-related e-commerce site that lost a bundle of money when a similar trick was used on product IDs showing up in URLs. The attacker changed the price of everything on the site to one cent (LiveSecurity subscribers can review the tale in "Dustin and the Price of Glory").
One way to hide such IDs: Pass them through a hashing algorithm so that what shows in the URL is not the literal ID. But more importantly -- because sooner or later, some user will try to twiddle digits -- the site should have an authentication mechanism built in, preventing user 123456 from "deciding" that she is user 123457.
Custom web applications now perch shamefully at the top of the list of hacker targets. But web apps have been popular targets for at least three or four years now, and any interested admin can find a plethora of help, tips, best practices, and configuration advice online. For example:
OWASP Application Security FAQ
SQL Injection: Modes of Attack, Defence, and Why It Matters
If your company's web server uses Microsoft's IIS, try the IIS Lockdown tool
The worst part of the Canadian breach? After the problem was spotted, fixed, and the site was brought back up, the Globe reports, "a few keystrokes sufficed to reveal some of the personal information of passport applicants, including names, addresses and numbers for references and emergency contacts." The site wasn't really fixed. No wonder one of the Canadian users of the site groused, "It's supposed to use high-tech security. You'd think it wouldn't be that bloody simple." Is this another example of security falling in the cracks between the IT group and the web dev team? Before you blame Canada, better check for similar problems inside the bureaucracy you call home. -- Scott Pinzon, CISSP
The Globe and Mail reports that a security flaw in Passport Canada's website rewards a trivial level of effort with enough data to steal the identity of any individual applying for a Canadian passport. The story does not describe the flaw in technical terms, but the layman's description sketches one of the all-time classic flaws in bad web design. When a user applies for a passport, he or she can see a user ID in the URL. Simply changing a character in the user ID reveals all the records of the next user. This "hack" is so simple that an ordinary passport applicant using the site discovered the flaw by accident.
A better approach would have been to design the site without making the user IDs a visible part of the URLs. Same for any kind of database ID; we once wrote a story about a music-related e-commerce site that lost a bundle of money when a similar trick was used on product IDs showing up in URLs. The attacker changed the price of everything on the site to one cent (LiveSecurity subscribers can review the tale in "Dustin and the Price of Glory").
One way to hide such IDs: Pass them through a hashing algorithm so that what shows in the URL is not the literal ID. But more importantly -- because sooner or later, some user will try to twiddle digits -- the site should have an authentication mechanism built in, preventing user 123456 from "deciding" that she is user 123457.
Custom web applications now perch shamefully at the top of the list of hacker targets. But web apps have been popular targets for at least three or four years now, and any interested admin can find a plethora of help, tips, best practices, and configuration advice online. For example:
OWASP Application Security FAQ
SQL Injection: Modes of Attack, Defence, and Why It Matters
If your company's web server uses Microsoft's IIS, try the IIS Lockdown tool
The worst part of the Canadian breach? After the problem was spotted, fixed, and the site was brought back up, the Globe reports, "a few keystrokes sufficed to reveal some of the personal information of passport applicants, including names, addresses and numbers for references and emergency contacts." The site wasn't really fixed. No wonder one of the Canadian users of the site groused, "It's supposed to use high-tech security. You'd think it wouldn't be that bloody simple." Is this another example of security falling in the cracks between the IT group and the web dev team? Before you blame Canada, better check for similar problems inside the bureaucracy you call home. -- Scott Pinzon, CISSP
