Difference between revisions of "Protecting Your Organizational Identity Online"
m (1 revision imported) |
|||
Line 47: | Line 47: | ||
accountname@ domain. | accountname@ domain. | ||
− | |||
− | |||
- every forwarder goes to 2 people. primary | - every forwarder goes to 2 people. primary | ||
Latest revision as of 18:44, 6 September 2016
Facilitated by Allen Gunn, Aspiration
Session Description
As nonprofits move increasingly to "the cloud", with hosted applications and online services playing a central role in their program and operations, a new category of risk exposures has emerged. From proper domain registration to ownership and management of hosted data to control of social media accounts, many organizations fail to consider the long term when they set up online presences and increase their dependency on online tools. This session will provide practical steps organizations can take to take full control of their online identity and long-term destiny.
Session Notes
protecting your org identity online
processes need to be braindead simple to be
adopted nonprofits don't have a list of their accounts
first step: spreadsheet with acct name, url,
but not password
second step: good password protocol
primary asset is the data. most orgs think
only of software and hardware costs
have inventory of where your data lives and
how often it is backed up
recommendations for tracking all accounts
- spreadsheets - google - but hosting critical org data
there has privacy tradeoffs
contact info on accounts isn't systematic.
- recommendation. - orgs should use cpanel hosting as easy
way to manage systems easily thru graphical
interface
- create email alias/forwarder that is
accountname@ domain.
- every forwarder goes to 2 people. primary
account user and ops manager.
- redundancy. 1 of 2 people will be
available at any time
- forwarder allows rerouting of the emails
when people change roles/depart the org
- helps to track who is sharing your info
with spammers
contact info for an account can't be personal
email/address. worst practice
plesk
- a variant of cpanel
software registrations too. not just web
registrations
domain registration
- scumbag registrars. godaddy = super
rightwing + bad site design ++++ hostage taker
registrar (very difficult to move to new
registrar)
- registrar.com - bad - domain registry of america. flaming
scumbags!!!!
- network solutions. hostage takers.
CIA-affiliation.
- joker.com. recommended by bruce. can be a
reseller.
- domainsite.com/name.com =
gunner-recommended. excellent admin tools.
only tech support on weekdays.
when domains get taken
- if someone registers your brand, there's a
grievance process.
- but if the domain gets grabbed, you're
screwed.
best practice
- register com/net/org combo when possible. - your opponent will buy them - they'll use seo to drive people away from
your org, mislead people.
- don't rely on registrar to alert you about
renewal
- make sure contact info is updated and
consistent across your domains
- autorenew is good if you're comfortable
having credit card info in a hackable
database. paypal is an option
- multiyear renewal is good. - NEVER LET AN EXTERNAL PARTY REG DOMAINS FOR
YOU
- written down explicit org process for
domain reg
- who is empowered - how. step by step. - put all domains in one registrar you trust - unless you're controversial and need to
keep domain with non-US registrar (ghandi.net)
- california green party does this
cybersquatter solution
- have whitehat squatters make domains
available to causes for short-term campaigns
tangent: china rerouted 15% of web traffic for
20 minutes earlier in 2010 and saved all the
info. proof of concept.
web hosting
- never ever ever do web hosting with your
registrar. leads to hostage situation.
- if hosting is separate from registration,
you can solve the hosting hten move the
domain. much harder to divorce if everything
is in the same place.
- archive your cpanel settings. monthly.
domains, subdomains, email accounts,
forwarders.
- when you create a hosted account, see if
access to the acct can be through a subdomain
or directory of your domain name. ex. you
could pay wordpress to direct
aspirationtech.wordpress.com to
aspirationtech.org/blog - local backup copies of databases. amazon s3
account. rochen.com hosting
email
- never give out anything but @yourdomain,
even if you route it through another service
(gmail)
- good options. cpanel hosting account. don't
use imap. use pop and local mail clients for
orgs who want to make it more difficult for
the gov't to take hte data. use an open source
mail client (squirrelmail, etc.)
- electric embers.org. npogroups.org. open
source webmail service
- FORBID YOUR STAFF FROM DOING ORG
COMMUNICATION THROUGH PERSONAL EMAIL ADDRESSES
- branding. you look amateurish. - staff is building address book of org
contacts. staff is aggregating org knowledge
into gmail folders that are outside the org's
control. if there's an ideological schism,
angry staff member quits and spam entire
address book with grievances.
- also think about volunteers/contractors
who do any external communications. set up an
org address for them.
- NO NON-WORK COMMUNICATIONS WITH ORG EMAIL
ADDRESS
- hard to monitor but train employees on the
policy and why we have it
- policy: the aggregate email info stays on
org hardware. pull data only onto org
machines.
one solution: install your own email client
(like open source Zimbra). daily snapshots of
data. can recover deleted emails.
version control and open source software
- your website is dependent on compatibility
with the version of software (wordpress) it is
running on.
- code escrow. recommended contractual item
with developers. code is staged out to the
escrow location every X days. protects against
schisms btw you and developer. run svn server
on local server (most orgs don't have
expertise/resources for this).
control of online real estate
- facebook/twitter. get on them and lock down
the userid/facebook url for your org. same
username on as your domain name if possible.
same for any other significant online outposts
- log in every 90 days to keep the acct - get a page for your org on wikipedia and
make sure it says what you want it to say. get
the rss feed and monitor
- have an org tag and monitor it on
deliciious, flickr, twitter.
- SEO. know what keywords you care about even
if you're not optimizing. google for them
occasionally to make sure your opponents
haven't optimized for them better.
- social media listening. netvibes is a good
service. no good open source solution yet.
"for a corporation, they're not that bad."
backups
- do them. do them more often. - all org data on all hard drives. - back up offsite. protects against disaster
or data grab.
- backups behind a locked door.. - partner with other org to back up each
other. both behind locked door. complying with
each others' privacy policy.
- ED or trusted employee taking backups home
isn't a bad option. Sending a physical copy of
your data thru Fedex to offsite location (like
board chair).
- all backups need to be encrypted. - recommended encrypted services - recommend services that accept
responsibility for data (s3) vs. services that
disclaim liability (dropbox, etc.)
SSL
- for collecting donations. protecting donor
info. make sure your have an SSL certificate.
- encrypting entire website (https) can be a
good idea, protect against sniffing/injection
- there are good tutorials (EFF white paper
on https and links to resources being released
soon. https anywhere firefox plugin.
aspiration paper: protecting your identity
online.
best practices: see if vendor's align with
nonprofit values - different from having a
nonprofit pricing plan.
key takeaway: open source hosting hires child
meth addicts as sysadmins
1. have organizational standards for website
logins and domain registrations. clear
separation of personal and organizational
communications
2. separate hosting and registration.
3. grab org usernames and urls on significant
social media sites and monitor how your org
name is being used.