Friday, November 20, 2009

Model Privacy Policy issued by the Feds

The FTC and seven other Federal agencies released their model privacy policy based on interviews with consumers and feedback from all of the agencies involved. Any organizations that fall under the regulatory auspices of one of those agencies, or has GLBA requirements would be well advised to take this “requirement” into consideration before it comes up in an action against the organization and you are facing an auditor asking you why you did not take this into consideration. See intro from the press release and a link to the entire release as well as the template.

From the FTC
Eight federal regulatory agencies today released a final model privacy notice form that will make it easier for consumers to understand how financial institutions collect and share information about consumers. Under the Gramm-Leach-Bliley Act (GLB Act), institutions must notify consumers of their information-sharing practices and inform consumers of their right to opt out of certain sharing practices. The model form issued today can be used by financial institutions to comply with these requirements.
Read more

Thursday, November 5, 2009

What if the e-mail says s-i-p-c?

There is a bill pending as part of the Investor Protection Act (section 508) that would require ISP’s to block content where scammers are posing as SIPC Members. Ask anyone that has tried to block scam e-mails or web sites, and they will tell you long sad stories about the impracticality of this exercise. And here is a news flash for the House – the e-mails and web sites you are attempting to block here, do not always clearly state SIPC member, or “we are a fraudulent site". They can use any number of tricks to hide the content from scanning including images that aren’t named “SIPC fraudulent logo.bmp” and HTTPS connections. Judges have already thrown out prior requirements of this type looking for porn. What’s next – using a BBB seal without rights? Wouldn’t it be better to solve the broader problem of consumer protection instead of looking at one type of fraud? The last I checked, check fraud was still the most prevalent fraud in America.

Story follows from cnet
http://news.cnet.com/8301-13578_3-10390779-38.html

Tuesday, November 3, 2009

Comcast's Constant Guard

Comcast is set to debut its “Constant Guard” program that will alert users if they suspect their machine is infected with malware. Apparently they are already doing this via telephone, and want to automate the process through browser notifications. As someone who used to manage IPS, I cannot imagine trying to do this on this scale, but I applaud them for trying this anyways. There are however two big issues with this – not to mention the nine others.

1. Privacy – exactly what are they watching here, and what are they sending in the way of interceptions
2. They are copying what the malware distributors are doing right now with fake A/V solutions that are actually malware, and it is going to be impossible for novice computer users, who apparently got infected in the first place to know the difference between Comcast and Malware.

Story below

http://ca.news.finance.yahoo.com/s/08102009/34/biz-f-business-wire-comcast-unveils-comprehensive-constant-guard-internet-security-program.html

Thursday, June 18, 2009

Pending Canadian legislation proposes new snooping capabilities for authorities

Interesting story reported by Canwest News Service out of Canada

OTTAWA — Police will be given new powers to eavesdrop on Internet-based communications as part of a contentious government bill, to be announced Thursday, which Public Safety Minister Peter Van Loan has said is needed to modernize surveillance laws crafted during "the era of the rotary phone."
Original Story by Canwest News Service

Monday, May 11, 2009

Star Wars and Information Security

One of our family traditions that I thoroughly enjoy is family movie nights. Every Sunday we gather in the theater to watch a family movie. It reminds me of Sunday nights when I was a kid, and Disney would show the Sunday night movie on ABC. It marked the end of the weekend, and the dreaded school week ahead loomed just over the horizon. The kids have gotten interested in Star Wars thanks to new cartoons that are being released, so this Sunday we decided to watch the original Star Wars. It has been a long time since I have seen the movie, but there is a great lesson for all organizations in the movie in regards to their risk management and information security programs. At this point, you are probably wondering if my misspent youth has clouded my judgment here, or perhaps I am one of those people who have a life size Darth Vader in their house and know all of the Star Wars trivia. I assure you that neither of these are in play here, so hang on a minute while I clarify. For the purposes of my illustration here, the Death Star and the baddies on it are a large organization with aspirations of intergalactic domination, not unlike (insert large organization from your “I hate them” list here).

At one point in the movie there is a meeting with the Generals, leaders, and Darth Vader where one of the individuals (I’ll call him the CSO) comments that the death star has several vulnerabilities and not to get too cocky (I’m paraphrasing here). The others dismiss his notions as nonsense, and Darth Vader proceeds to choke him without actually touching him. This would equate to the CEO or Executive Board shooting down your most recent proposal. As if the physical breach of the Death Star’s security by a newbie, a freighter pilot, a Princess, a Wookie, and two robots was not enough of a wakeup call, the Rebels eventually figure out that there is indeed a vulnerability in the Death Star that can be exploited by a single X-Fighter. We will equate this to a web vulnerability in one of your front-end applications that when exploited gives someone complete control over the back end system that holds credit cards. As this attack is underway the same person advises one of the Generals that perhaps it is time to get his escape pod ready (DR plan) and is again dismissed because hey what could possibly go wrong when we have enough money to build a ship the size of a planet.

In the end of course the vulnerability is exploited and the entire thing gets blown to bits. I found myself hoping that the CSO got out of there somehow since he was the only one who knew the BCP plan by memory, and is now living a peaceful life on some planet.
Anyone who has ever read any of my blogs (thanks Sis) knows that at this point, I will try and tie this to some nugget of Information Security gold, and they are right. No matter how much money you spend on Information Security in an organization, there is probably some vulnerability in something you coded or bought that can wreak havoc on your organization. The trick is to catch as many of these as you can without driving your company into bankruptcy, or the CSO into an early grave doing so. Additionally, when things do go terribly wrong you had better have a BCP/DR plan that everyone knows how to execute.

Wednesday, March 18, 2009

Changes coming for Healthcare Privacy

On February 17, 2009, President Obama signed into law the American Recovery and Reinvestment Act of 2009 (“ARRA”). Title XIII of ARRA, the Health Information Technology for Economic and Clinical Health Act (“HITECH Act) and specifically Subtitle D calls for new regulations and requirements to protect the privacy of health-related information that previously fell under HIPAA.

Under the HITECH Act, entities will be required to notify individuals as to a breach of their personal health information (PHI) unless it is encrypted. The breach notification must be made without unreasonable delay and within no more than 60 days following the detection of the breach. If the breach involves more than 500 individuals, then the Department of Health and Human Services (“HHS”) must also be notified as well as “prominent media outlets” in the applicable area. HHS will also be publishing the names and details of these reckless wrongdoers (my words not theirs) on their website.

This will effectively make this the first Federal data breach notification law in the country, and will be just one more item that needs to be added to the ever expanding data breach procedures at any organization that handles, owns or processes this type of information.
More information in the link
http://waysandmeans.house.gov/media/pdf/110/hit2.pdf

Wednesday, February 25, 2009

Information Security and Privacy class

Thanks so much for everyone who attended my class. I have published notes and links at the Class Notes link below. Please let me know if you have any questions, or need additional information.

Chris

Class Notes

Monday, February 23, 2009

Outsourcing Risk Management

You’ve heard it before “you can outsource the business process, but you can’t outsource the risk”. SaaS, cloud computing, BPO, or simply external hosting of an internally developed application can open up an organization to a much larger risk appetite than they might have if the data and solutions remained in-house. Of course if an organization’s policies, procedures, and standards are bad enough it could also reduce the risk. Either way, organizations must manage that risk to determine if there are significant changes that need to be addressed. COBiT, ISO 27K, PCI, and most other standards and many regulations call for the proper management and oversight of outsourced providers, so this should be no surprise to organizations or the companies that provide these type of services.

The first place to start is during contract negotiations with the external party. It should be clear what the organization expects, and what standards, policies, and procedures should be met. There should be penalties and consequences if these are not meant, and audit rights should always be present in any obligations. The FFIEC statement on this entitled Risk Management of Outsourced Technology Services.


The following is a good baseline of items that should be included.


  • Service Level Agreements for 10% of the yearly expenditures for each breach of the SLA.

  • The service provider and its agents are prohibited from using or disclosing the institution’s information, except as necessary to or consistent with providing the contracted services, and to protect against unauthorized use (e.g., disclosure of information to institution competitors).

  • All third-party or sub-contractors who will be storing or processing data must be approved.

  • Provider must disclose any known, suspected or future security issues or incidents

  • Any BITS FISAP, SAS 70 Type II, or other external third party audits

  • Qualified information security management must be in place in the organization

  • Regularly scheduled reviews of the third-party’s policies