The big buzz this year around security assessments and audits is all about HIPAA. This was #6 in SecureState's Top 8 of 08 and, to say the least, there’s quite a bit of tension in the air as organizations hold their breath. While PCI is still the most active, all of our clients with HIPAA concerns – which is many – are on constant watch to see what HIPAA is really going to mean. To date, HIPAA has been a little weak as organizations have been left to their own devices to operate around a risk-based approach for HIPAA. But that approach has time and time again proven to not be diligent enough and/or favors the business over security. But now, the audits are happening, HIPAA is getting some teeth, and most organizations are scrambling to figure out what ‘their’ interpretation is and if what they did is enough. Everyone knows that the first audit was done last year at a hospital and have seen the list of‘42 questions’ that were asked. But those hardly helped as they really didn’t indicate what the expectations were. Now other HIPAA organizations are being audited including retailers and insurers. The results are supposed to be posted on the CMS/HHS site, but so far nothing is out there. But hope is not lost as the details emerge from our clients and other information.
First of all, it is important to realize who is doing the audits. It is KPMG’s government practice and working for a government agency. As such, it should be expected that they would leveraging NIST standards. The second indicator is from NIST itself. The CMS/HHS first worked with NIST to develop the 800-66 publication for understanding and implementing the HIPAA Security Rule. But that proved to be fairly vague and mainly referencing a bunch of other NIST standards but not providing a lot of ‘how’. Based on that type of feedback, they have issued a draft version ( http://csrc.nist.gov/publications/drafts/800-66-Rev1/Draft_SP800-66-Rev1.pdf ) that has finally provided a solid understanding of how to implement the Security Rule – by mapping it to NIST 800-53 that outlines ‘recommended controls’, not unlike ISO 27002 (formerly 17799). Ultimately, this has been further confirmed in reviewing some of the HIPAA audit draft reports that NIST 800-53 is the core of the KPMG audit framework.
So now you know what they are looking for and what to expect. If you were looking for a solid ‘checklist’ for gapping your HIPAA program, look no further than NIST 800-53, or even better, the draft of NIST 800-66. The draft is great as it also has sample questions that the auditor might be asking as well – hint hint. The other referenced NIST standards can also be helpful, especially if your organization uses a particular technology extensively e.g. 800-124 draft on cell/PDA security. Regardless of what the checklist is, the bottom line is HIPAA has not had a strong enough impact for organizations, much like SOX. As a result, companies aren’t really getting secure as originally intended. Every hospital or insurance company we have reviewed has failed system audits and penetration testing - and we're the good guys. Getting compliant, even to a higher level, isn’t getting secure. And odds are, your organization has more than HIPAA data out there.
So do the right thing, do due diligence, do it soon, and get your organization to a defensible position before the audit. Base your decisions on the intent of the controls outlined in 800-53/66, not the wording or sample interpretation. Don't wait for the audit, findings and fines - or even worse - the breach. It's a lot more expensive to implement security after the fact than before.
Read more!
Tuesday, August 5, 2008
Friday, August 1, 2008
Thank You For Putting Customer Satisfaction Last!
Taking a break from the normal week to write on this topic that has been bothering me for quite a while. If a company loses your data… and you are at risk for identity theft, they think it is kosher to offer you “up to one year of identity theft monitoring”.
So my question is… What about the next 2-20 years of your life?
A quick search on Google reveals that credit monitoring costs sit in the $12/month range. Yes that means if they lose your Social Security Number, Credit Card Numbers, PINs, etc… They owe you just $144. A sort of… “Oops! Sorry we lost your data.”
Five years down the road when someone decides to cash in on the theft they have made of YOUR data… Weellllllll… You’re on your own!
What organizations should start doing (besides including security in everything they do) is at least offer a lifetime worth of this service. This would say “We are extremely sorry that we lost your data, we will do anything we can to make sure that it will not be used maliciously. And if someone does… this will help you be able to stop them before they get anything!”
So until that day comes... (or never)… Those who have had their identity stolen will have problems like this guy... for years to come for much longer than “up to one year.”
Read more!
So my question is… What about the next 2-20 years of your life?
A quick search on Google reveals that credit monitoring costs sit in the $12/month range. Yes that means if they lose your Social Security Number, Credit Card Numbers, PINs, etc… They owe you just $144. A sort of… “Oops! Sorry we lost your data.”
Five years down the road when someone decides to cash in on the theft they have made of YOUR data… Weellllllll… You’re on your own!
What organizations should start doing (besides including security in everything they do) is at least offer a lifetime worth of this service. This would say “We are extremely sorry that we lost your data, we will do anything we can to make sure that it will not be used maliciously. And if someone does… this will help you be able to stop them before they get anything!”
So until that day comes... (or never)… Those who have had their identity stolen will have problems like this guy... for years to come for much longer than “up to one year.”
Read more!
Friday, July 25, 2008
Lame Man's Terms
Once again it’s time for the Lame Man’s View… only one story this week… and it’s a good one!
It comes to us from San Francisco. According to numerous reports on the web and on TV… The City of San Francisco has had several breaches and has spent most of their time notifying customers and citizens that their Social Security Numbers may have been compromised. Now this story is good in my eyes because of the way the City of San Francisco operates. This is a city that claims it is sovereign from the Federal Government and does not have to follow certain laws regarding harboring illegal aliens. I think the Federal Government should take this time to not provide aid in any form to the City of San Francisco to show them what it would really be like… were they actually sovereign.
http://youtube.com/watch?v=tisfvHviIGA
That’s all for this week… Catch me again next Friday…
Read more!
It comes to us from San Francisco. According to numerous reports on the web and on TV… The City of San Francisco has had several breaches and has spent most of their time notifying customers and citizens that their Social Security Numbers may have been compromised. Now this story is good in my eyes because of the way the City of San Francisco operates. This is a city that claims it is sovereign from the Federal Government and does not have to follow certain laws regarding harboring illegal aliens. I think the Federal Government should take this time to not provide aid in any form to the City of San Francisco to show them what it would really be like… were they actually sovereign.
http://youtube.com/watch?v=tisfvHviIGA
That’s all for this week… Catch me again next Friday…
Read more!
You want my what? Really.
They say that identity theft is a larger and more profitable business than drug trafficking.
I wonder why.
Hmmm, I don't know, maybe because EVERYONE HAS MY PERSONAL INFORMATION.
Help desk analyst I talked to recently:
"In order for me to help you, I'll need your Social Security Number."
My response: Really?
Person from certification body auditing my credentials:
"If you'll give me your Social Security Number, I might be able to save some time in collecting the information I need."
My response: Really?
Nurse at doctor's office that I spent all of 6 minutes at:
"I'll need all of your information filled out on this form, including your Social Security Number."
My response: Really.
Enough is enough. In the past 3 weeks, I've been asked for my Social Security Number by 7 people that I didn't know or inherently trust. Some of these people had legitimate reasons for asking for my info, but for others it was simply them wanting to "save some time".
As security professionals and evaluators of controls and procedures, we should be first to say, "Hey, how about we NOT ask for their SSN and maybe use other sources of info to verify their identity?"
I know what you're thinking.Wait, let ME say it. Social Security Numbers are one of the few reliable sources of personally identifiable information out there. I understand this. I just wonder why organizations worldwide use them so publicly and openly.
Bottom line: our Social Security Numbers shouldn't be the one and only source of information that we use to identify the people that interact with us. Organizations all over the world should be a little more creative with this process.
And to the people that GIVE this information so freely to the people that request it, all you need to do is say one word: "Why?" The organization or person should be able to answer this. If the response you're given makes your stomach hurt, just say: "Is there another piece of information that I can give you to identify me?" Most of the time there will be, and asking simple questions helps to limit the exposure in a number of ways.
Let me esplain...no wait, there is too much, let me sum up:
Read more!
I wonder why.
Hmmm, I don't know, maybe because EVERYONE HAS MY PERSONAL INFORMATION.
Help desk analyst I talked to recently:
"In order for me to help you, I'll need your Social Security Number."
My response: Really?
Person from certification body auditing my credentials:
"If you'll give me your Social Security Number, I might be able to save some time in collecting the information I need."
My response: Really?
Nurse at doctor's office that I spent all of 6 minutes at:
"I'll need all of your information filled out on this form, including your Social Security Number."
My response: Really.
Enough is enough. In the past 3 weeks, I've been asked for my Social Security Number by 7 people that I didn't know or inherently trust. Some of these people had legitimate reasons for asking for my info, but for others it was simply them wanting to "save some time".
As security professionals and evaluators of controls and procedures, we should be first to say, "Hey, how about we NOT ask for their SSN and maybe use other sources of info to verify their identity?"
I know what you're thinking.Wait, let ME say it. Social Security Numbers are one of the few reliable sources of personally identifiable information out there. I understand this. I just wonder why organizations worldwide use them so publicly and openly.
Bottom line: our Social Security Numbers shouldn't be the one and only source of information that we use to identify the people that interact with us. Organizations all over the world should be a little more creative with this process.
And to the people that GIVE this information so freely to the people that request it, all you need to do is say one word: "Why?" The organization or person should be able to answer this. If the response you're given makes your stomach hurt, just say: "Is there another piece of information that I can give you to identify me?" Most of the time there will be, and asking simple questions helps to limit the exposure in a number of ways.
Let me esplain...no wait, there is too much, let me sum up:
- If you're in a crowded area, and someone asked you to verbally give them your credit card number, would you do it? I hope not. Granted, the number of people that can memorize 12 to 16 digits after hearing them once is pretty limited, but you get my point.
- The majority of the time, call center operators that ask for anything related to your Social Security Number are only asking for the last 4 digits. Most of the time this is all that's visible to them on the monitor in front of them. If someone is asking for the full meal deal, take caution and again ask, "Why?".
- Stay on the side of caution when ANYONE asks for your SSN. Be cautious. Once you give it up, that's it. It's not like you can call American Express and ask them to issue you a new one.
Read more!
Tuesday, July 22, 2008
The big DNS security hole hype exposed
Dan Kaminsky released a little bit ago a joint effort to fix a major and "critical" security flaw with multiple vendors regarding DNS. Dan had stated he was not going to release the vulnerability until his BlackHat speaking in July, but it appears it was already leaked.
DNS Cache Poisoning is nothing new, on July 22, 1999 Hillary Clinton's site was subject to DNS cache poisoning:
http://www.cnn.com/TECH/computing/9907/22/hillary.idg/
It appears that the vulnerability itself is due to predictable TXID's and the lack of port randomization in DNS. Based on TXID inspection (and the blog from Microsoft) it appears that the 4-8 bits are predictable and are able to determine the PRNG state and predict the TXID.
To fix DNS Cache Poisoning, the PRNG algorithm was applied to the TXID or transaction ID's. The vulnerability lies within TXID where the 4-8 bits are predictable allowing the attacker to predict the next TXID. Here's how the attack is suppose to work (hypothetically):
Attacker queries nameserverA for yahoo.com's IP address through DNS. nameserverA doesn't know the IP of yahoo.com. nameserverA goes to the root name servers and says wheres the listings for .com, nameserverA goes to the listings for all .com and looks for the authoritative DNS server for yahoo.com. After that the IP is resolved and you can browse normally to yahoo.com. Where the attack is performed is the request from nameserverA to the authoritative DNS server, when nameserverA sends a request to the root server, the root server sends back a "referral" which tells nameserverA where to go for the .com listings. Contained in this exchange of information is the TXID. It keeps going down the list to various DNS servers, ultimately to the authoritative DNS server.
Our guess at where the attack occurs is the response back from the root server to respond on where yahoo.com's server resides. If an attacker can spoof a valid TXID and say yahoo.com's nameserver is really at ns.badhacker.com and not ns.yahoo.com and ultimately resolves to 1.1.1.1 instead of 2.2.2.2, we can perform cache poisoning of that name server.
So initial speculations that this is bad is pretty accurate and why all the hush was kept to allow all vendors to patch the systems accordingly. Kudos goes out to Dan Kaminsky for taking all of the scrutiny over all of this and allowing vendors time to patch the systems to something that was in fact not just hype but could have major implications if exploited successfully.
I hope all of your DNS servers are patched, a POC should be pretty easy to write off of this.
Special thanks to Microsoft for releasing details about the patch and letting us know what the vulnerability was:
http://blogs.technet.com/swi/archive/2008/04/09/ms08-020-how-predictable-is-the-dns-transaction-id.aspx
Special thanks to John Melvin from SecureState for helping me out on this.
Again this is purely hypothetical, this hasn't been confirmed nor denied.
UPDATE: Update to this post, it appears that it has been confirmed and found by Halvar Flake blog. In addition matasano also discovered it but the site was put up temporarily and taken down when discovered, a mirrored site can be found at: http://beezari.livejournal.com/141796.html. Patch your servers folks!
PATCH: What the patch appears to do, pretty cut and dry, it makes the TXID truly random and randomizes the DNS ports pretty much making this attack useless.
Read more!
DNS Cache Poisoning is nothing new, on July 22, 1999 Hillary Clinton's site was subject to DNS cache poisoning:
http://www.cnn.com/TECH/computing/9907/22/hillary.idg/
It appears that the vulnerability itself is due to predictable TXID's and the lack of port randomization in DNS. Based on TXID inspection (and the blog from Microsoft) it appears that the 4-8 bits are predictable and are able to determine the PRNG state and predict the TXID.
To fix DNS Cache Poisoning, the PRNG algorithm was applied to the TXID or transaction ID's. The vulnerability lies within TXID where the 4-8 bits are predictable allowing the attacker to predict the next TXID. Here's how the attack is suppose to work (hypothetically):
Attacker queries nameserverA for yahoo.com's IP address through DNS. nameserverA doesn't know the IP of yahoo.com. nameserverA goes to the root name servers and says wheres the listings for .com, nameserverA goes to the listings for all .com and looks for the authoritative DNS server for yahoo.com. After that the IP is resolved and you can browse normally to yahoo.com. Where the attack is performed is the request from nameserverA to the authoritative DNS server, when nameserverA sends a request to the root server, the root server sends back a "referral" which tells nameserverA where to go for the .com listings. Contained in this exchange of information is the TXID. It keeps going down the list to various DNS servers, ultimately to the authoritative DNS server.
Our guess at where the attack occurs is the response back from the root server to respond on where yahoo.com's server resides. If an attacker can spoof a valid TXID and say yahoo.com's nameserver is really at ns.badhacker.com and not ns.yahoo.com and ultimately resolves to 1.1.1.1 instead of 2.2.2.2, we can perform cache poisoning of that name server.
So initial speculations that this is bad is pretty accurate and why all the hush was kept to allow all vendors to patch the systems accordingly. Kudos goes out to Dan Kaminsky for taking all of the scrutiny over all of this and allowing vendors time to patch the systems to something that was in fact not just hype but could have major implications if exploited successfully.
I hope all of your DNS servers are patched, a POC should be pretty easy to write off of this.
Special thanks to Microsoft for releasing details about the patch and letting us know what the vulnerability was:
http://blogs.technet.com/swi/archive/2008/04/09/ms08-020-how-predictable-is-the-dns-transaction-id.aspx
Special thanks to John Melvin from SecureState for helping me out on this.
Again this is purely hypothetical, this hasn't been confirmed nor denied.
UPDATE: Update to this post, it appears that it has been confirmed and found by Halvar Flake blog. In addition matasano also discovered it but the site was put up temporarily and taken down when discovered, a mirrored site can be found at: http://beezari.livejournal.com/141796.html. Patch your servers folks!
PATCH: What the patch appears to do, pretty cut and dry, it makes the TXID truly random and randomizes the DNS ports pretty much making this attack useless.
Read more!
PCI Compliance: Close but no cigar.
PCI Compliance is on almost everyone's mind and it will continue to grow in popularity as time progresses. Before I start, this is by no means a rant or flaming of the PCI DSS 1.1 standard, in fact, to date the PCI DSS is the most technical security framework really out there to date. There are a lot of positives toward the standard; however it has many shortcomings. I'm not going to list every one, but focus on some of the most pressing issues that we've seen as penetration testers and where the standard really is failing.
First, let’s start with: the standard should never be fully relied upon for organizations overall security posture. A matured security organization typically pulls from many standards like the ISO 27001/27002, NSA IAM, NIST, PCI, etc. One thing that this standard has really pulled through was a start to security in organizations and a start for security to be taken seriously. Generally, banks were the forefront for protecting data due to the sensitive nature of information, and most other organizations security fell in the wind and has since begun to shift in a different direction.
As a penetration tester, and running a team of gifted hackers, we get to see every environment and configuration known to man. Due to PCI's 11.3 "Performing penetration testing at least one a year", we do a variety of penetration testing assessments against PCI Compliant organizations. One of the most alarming statistics is our 63 percent success rate for breaching systems in PCI Compliant organizations. By breaching systems, we're talking about full access to the underlying operating system and potential to further penetrate into the network. The 63 percent doesn't even include access to the back-end databases, login bypasses, and various other issues we find during a pentest.
PCI's 1.1 states in 6.5 to use the OWASP guidelines for securing their systems. PCI 1.1 uses the OWASP 2004 framework for vulnerabilities, which is missing the good ol' malicious file execution amongst others. In addition to this, the ASV scans that need to be performed only check for XSS and SQL Injection. Vulnerability scanners, in general, are pretty rudimentary and basic in vulnerability identification, but only detecting two of the overall top ten is a major issue. In 6.6 a code review or WAF has to be in place, which should hopefully stop SOME of these attacks, but the alarming issue here is we've done successful penetration tests against sites that have undergone a code review, or have a WAF in place and do minor protection against attacks.
WAF are great (if properly configured), don't get me wrong, but they should not be the only layer of defense. Creating a security systems development life-cycle (SSDLC) from the beginning of development and through development and establishing code freezes for security testing before going into production is vital and the preferred method. Web applications have been getting a bum rap and are the major points of entry for external breaches to date. The standard simply states "Installing an application-layer firewall in front of web-facing applications", it does not state anything about allowing exceptions for functionality of the site (and introducing exposures) or hardening techniques. Again, the purpose of the standard was not to secure your systems for you, but at least give you a framework for organizations to implement security.
My next question on the DSS standard is who performs the code reviews looking for these common vulnerabilities? Most VARs have a penetration testing wing, generally consisting of two people that implement product and do penetration testing as a side job (oh and hey, if you buy this product it'll fix your vulnerabilities). These guys generally use tools that don't even touch the web application layer in depth and give false satisfactions and assurance to organizations. There’s no certification process for web applications assessors, it only states "an organization that specializes in application security", if I have Nessus does that make me a specialist in web application security? If I have AppScan, WebInspect, Ounce, Fortify, or any of the others in there, does running a tool make me a specialist?
My last main issue covers the ASV guidelines, quoted directly from the ASV scanning standard:
"Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible. "
We've run into many scenarios where organizations are using this loophole to take systems out of scope for the PCI assessment. While the organization is "responsible" if it becomes compromised, generally the companies we're seeing this as a way to pass the test without ever having any of the security restrictions on the system in place. So as per this statement, a main e-commerce site handling all credit card transactions for the organization can be taken out of scope by the merchant or service provider if they choose. At this point, what is the point in becoming compliant at all? Why study hard for a “C” when you can get an “A” every time without ever studying? “Sure if you get caught cheating its bad, but what’s the payoff, we're never going to get breached!”
To finalize the point I was trying to get out here is organizations are really using this to become "secure", when that really isn't the impact intended. In order for organizations to incorporate security, it has to be a widespread adoption within the organization, pull multiple frameworks and standards, and incorporate them into a regularly tested and updated programs. Relying solely on of PCI compliance and going through the checklist is not going to protect you from a breach by any means.
Read more!
First, let’s start with: the standard should never be fully relied upon for organizations overall security posture. A matured security organization typically pulls from many standards like the ISO 27001/27002, NSA IAM, NIST, PCI, etc. One thing that this standard has really pulled through was a start to security in organizations and a start for security to be taken seriously. Generally, banks were the forefront for protecting data due to the sensitive nature of information, and most other organizations security fell in the wind and has since begun to shift in a different direction.
As a penetration tester, and running a team of gifted hackers, we get to see every environment and configuration known to man. Due to PCI's 11.3 "Performing penetration testing at least one a year", we do a variety of penetration testing assessments against PCI Compliant organizations. One of the most alarming statistics is our 63 percent success rate for breaching systems in PCI Compliant organizations. By breaching systems, we're talking about full access to the underlying operating system and potential to further penetrate into the network. The 63 percent doesn't even include access to the back-end databases, login bypasses, and various other issues we find during a pentest.
PCI's 1.1 states in 6.5 to use the OWASP guidelines for securing their systems. PCI 1.1 uses the OWASP 2004 framework for vulnerabilities, which is missing the good ol' malicious file execution amongst others. In addition to this, the ASV scans that need to be performed only check for XSS and SQL Injection. Vulnerability scanners, in general, are pretty rudimentary and basic in vulnerability identification, but only detecting two of the overall top ten is a major issue. In 6.6 a code review or WAF has to be in place, which should hopefully stop SOME of these attacks, but the alarming issue here is we've done successful penetration tests against sites that have undergone a code review, or have a WAF in place and do minor protection against attacks.
WAF are great (if properly configured), don't get me wrong, but they should not be the only layer of defense. Creating a security systems development life-cycle (SSDLC) from the beginning of development and through development and establishing code freezes for security testing before going into production is vital and the preferred method. Web applications have been getting a bum rap and are the major points of entry for external breaches to date. The standard simply states "Installing an application-layer firewall in front of web-facing applications", it does not state anything about allowing exceptions for functionality of the site (and introducing exposures) or hardening techniques. Again, the purpose of the standard was not to secure your systems for you, but at least give you a framework for organizations to implement security.
My next question on the DSS standard is who performs the code reviews looking for these common vulnerabilities? Most VARs have a penetration testing wing, generally consisting of two people that implement product and do penetration testing as a side job (oh and hey, if you buy this product it'll fix your vulnerabilities). These guys generally use tools that don't even touch the web application layer in depth and give false satisfactions and assurance to organizations. There’s no certification process for web applications assessors, it only states "an organization that specializes in application security", if I have Nessus does that make me a specialist in web application security? If I have AppScan, WebInspect, Ounce, Fortify, or any of the others in there, does running a tool make me a specialist?
My last main issue covers the ASV guidelines, quoted directly from the ASV scanning standard:
"Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible. "
We've run into many scenarios where organizations are using this loophole to take systems out of scope for the PCI assessment. While the organization is "responsible" if it becomes compromised, generally the companies we're seeing this as a way to pass the test without ever having any of the security restrictions on the system in place. So as per this statement, a main e-commerce site handling all credit card transactions for the organization can be taken out of scope by the merchant or service provider if they choose. At this point, what is the point in becoming compliant at all? Why study hard for a “C” when you can get an “A” every time without ever studying? “Sure if you get caught cheating its bad, but what’s the payoff, we're never going to get breached!”
To finalize the point I was trying to get out here is organizations are really using this to become "secure", when that really isn't the impact intended. In order for organizations to incorporate security, it has to be a widespread adoption within the organization, pull multiple frameworks and standards, and incorporate them into a regularly tested and updated programs. Relying solely on of PCI compliance and going through the checklist is not going to protect you from a breach by any means.
Read more!
The Lame Man's Perspective
The Lame Man delves into the security breaches/stories for the past week and reveals the Good (attempt to find the good), Bad and oh so Ugly.
Good… Security breaches aren’t good… people lose their information, have the threat of identity theft, lose money and the all the other things that come along. But this story out of DC gets the pat on the back for the week. According to the Washington Post, the Social Security numbers of almost 4700 current and former Metro employees were posted on the agency’s website last month. It was a mistake made when the transit authority was soliciting possible workers’ comp. and risk management vendors. The good part of the breach comes here… Metro suspended the three workers responsible for the incident for one month without pay. It’s always good to hear that someone is being punished for their lack of common sense.
Bad… LPL Financial. The Boston-based broker-dealer reported that they began to take several steps to increase their data protection. This, after being breached for the second time in less than one year! The article, written in Investment News , says that the steps LPL is taking (since its first breach last July) to “beef up” its security includes: increasing the profile of data security within the company at all level, hiring a chief security/privacy officer and implementing a new information privacy and security program. Something tells me this plan isn’t working…
And the Ugly for this week comes from Washington and the Washington Education Association’s website which was brought down by Turkish hackers. Now, according to seattlepi.com, the attack brought down several local teachers’ union affiliates. It goes on to say that the attack did not compromise any personal data… but the reason why this goes on as the ugly story for the week is that the association is still having problems, one month later! Oh and they still proudly display Hackers 1, WEA 0.
Read more!
Good… Security breaches aren’t good… people lose their information, have the threat of identity theft, lose money and the all the other things that come along. But this story out of DC gets the pat on the back for the week. According to the Washington Post, the Social Security numbers of almost 4700 current and former Metro employees were posted on the agency’s website last month. It was a mistake made when the transit authority was soliciting possible workers’ comp. and risk management vendors. The good part of the breach comes here… Metro suspended the three workers responsible for the incident for one month without pay. It’s always good to hear that someone is being punished for their lack of common sense.
Bad… LPL Financial. The Boston-based broker-dealer reported that they began to take several steps to increase their data protection. This, after being breached for the second time in less than one year! The article, written in Investment News , says that the steps LPL is taking (since its first breach last July) to “beef up” its security includes: increasing the profile of data security within the company at all level, hiring a chief security/privacy officer and implementing a new information privacy and security program. Something tells me this plan isn’t working…
And the Ugly for this week comes from Washington and the Washington Education Association’s website which was brought down by Turkish hackers. Now, according to seattlepi.com, the attack brought down several local teachers’ union affiliates. It goes on to say that the attack did not compromise any personal data… but the reason why this goes on as the ugly story for the week is that the association is still having problems, one month later! Oh and they still proudly display Hackers 1, WEA 0.
Read more!
Subscribe to:
Posts (Atom)
Posts
