One Thing To Do Today: Threat Model 5, How to look for mitigations
We had a great conversation with Santa, but it won’t help us at all if we don’t look for ways to thwart him. Real mitigation plans (PDF) by real experts take quite some time. I’m going to sum up the process starting by recapping the vulnerabilities and attack vectors he mentioned specifically to make sure our brainstormed solutions actually address them. Next I’ll make a table to help prompt ideas for possible solutions. That will be enough for today, but future posts will have filled out the tables for the different vulnerabilities. Still after that comes ranking the choices to an action plan. Whew.
What vulnerabilities did Santa find?
- Data frequently given away by targets via
- All social media updates, geotagged or not
- Images, EXIF data
- Images, tagged by hand, via facial recognition or place based reverse image searches.
- Mobile App collection and handling of location data
- Unencrypted data easily available to many people in the company
- Encrypted data, the keys live at the company. How many people in the company can get the keys?
- Apps taking data they were not invited to take, for example, apps getting that location data from visible WiFi networks.
- Possibility that any of this information is being transmitted without encryption?
- Connectivity logs from Telecomm companies and ISPs
- Same as app company concerns
- Cell phone triangulation more precise than IP
- Also spoofed cell towers or other man in the middle better for a situation where the goal is to learn about who’s in a location, not the possible locations of a who.
- Minor: Usage data from IoT items of know location
- Same vulnerabilities as all other logs.
- Item could be planted in a location the target might show up at, but like a spoofed cell tower, better to confirm target presence at a known location not to figure out what locations are relevant in the first place.
What vectors did santa discuss?
Santa has a lot of confidence in his social engineering skills. Most of his exploits involve getting someone to willingly help rather than crack a password or trying a man in the middle attack. Santa specifically mentioned that he likes to call, and you can listen to examples of which are available on YouTube. Companies need to have well designed permission structures and data access procedures in place since humans have their “only human” thing going on. This is incredibly hard to verify as a consumer.
Santa also mentioned that he could go direct to consumer with his own game app designed to seduce. If it actually was fun, it wouldn’t be quite the same as counterfeit app. I’m pretty sure I’d be helpless against it.
One rather suspicious omission, Santa, despite his B&E skills, didn’t mention his ability to just walk into houses while people are sleeping and suck down data from the devices themselves. Given his ability to hit millions if not billions of houses in one night, that’s kind of a weird vector not to try. My alarm bells have gone off.
Also not raised by santa, facial recognition by surveillance cameras. I’m not sure how else he’s pulling off the “He sees you when your sleeping” bit. I might troll him a bit by adding some Nasim Sehat eyeware to my wishlist.
- Upstream Social Engineering, specifically “vishing”
- Mobile app with deceptive practices
- (Accessing devices)
- (Visual surveillance data)
Ways to mitigate
So the great chasm of vulnerabilities has opened. Everyone has their own way to handle staring chaos in the eyes. Mine is to make tables.
Across the top of the table I’ve put the layers of technology the average consumer deals with, from easiest to control to the least. Sort of. Putting people first might be a mistake. Bad habits get forged from adamantium, I know.
Down the left are types are classes of mitigations, as I understand them.
| People | Installed software | OS, Firmware, Utilities |
Hardware | Networks | External Accounts | |
| Reduce attack surface | ||||||
| Reduce procedural vulnerabilities | ||||||
| Reduce technological vulnerabilities | ||||||
| Block specific exploits | ||||||
| Lobby/Sue/Report |
Reduce attack surface: People build forts on cliffs, on peninsulas, inside moats to reduce the number of approaches enemies have to get to them. They’ve reduced their attack surface. Solutions that reduce the number of accounts, apps, devices, open ports shrink the attack surface that threat actors can exploit.
Reduce procedural vulnerabilities: The things that people do that make the system unsafe. An example of a procedural improvement? Let’s say there is a message for you from someone at your bank saying they have an urgent message. Right now your procedure might be to simply call that number back. Fixing that procedural vulnerability might mean replacing that one step process with a list of actions:
- search for the original number online
- look up their main customer service number
- call the main customer service number instead no matter what
- report the initial call to the FTC if the bank doesn’t confirm that they called
Procedural problems can have technical fixes as well. An IT department might block phone calls to and/or from known spammers. Individuals can install apps on their phones.
Reduce technical vulnerabilities: The simplest example? Software has bugs. Updates tend to remove bugs. You’ve removed a technical vulnerability. Sadly sometimes the technical vulnerabilities come baked into the architecture. For a consumer that may mean switching services, operating systems or hardware to options that take security and privacy more seriously.
Block Specific Exploits: Here we switch from strategic to tactical. Sometimes a vulnerability can’t be removed from the system immediately. Can’t have cell phones without cell towers for the time being. Sometimes a narrow tool (VPN) to address a narrow problem (unprotected data going through a spoofed tower, not the fact of the connection) provides the least bad choice.
Lobby/Sue: Sometimes there is already a legal protection against what’s happening. When a company has left you vulnerable by violating their published privacy policy they can be reported to the FTC, for example. These represent my least favorite mitigations, but they do exist.
Tomorrow I’ll pick a vulnerability and start filling the table out. Maybe give it a try on your own.
