Tag Archives: encryption

Is It Time To Worry About Cybercrime?

This article was originally posted on the Idealware Blog in September of 2011.

For the past decade, the bulk of unlawful web-based activities have been profit-motivated: phishing, spam, “Nigerian” money scams, and hacking to get credit cards. This year has seen a rise in politically motivated crimes, most widely exemplified by the loosely-knit group of hackers known as “Anonymous“.  Anonymous hackers attack the websites of organizations, be they government, corporate or otherwise that they deem to be repressive or unethical.  In addition to defacing the sites, they’ve also routinely exposed confidential user information, such as login names, passwords and addresses.  If we are now entering the age where political cybercrime is commonplace, what does that mean for nonprofits?  How can we defend oursleves when we already struggle with basic security on tight budgets and limited resources?

Two high profile victims were Sony, the gigantic electronics and entertainment conglomerate, and BART, the Bay Area Rapid Transit commuter service.

  • Sony was initially a target for Anonymous after they took legal action against a computer geek named George Holtz, who figured out how to reprogram a Playstation game device in order to play blocked third-party games on it.  This violated the Sony license, but the hacking and gaming communities felt that the license restriction wasn’t very fair in the first place. They considered the action against Holtz unwarranted and severe.  Sony also, famously, installed a hacker’s rootkit, themselves, on a number of music CDs with interactive computer features, and were sued for that crime.,  Could it be that the hackers were particularly annoyed that this mega-corporation will stoop to their tactics, but sue them for similar actions?
  • BART was targeted for more visceral actions.  Their internal police force shot Oscar Grant, an unarmed youth, in the back a few years ago, and then, again, recently, fired on a homeless man holding a knife, killing him. These actions drew the attention of the community and resulted in protests, some violent.  But BART only drew the attention of Anonymous when they took the step of blocking cell phone service at their four downtown San Francisco stations in order to quell communication about a planned protest.  This action is under investigation by the FCC and has been decried by the ACLU; it was quite likely illegal. Then it was revealed that, at a press conference to discuss the protests, they seeded the audience with BART proponents coached in what to ask and say.

Anonymous hacked a dozen or more Sony Websites and three BART websites in protest/retaliation for what they consider to be corporate crime. Here’s how easy it was for them: one of the Sony servers containing hundreds of thousands of user account records was running on an old, unpatched version of Apache with no encryption. The initial attack was simply accomplished using a hack (SQL Injection) that is ridiculously easy to block (by updating to a current software version, in most cases). The Administrator password to get into the BART police site was “admin123”.  The “hacker” who broke into that site reported that she’d never hacked a web site in her life, she just did a bit of googling and got right in.

These were corporate web sites, run by companies that take in vast amounts of consumer dollars every day, and they couldn’t be bothered to do even the minimum amount of safeguarding of their customer’s data.  They might not be the criminals, but is it wild to suggest that they were criminally negligent? This isn’t a matter of them not having the money, resources or available expertise to protect our data.  It was a matter of them not taking the responsibility to protect it.

What can nonprofit organizations, that aren’t obsessed with bottom lines, do to avoid the problems that BART and Sony have faced?

  • First and foremost, we need to protect constituent data.  If your NPO doesn’t have the weherewithal to do that internally, than your online data should be hosted with companies that have strong commitments to security and privacy of customer data.
  • Second, should breaches occur (and they do), your primary goal should be timely, open communication with the victims of the data breach.  We’re getting past the point where our constituents are naive about all of this (Sony has done a great job of prepping them for us).  So your first response to exposed constituent data should be to tell the constituents exacty what was exposed.
  • One uncomfortable situation like this won’t kill your credibility, but a history of bad or callous relationships will amplify it.  This is one of the reasons why good social media policies are critical — the people who can support or sink you when something like a data breach occurs are on Twitter and Facebook, and they’ll feed the media stream with support or slander, depending on how well you relate to them.
  • We promote causes online, but we admit faults there, too.  We don’t engage customers by lying to them, hiding things that impact them, or dictating the terms of our relationships with them.
  • Our supporters are people, and they have their motivations for supporting us (or not) and their ideas about how they should be doing it.  Their motivations and reasoning might be quite different from what we assume. Accordingly, we should be basing our assumptions — and campaigns — on the best feedback that we can coax out of them.  Long-held industry assumptions are suspect simply because they’re long-held, in a world where technology, and how we interact with it, is constantly changing.

 

If we ever needed reverse primers in how to manage constituent relationships, the Sony and BART fiascos are prime ones.  They are victims of illegal and unethical behaviour.  But by viewing their customers and constituents as threats, with callous regard for the people who keep them in business in the first place, they’ve created a public relationship that did nothing to stem the attacks. Sony has put far more money and effort into attacking and dehumanizing their customers with lawsuits and invasive, annoying copyright protection schemes than they have in listening, or trying to understand the needs and desires of their constituents.  BART has tried to block their ears so tightly to shut out public criticism of their violent, shoot first police force that they’ve crossed constitutional lines of conduct. We — nonprofits — know better. It’s a two way relationship, not a dictatorial relationship with our supporters, that will serve as our most effective firewall.

Complying with Data Security Regulation

This post was originally published on the Idealware Blog in November of 2008.
An article appeared in the NonProfit Times this week regarding a recent ruling in Nevada requiring that all personal information be securely transmitted, e.g. encrypted. The article, States Push To Encrypt Personal Data is by Michelle Donahue, and quotes, among others, me and our friend Holly Ross, Executive Director of NTEN — it’s a worthwhile read. The law in question is a part of Nevada’s Miscellaneous Trade Regulations and Prohibited Acts. I’ve quoted the relative pieces of this legislation below, but I’ll sum it up here:

Personal information can not be transferred to you by your customers (donors) without encryption. Personal information is defined as any transmittal of someone’s name along with their credit card number, driver’s license, or other data that could be used to access their financial records.

Nevada is the first state to pass legislation like this, but it’s a good bet that they are the first of fifty. Massachusetts is right behind them. And if the government won’t get you, the credit card industry might. The regulations that they impose on larger retailers for credit card security are even tougher. These initially applied to retailers bringing in far more money via credit card than most of us do, but they have lowered the financial threshold each year, bringing smaller and smaller organizations under that regulatory umbrella.

So, the question is, how many of you receive donations via email? If you do accept donations over the web, are you certain that they’re encrypted from the time of input until they land inside your (secured) network? What do you do with them when you receive them? Do you email credit card numbers within the office? Retain them in a database, spreadsheet or document?

Most nonprofits are understaffed and unautomated. We accept donations in any manner that the donors choose to send them, and get them into our records-keeping systems in a myriad of fashions. The bad news here is that this will have to change. The good news is, if you do it right, you should be able to adopt new practices that streamline the maintenance of your donor data and reduce the workload. Even better, if the solution is to move from Excel or Word to Salesforce or Etapestry, then you’ll not only have a better records-keeping system, you’ll also have good analytical tools for working with your donors.

Automating systems, refining business processes, improving data management and maintenance — these are all of the things that we know are important to do someday. It looks like the urgency is rising. So don’t treat this threat as an impediment to your operations — treat it like an opportunity to justify some necessary improvements in your organization.

The relevent snippet from the Nevada law:

” 1. A business in this State shall not transfer any personal information of a customer through an electronic transmission other than a facsimile to a person outside of the secure system of the business unless the business uses encryption to ensure the security of electronic transmission.

2. As used in this section:

(a) “Encryption” has the meaning ascribed to it in NRS 205.4742.

(b) “Personal information” has the meaning ascribed to it in NRS 603A.040.

“Personal Information” is defined as:

“Personal information” means a natural person’s first name or first initial and last name in combination with any one or more of the following data elements, when the name and data elements are not encrypted:

1. Social security number.

2. Driver’s license number or identification card number.

3. Account number, credit card number or debit card number, in combination with any required security code, access code or password that would permit access to the person’s financial account.

The term does not include the last four digits of a social security number or publicly available information that is lawfully made available to the general public.