Risks and Threat Models

From PlexodusWiki
Jump to: navigation, search

The world is a dangerous place.

Online systems allow you to do anything, anywhere, at any time. And the rest of the world as well.

The online world is an extremely dangerous place: the inverse of convenience is threat.

We're going to talk about risk, threat models, and risks in the context of online and social media.


Risk[edit]

Hazard; danger; peril; exposure to loss, injury, or destruction.

-- 1913 Webster

Risks involve probabilities and likelihoods. A risk is not certain to any one individual or moment, but as larger groups of individuals, or periods of time occur, do approach certainty, or at least regular occurrence. Risk can be considered a form of debt, in the sense that there will (probably) be a future obligation to pay for or suffer the consequences of it.


Threat models[edit]

A threat model gives you a tool for assessing a specific set of possible risks.

A threat model concerns:

  • Who am I, and what am I doing here?
  • Who or what might try to mess with me, and how?
  • How much can I stand to do about it?
  • Rinse and repeat.

From Sean Gallagher, "How I learned to stop worrying (mostly) and love my threat model", which is an excellent introduction to this topic.

From the Electronic Frontier Foundation:

  • What do you want to protect? (The data, communications, and other things that could cause problems for you if misused.)
  • Who do you want to protect it from? (The people, organizations, and criminal actors who might seek access to that stuff.)
  • How likely is it that you will need to protect it? (Your personal level of exposure to those threats.)
  • How bad are the consequences if you fail?
  • How much trouble are you willing to go through in order to try to prevent those? (The money, time and convenience you're willing to dispense with to protect those things.)


Risks and Online Services[edit]

These run the gamut, with a set of usual suspects being: data (deletion, exposure, breech, modification, access denial), hardware, financial, copyright, abuse, harassment, malware, vandalism, burnout, propaganda, disinformation / misinformation, technical debt, fascism / demagoguery, groupthink, surveillance, data harvesting, admin betrayal, admin sellout, etc.

These apply somewhat differently to users or consumers of, and hosts or administrators of, information services.

Information security is focused on the question "What could possibly go wrong?"

  • What is the likelihood of the event.
  • What are the consequences?
  • What mitigations can be taken?
  • What elements are inside and outside of your control?


Centralisation, decentralisation, and risk[edit]

There is no one answer here. Some risks are reduced by centralisation: a single, hardened target may be safer, easier to protect, and/or harder to attack, than many distributed targets. Some are reduced by decentralisation: multiple widely separated and independent targets are difficult to attack simultaneously. Which approach to use depends on the nature of the asset being protected, its operators, users, and defenders, and the attackers or risks. Some targets cannot be centralised: the elements of a distribution network (transportation, communications, electricity, water, gas, etc.) must traverse the area being serviced. Some targets resist decentralisation: a hydroelectric dam or nuclear power plant cannot easily be scaled to household size for local on-site generation, or it might only be suited to specific locations.

Risks can be broken down further:

A rented device[edit]

The worst choice of device to go online is a computer you don't own, e.g. one in an internet cafe. That is so much broken beyond repair that it's not worth fixing it. Simply don't do that.

Your own device[edit]

Your own device is likely the weakest point for a targeted attack, because you don't have the resources to protect it properly. The following is a list of common attacks:

  • Evil maid attack: Your unattended device is compromised. Remedies: Full disk encryption, door locks, always carry it with you. Devices that are easy to open and repair allow inspection (has someone added a physical keylogger?), devices that are hard to open and repair require special equipment, which gives the evil maid an advantage. Note that physical keyloggers may not stay long in your device, just long enough to get past the full disk encryption.
  • Phishing You are coerced into breaching your own security, with e-mails directing you to fake sites where you are coerced to enter your password or other credentials.
  • Drive-by download Your software is coerced into downloading malware without you realizing what's happening. Software needs to be hardened against this type of infection.
  • Zero-days in your software, bad maintenance by your software provider, reluctance to install security updates: Even on your own device, you depend a lot on big companies.
  • Choice of weak passwords. Remedies: use a password manager which stores your passwords on your devices only (syncing end-to-end encrypted between multiple of your own devices would be ok), and use strong per-site generated passwords to log into web services. The password manager should help you to generate strong passwords, the web service shall not reject passwords that are “too long” or contain “special characters”.
  • There are also hardware “solutions” to the password problem (USB tokens), which have their own implementation-specific share of problems.

This is only partly independent of what kind of social network you use, because phishing and drive-by downloads depend on technology commonly used by social web sites (e.g. sending you regular e-mails to get your attention and requiring insecure plugins like Flash/Java or JavaScript activated in your browser all the time). The services you use weakens your defense.

The communication between your device and the server[edit]

  • Passwords: Password authentication is the weakest point of secure communication with a centralized server.
  • TLS: Fortunately, after the Snowden leaks in 2013, TLS-based encryption has become de-facto standard when talking to social network servers. Earlier versions of SSL and TLS had their fair share of problems; the current TLS standard has one big problem left: The Certification Authorities mess.
  • A Certificate is used to provide a means against a Man-in-the-middle attack, and usually obtained by a procedure (domain validated certificate) that itself is susceptible to a MITM-attack. And you have to trust many certificate authorities, some of which are known bad (e.g. Symantec), and browser vendors are too reluctant to throw them out quickly.

The server farm[edit]

“Cloud” means it's not running on your computer and not stored on your device. You don't have control, someone else has. Data is frequently stored in plain text on the service, because either the technology mandates it (e.g. public for-all accessible data), or because the operator uses the data to monetize it (e.g. targeted adverts). Some services do have data which could be used to blackmail their users (e.g escapade dating sites, chat apps used for teen sexting).

While you should assume that big networks are operated by people who know what they do, have the resources to protect you, and can afford the audits for that, be aware that the people there are also humans, and that especially in bigger companies, the employees are on average mediocre. Therefore the same sort of breaches happen and happen again and again. Smaller servers as used in federated networks share the same set of problems, but don't have the same resources to protect them.

  • APIs: Many social networks offer APIs for apps to access data with your consent. That is ok, the threat model goes to the section above. But often enough, these APIs allow apps to access data without your consent. See Facebook/Cambridge Analytics, see Google+'s potential breach that lead to the sunsetting.
  • Passwords: password databases are a sort-of front door for all evil attackers, and they happen to everyone. Remedies: operators shall store passwords as salted hash with a relatively hard to compute hash function; e.g. bcrypt. Two-factor authentication can help further. Client public key authentication would help a lot, but isn't used; though (with client certificates) available already for decades. Operators of web services could issue their own certificates for their users, there is no need to have a CA as intermediate.
  • “Lawful” interception: Many countries have laws that permit authorities to secretly take out data of their customers. Some smaller providers may respond to such an order with a shutdown, larger providers are more likely to cooperate.
  • Whimful shutdowns: Any operator of a server or server farm can decide at any time to shut down their service; this is mutual: as user, you can terminate the use of their service at any time, too. If you pay for it, they may owe you something, but if you don't, they owe you nothing. Underfunded decentralized services may fall apart anytime just for lack of funding, big ones for lack of ROI.
  • Use of technology that weakens the client's security, such as Flash or Java plugins, or JavaScript always enabled.

Concepts[edit]

"People don't want backups. What people want is restores."

  • Disaster recovery
  • Backups
  • Restores
  • Replication
  • Hardening
  • Principle of least privilege
  • Principle of least astonishment
  • Process and procedure
  • Automation
  • Documentation



For Users[edit]

(starter list, incomplete)

  • what if my chosen platform / pod vanishes suddenly?
    • or didn't do proper backups and is now missing things
  • exposure of private data to others
    • technical issues
    • exploits
    • bad UI
    • software / feature update exposes what was previously thought to be private (looking at you, Google Buzz)
  • admins usually can see everything - who checks up on my admin?
  • social attacks (scam, spam, harassment, abuse), also: Can and should my social network handle those? How?

As expressed by Kathie "Kat" Gifford:

Some want to be able to access and export their content from anywhere on the web. Others, like me, need storage and don't want to incur fees later on. Some don't want to have to use their real name. Some are worried about sites selling their data.

Source: https://plus.google.com/112005455648666571245/posts/TFdpnMkXdXG (Internet Archive)

For Hosts and Administrators[edit]

TODO

Resources and references[edit]

TODO complete

Organisations[edit]

See also Privacy and Electronic Rights Organisations.

  • EFF: The Electronic Frontier Foundation (US)
    • Electronic Frontier Canada TODO: URL. Related to EFF-US?
    • Electronic Frontiers Australia TODO: URL. Related to EFF-US?
  • EPIC: Electronic Privacy Information Center (US)
  • C3: The Chaos Computer Club (EU)]
  • [European Digital Rights] TODO: URL
  • [Freedom of the Press Foundation] TODO:URL
  • [League for Programming Freedom] TODO:URL
  • OpenMedia.ca
  • [Open Rights Group] (UK) TODO: URL
  • [Reporters Without Borders] TODO: URL
  • ACLU: American Civil Liberties Union (US)
  • [Center for Democracy and Technology]
  • [Computer Professionals for Social Responsibility]
  • [Future of Privacy Forum]
  • [Global Network Initiative]
  • noyb.eu
  • [Privacy International]
  • [Privacy Rights Clearinghouse]

Mostly sourced from Wikipedia:Electronic_Frontier_Foundation. --Dredmorbius (talk) 09:54, 24 October 2018 (CEST)

TODO: Make something of above.

Books[edit]

  • Bruce Schneier, Applied Cryptography, Secrets and Lies, Liars and Outliers.
  • Simpson Garfinkel, Practical Unix and Internet Security
  • Charles Perrow, Normal Accidents, The Next Disaster

Articles[edit]

  • "Managing the Risks of Web Services", Elana Varon (CIO) 1 October 2003. "how three very different organizations—Motorola, the U.S. Navy and Wells Fargo—are addressing five major risks of Web services in their deployment strategies." Specifically addresses security, standards, and vendor business failure risks.

Discussions[edit]

  • On the risks of a federated option (13 October 2018) A sprited and informed exchange on the pros and cons of federated vs. centralised systems Rick Wayne, John Hattan, Nava Sharad, and others.

TODO