TEHRAN, Iran – Iranian media reports say the country's nuclear agency is trying to combat a complex computer worm that has affected industrial sites in Iran and is capable of taking over power plants.
The semi-official ISNA news agency says Iranian nuclear experts met this week to discuss how to remove the malicious computer code, dubbed Stuxnet, which can take over systems that control the inner workings of industrial plants.
Experts in Germany discovered the worm in July. It has since shown up in attacks in Iran, Indonesia, India and the U.S.
Saturday, September 25, 2010
Thursday, September 23, 2010
IRS Letters to Citizens Still Ripe for Identity Theft
The Internal Revenue Service (IRS) has yet to comply with a May 2007 federal order to remove the unnecessary use of Social Security numbers from correspondence with citizens, which can lead to identity theft, according to a recent report by the Treasury Inspector General for Tax Administration.
According to the report, the Office of Management and Budget (OMB) gave federal agencies 120 days to develop a plan to eliminate the unnecessary collection and use of social security numbers and 18 months to implement the plan.
Although the IRS has a plan in place, it has yet to draft detailed implementation and compliance management milestones, and target dates have not yet been established to eliminate or reduce taxpayer Social Security numbers from its correspondence with the public, according to the Inspector General’s report.
“Taxpayers need to be assured that the IRS is taking every precaution to protect their private information from inadvertent disclosure,” according to the Inspector General.
The number one consumer complaint during 2009 was identity theft, which often requires identity thieves to use victims’ Social Security numbers, according to a 2010 Federal Trade Commission report.
In 2010, the IRS mailed more than 42 million notices and letters to individual taxpayers for various reasons, including balance due notices. Most of those notices and letters included taxpayers’ Social Security numbers because they required the taxpayers to respond to the IRS.
The IRS submitted the first release of its plan to reduce or eliminate the use of Social Security numbers to the Department of the Treasury in November 2007 and has provided three releases of its plan since then, the last in February 2009.
However, to date it has only redacted or shortened taxpayers’ Social Security
numbers from only a small number of systems, notices, and forms, and there are no target dates for decisions on whether taxpayers’ Social Security numbers can be removed from notices and letters, according to the Inspector General’s report.
According to the report, the Office of Management and Budget (OMB) gave federal agencies 120 days to develop a plan to eliminate the unnecessary collection and use of social security numbers and 18 months to implement the plan.
Although the IRS has a plan in place, it has yet to draft detailed implementation and compliance management milestones, and target dates have not yet been established to eliminate or reduce taxpayer Social Security numbers from its correspondence with the public, according to the Inspector General’s report.
“Taxpayers need to be assured that the IRS is taking every precaution to protect their private information from inadvertent disclosure,” according to the Inspector General.
The number one consumer complaint during 2009 was identity theft, which often requires identity thieves to use victims’ Social Security numbers, according to a 2010 Federal Trade Commission report.
In 2010, the IRS mailed more than 42 million notices and letters to individual taxpayers for various reasons, including balance due notices. Most of those notices and letters included taxpayers’ Social Security numbers because they required the taxpayers to respond to the IRS.
The IRS submitted the first release of its plan to reduce or eliminate the use of Social Security numbers to the Department of the Treasury in November 2007 and has provided three releases of its plan since then, the last in February 2009.
However, to date it has only redacted or shortened taxpayers’ Social Security
numbers from only a small number of systems, notices, and forms, and there are no target dates for decisions on whether taxpayers’ Social Security numbers can be removed from notices and letters, according to the Inspector General’s report.
Saturday, August 28, 2010
Senators Introduce Federal Data Breach Notification Bill
On August 5, 2010, the Chairman of the Senate Commerce Subcommittee on Consumer Protection, Product Safety, and Insurance Mark Pryor (D-AR) and Full Committee Chairman John Rockefeller (D-WV) introduced the “Data Security and Breach Notification Act of 2010,” S. 3742, which would require businesses to protect personal information in their possession, to notify residents if that information is breached, and to adopt a data security policy.
Currently, there is no federal notification requirement for a data breach in most industries, although the vast majority of states have enacted data breach notification laws. The proposed bill requires entities to notify consumers within 60 days of a breach and to provide consumers with two years of credit monitoring services.
The proposed bill would authorize the FTC to set national standards for safeguarding personal information and to seek up to $5 million in civil penalties for failure to comply.
If enacted, the bill would preempt all state data breach notification and data security laws and regulations. Only companies covered by the Fair Credit Reporting Act and in compliance with that act would be exempt from the proposed law. Last month, Sens. Tom Carper, D-DE, and Robert Bennett, R-UT, reintroduced a similar bill, S. 3579.
Currently, there is no federal notification requirement for a data breach in most industries, although the vast majority of states have enacted data breach notification laws. The proposed bill requires entities to notify consumers within 60 days of a breach and to provide consumers with two years of credit monitoring services.
The proposed bill would authorize the FTC to set national standards for safeguarding personal information and to seek up to $5 million in civil penalties for failure to comply.
If enacted, the bill would preempt all state data breach notification and data security laws and regulations. Only companies covered by the Fair Credit Reporting Act and in compliance with that act would be exempt from the proposed law. Last month, Sens. Tom Carper, D-DE, and Robert Bennett, R-UT, reintroduced a similar bill, S. 3579.
Thursday, August 26, 2010
False Sense of Computer Security
Keyloggers are designed to silently record all of one's computer activity. They are commonly used for parents to monitor their children's computer activity. Now they are being used for criminal activity ranging from spying on individuals, identity theft and data theft.
The security team at SpyReveal tested the leading anti-spyware and anti-virus software against ten of the most popular keyloggers. The results were astonishing! Most of the leading security software used to combat viruses and spyware failed to detect 70% of the keyloggers. While most failed to detect any keyloggers at all, SpyReveal successfully detected all keyloggers.
Computer users are receiving a false sense of security when installing various security applications. With the explosion in online banking, the proliferation of identity theft is greater than ever. Many users install an anti-spyware solution with the expectation of being safe from identity theft. Unfortunately, they are still at an extremely high risk for identity theft and data logging.
"More and more news stories are being published of hackers who have obtained credit card records by using keyloggers", said Mr. Hankinson, SpyReveal's co-founder. "Yet, we still see major players in the security industry continue to fail at this specific type of problem."
Still don't think you or your business is at risk? Take for example Verizon's 2009 Data Breach Investigations Supplemental Report which states "Keyloggers and spyware.... played a crucial role in larger breach scenarios in which hundreds of millions of records were compromised."
"Consumers and businesses should not rely on a single solution for security. Each has a specific purpose. We want consumers to realize that even though their anti-spyware software says 'Nothing Found', that any keylogger could still be present, recording credit card information or business intellectual property," Mr. Hankinson added.
It is important for users to purchase security solutions that are designed for a dedicated purpose to receive the highest degree of protection, without being too narrow. With software like SpyReveal, you can rest assured that you are protected from most keyloggers available on the open market.
Thursday, August 19, 2010
Jennifer Aniston named as victim of salon fraud
The owner of a Beverly Hills beauty salon was arrested on Wednesday on charges of stealing credit card information from Jennifer Aniston, Anne Hathaway and Liv Tyler and running up tens of thousands of fraudulent payments on their accounts.
According to court documents in the case, a witness claimed that Cher, Melanie Griffith and former "Felicity" television star Scott Speedman were also victims of the fraud.
The owner of Chez Gabriela Studio is accused of swindling $214,000 from Tyler alone in a five-month period last year, according to a court affidavit.
The U.S. Attorney's office in Los Angeles said salon owner Maria Gabriella Perez, 51, is accused of making at least $280,000 of fraudulent charges in a one-year period.
Perez is alleged to have used credit card information provided by celebrities and other clients for legitimate services, and later entered the details manually to run up unauthorized charges.
Aniston, Hathaway, Cher, Tyler, Griffith and Speedman were named in the court papers as among those who saw unauthorized charges on their credit cards.
Representatives for Cher, however, told celebrity website TMZ.com that the singer and actress was not a victim and did not know why she had been named in the court papers.
According to court documents in the case, a witness claimed that Cher, Melanie Griffith and former "Felicity" television star Scott Speedman were also victims of the fraud.
The owner of Chez Gabriela Studio is accused of swindling $214,000 from Tyler alone in a five-month period last year, according to a court affidavit.
The U.S. Attorney's office in Los Angeles said salon owner Maria Gabriella Perez, 51, is accused of making at least $280,000 of fraudulent charges in a one-year period.
Perez is alleged to have used credit card information provided by celebrities and other clients for legitimate services, and later entered the details manually to run up unauthorized charges.
Aniston, Hathaway, Cher, Tyler, Griffith and Speedman were named in the court papers as among those who saw unauthorized charges on their credit cards.
Representatives for Cher, however, told celebrity website TMZ.com that the singer and actress was not a victim and did not know why she had been named in the court papers.
Sunday, August 8, 2010
Rogue AV: A wolf in sheep's clothing
Rogue anti-malware, also known as rogue AV, has become the delivery vehicle of choice for the cybercriminals seeking to infect endpoints with their payloads. Those endpoints consist of both the consumer and enterprise. The ESET Global Threat Trends Report for April 2010 contains a short article called “Free but Fake.” Better yet, one of our most active researchers, Cristian Borghello from our Latin American office, wrote an excellent paper on rogue anti-malware.
If you haven't had a chance to view the convincingly crafted fake scans from our various rogue AV pages, here's one that I took off of one of my testing workstations prior to the infection. The first stage requires the user to take a particular action. In this case – and many others – it can't infect the system without human assistance.
According to a recent paper on large-scale exploits and emergent threats that Google released in late April at the Usenix Workshop, rogue AV accounts for more than 15 percent of all malware Google detects. In the report, Google outlines that from January 2009 until February 2010, more than 11,000 domains were involved in rogue AV distribution.
I have also had recent discussions with colleagues over fake/rogue anti-malware that didn't break the law by infecting endpoints. This isn't actually fake security software, just highly substandard with disproportionately strong messaging.
This aligns strongly with an article from Bruce Schneier that I recall reading entitled “A Security Market For Lemons” (Wired, April 2007). In his article Bruce states:
““Of course, it's more expensive to make an actually secure USB drive. Good security design takes time, and necessarily means limiting functionality. Good security testing takes even more time, especially if the product is any good. This means the less-secure product will be cheaper, sooner to market and have more features. In this market, the more-secure USB drive is going to lose out.”
Bruce closes the article with:
““With so many mediocre security products on the market, and the difficulty of coming up with a strong quality signal, vendors don't have strong incentives to invest in developing good products. And the vendors that do tend to die a quiet and lonely death.”
I agree that a new tactic that's not illegal, such as a deluge of confusing messages and products (more than our customers currently experience), has the potential to impact the revenue of legitimate companies and leads the end-user into having a false sense of security with a highly inert product.
So what do we do about blatantly rogue anti-malware? Below are four points to consider:
■The executable itself shouldn't be allowed to touch or run on the endpoint. While possible, this is easier said than done due to the myriad permutations of endpoint configurations.
■Rogue software, like other malware, may be detectable via behavioral analysis. Implement a highly regarded anti-malware product with excellent static and/or dynamic detection (i.e., positive user feedback and presale dialog – not marketing hype)
■The distribution of the executable is dependent on very convincing JavaScript and associated graphics. Filtering for these, while tedious, can yield big payoffs.
■If the rogue executable is discovered, send it to the security response team for your anti-malware product. This allows them to add static detection and update their dynamic detection algorithms.
Attacks are cyclical, so once there is a much more effective means for dealing with rogue AV, you can rest assured there will soon be another angle leveraged to gain a foothold in the endpoint. In the meantime, it's an arms race and there are a lot of security vendors working hard to meet the escalating threats head-on. As a security community, keeping the lines of communication open and flowing to share threat intelligence is one of our greatest strengths in this protracted fight.
If you haven't had a chance to view the convincingly crafted fake scans from our various rogue AV pages, here's one that I took off of one of my testing workstations prior to the infection. The first stage requires the user to take a particular action. In this case – and many others – it can't infect the system without human assistance.
According to a recent paper on large-scale exploits and emergent threats that Google released in late April at the Usenix Workshop, rogue AV accounts for more than 15 percent of all malware Google detects. In the report, Google outlines that from January 2009 until February 2010, more than 11,000 domains were involved in rogue AV distribution.
I have also had recent discussions with colleagues over fake/rogue anti-malware that didn't break the law by infecting endpoints. This isn't actually fake security software, just highly substandard with disproportionately strong messaging.
This aligns strongly with an article from Bruce Schneier that I recall reading entitled “A Security Market For Lemons” (Wired, April 2007). In his article Bruce states:
““Of course, it's more expensive to make an actually secure USB drive. Good security design takes time, and necessarily means limiting functionality. Good security testing takes even more time, especially if the product is any good. This means the less-secure product will be cheaper, sooner to market and have more features. In this market, the more-secure USB drive is going to lose out.”
Bruce closes the article with:
““With so many mediocre security products on the market, and the difficulty of coming up with a strong quality signal, vendors don't have strong incentives to invest in developing good products. And the vendors that do tend to die a quiet and lonely death.”
I agree that a new tactic that's not illegal, such as a deluge of confusing messages and products (more than our customers currently experience), has the potential to impact the revenue of legitimate companies and leads the end-user into having a false sense of security with a highly inert product.
So what do we do about blatantly rogue anti-malware? Below are four points to consider:
■The executable itself shouldn't be allowed to touch or run on the endpoint. While possible, this is easier said than done due to the myriad permutations of endpoint configurations.
■Rogue software, like other malware, may be detectable via behavioral analysis. Implement a highly regarded anti-malware product with excellent static and/or dynamic detection (i.e., positive user feedback and presale dialog – not marketing hype)
■The distribution of the executable is dependent on very convincing JavaScript and associated graphics. Filtering for these, while tedious, can yield big payoffs.
■If the rogue executable is discovered, send it to the security response team for your anti-malware product. This allows them to add static detection and update their dynamic detection algorithms.
Attacks are cyclical, so once there is a much more effective means for dealing with rogue AV, you can rest assured there will soon be another angle leveraged to gain a foothold in the endpoint. In the meantime, it's an arms race and there are a lot of security vendors working hard to meet the escalating threats head-on. As a security community, keeping the lines of communication open and flowing to share threat intelligence is one of our greatest strengths in this protracted fight.
PCI DSS 1.2: Changes, best practices and tips
PCI DSS is a global information security standard consisting of 12 different requirements – assembled and released by the Payment Card Industry Security Standards Council (PCI SSC). It was created to assist organizations that hold, process or pass on credit card information to help in preventing credit card fraud.
This particular blog post will detail some of the differences between PCI DSS 1.1 and 1.2, and offer several best practices and four useful tips in consideration of obtaining and maintaining PCI DSS compliance. Changes are in the works for DSS, with a formal announcement coming in the fall,
Below are some of the key changes from PCI DSS v1.1 to v1.2:
■Incorporates existing and new best practices
■Provides further scoping and reporting clarification
■Eliminates overlapping sub-requirements and consolidates documentation
■Enhances the frequently asked questions (FAQ) and glossary to facilitate understanding of the security process.
Wireless network changes from v1.1 to v1.2:
■Requirement 4.1.1.
■In v1.1 there were provisions for WEP (Wired Equivalent Privacy) which is a weak encryption.
■Removing the requirement for disabling SSID broadcasts is new in v1.2.
Anti-virus requirement differences:
■In v1.2, there is a clarification regarding the use of anti-virus software – namely that it applies to all operating system types
■Requirement number 5.1.1 states: “Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.”
Best practices:
■Constant vigilance: Knowing that there is no 100% guaranteed “silver-bullet” for network security companies. Instead, they must maintain constant vigilance of their security – from physical security to network configuration/security. A “set it and forget it” attitude in the security world sets false expectations of ongoing security.
■Network traffic anomaly detection
■Log analysis: Using software to correlate various security logs (e.g., firewall, web server, remote access) to spot trends
■Heuristic detection of malicious software: Heuristically detecting malicious software on critical systems that are connected to the vendor's network – not just the systems that handle customer data
■Implementing layered security: If one defense fails, the others have a chance of stopping the attack
■Patch management: Maintaining an effective patch management system, procedures, or both is a key security measure
Four useful tips (going beyond the checklist):
1. Compliance is not a one-time project – it is an ongoing process
a. One of the biggest dangers of the checklist is that it can't be viewed as a one-time project. It is an ongoing process of checking/re-checking the various security controls, as well as enforcing them. Companies should not consider themselves immune to attacks simply because they have achieved compliance.
2. End-to-end encryption (E3)
a. PCI DSS doesn't mention, or require, encrypting the data from the point at which the customer's card was “swiped.” This step will significantly reduce the value of data if it is intercepted.
3. Avoid the low-hanging fruit
a. People tend to go for the path of least resistance. For instance, if their network is unique in its design, and there is a new method of accessing data, and the checklist does not cover the new method, it might be glossed over and compliance would still be achieved. Scheduled reviews of a company's PCI DSS compliance will help ensure that as technology and networks continue to progress, new threat vectors are addressed. For instance, Requirement 5 of the PCI DSS states that for compliance a vendor must use and regularly update anti-virus programs. As there are varying levels in the quality of anti-virus software, a vendor could choose to implement a low detection/high false-positive anti-virus program and have a fairly ineffective anti-virus application running on their systems.
4. “Chain of events” or the “error chain”
a. As in the aviation world, when there is an accident it is referred to as a “chain of events” or the “error chain.” These terms simply mean that multiple factors, rather than a single one, lead to an accident. The same can be said for security incidents, such as data leakage.
Resources:
■PCI Security Standard Council web site: https://www.pcisecuritystandards.org/
■PCI DSS v1.2 Requirements and Security Assessment Procedures: https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html
Do you have additional best practices, tips or observations? You can also share your experiences regarding PCI DSS – experiences, challenges, benefits or any other comments regarding your company and credit card security.
This particular blog post will detail some of the differences between PCI DSS 1.1 and 1.2, and offer several best practices and four useful tips in consideration of obtaining and maintaining PCI DSS compliance. Changes are in the works for DSS, with a formal announcement coming in the fall,
Below are some of the key changes from PCI DSS v1.1 to v1.2:
■Incorporates existing and new best practices
■Provides further scoping and reporting clarification
■Eliminates overlapping sub-requirements and consolidates documentation
■Enhances the frequently asked questions (FAQ) and glossary to facilitate understanding of the security process.
Wireless network changes from v1.1 to v1.2:
■Requirement 4.1.1.
■In v1.1 there were provisions for WEP (Wired Equivalent Privacy) which is a weak encryption.
■Removing the requirement for disabling SSID broadcasts is new in v1.2.
Anti-virus requirement differences:
■In v1.2, there is a clarification regarding the use of anti-virus software – namely that it applies to all operating system types
■Requirement number 5.1.1 states: “Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.”
Best practices:
■Constant vigilance: Knowing that there is no 100% guaranteed “silver-bullet” for network security companies. Instead, they must maintain constant vigilance of their security – from physical security to network configuration/security. A “set it and forget it” attitude in the security world sets false expectations of ongoing security.
■Network traffic anomaly detection
■Log analysis: Using software to correlate various security logs (e.g., firewall, web server, remote access) to spot trends
■Heuristic detection of malicious software: Heuristically detecting malicious software on critical systems that are connected to the vendor's network – not just the systems that handle customer data
■Implementing layered security: If one defense fails, the others have a chance of stopping the attack
■Patch management: Maintaining an effective patch management system, procedures, or both is a key security measure
Four useful tips (going beyond the checklist):
1. Compliance is not a one-time project – it is an ongoing process
a. One of the biggest dangers of the checklist is that it can't be viewed as a one-time project. It is an ongoing process of checking/re-checking the various security controls, as well as enforcing them. Companies should not consider themselves immune to attacks simply because they have achieved compliance.
2. End-to-end encryption (E3)
a. PCI DSS doesn't mention, or require, encrypting the data from the point at which the customer's card was “swiped.” This step will significantly reduce the value of data if it is intercepted.
3. Avoid the low-hanging fruit
a. People tend to go for the path of least resistance. For instance, if their network is unique in its design, and there is a new method of accessing data, and the checklist does not cover the new method, it might be glossed over and compliance would still be achieved. Scheduled reviews of a company's PCI DSS compliance will help ensure that as technology and networks continue to progress, new threat vectors are addressed. For instance, Requirement 5 of the PCI DSS states that for compliance a vendor must use and regularly update anti-virus programs. As there are varying levels in the quality of anti-virus software, a vendor could choose to implement a low detection/high false-positive anti-virus program and have a fairly ineffective anti-virus application running on their systems.
4. “Chain of events” or the “error chain”
a. As in the aviation world, when there is an accident it is referred to as a “chain of events” or the “error chain.” These terms simply mean that multiple factors, rather than a single one, lead to an accident. The same can be said for security incidents, such as data leakage.
Resources:
■PCI Security Standard Council web site: https://www.pcisecuritystandards.org/
■PCI DSS v1.2 Requirements and Security Assessment Procedures: https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html
Do you have additional best practices, tips or observations? You can also share your experiences regarding PCI DSS – experiences, challenges, benefits or any other comments regarding your company and credit card security.
Subscribe to:
Posts (Atom)
Posts
