Really great guide. I love the community focus — so many of these security guides are individually-oriented, which limits their applicability to groups, especially volunteer groups.

A pretty good checklist. Some things are tailored for the relatively-higher risk faced by journalists, but with some judicious “not applicable” application could be a good checklist for anyone.

Round up of research and commentary on phishing sims

Detection Engineering is a concept that has emerged in the detection space. It acknowledges the complexity of a detection stack and the…

Interesting framework for thinking about risk mitigation. Designed for workplace protection, but could be applied to lots of different risk scenarios. Compare with Magoo’s Five Factors, there are some similarities here.

Actual study is here: https://arxiv.org/pdf/2112.07498.pdf

Here’s how to safely store and use credentials for the Python gspread library, a Python API for Google Sheets.

Background: How To Keep A Secret, by Glyph The most relevant parts start around 15:00, but watch the whole thing, it’s great and worth your time.

Pre-requisites

Install keyring: pip install keyring or equivalent.

Storing credentials

Create service account credentials as explained in the gspread docs. This ends with you having a JSON credentials file on your disk somewhere (unacceptable).

This is the definitive “why you shuoldn’t use a VPN” article that I link every time the topic comes up.

Unfortunately, it appears Bitwarden may have coppied some of the pretty unfortunate design decisions from LastPass. I might have to revise my recommendation.

Fucking excellent analysis of both the technical, legal, and policy failures at play here. Required reading.

I’m trying out Tiller (a service that pulls financial transaction data into Google Sheets), and there’s a nifty bit of security design.

• Instead of its own authentication, you login via Google. This means Tiller doesn’t need to do any account management, and my account’s as secure as my Google account.
• Like all other services in this sector (Mint, Personal Capital, YNAB, etc), the actual data sync happens via Yodlee. Yodlee is… not great, but it’s at least not worse than what everyone else is doing. And, Tiller does the best they can by using Yodlee’s own credential flow, which means your bank login never hits Tiller’s servers.
• When you set up a sheet, instead of requesting access to Google Sheets, Tiller creates the sheet using a bot account, then shares it with you. This means Tiller only has access to the specific spreadsheets it manages, not your entire drive.

There’s always a bit of inherent risk in services like this, and I’m pleased to see that someone at Tiller clearly thought very carefully about the risk model, and designed things to be about as safe as it could be.

I’m not a fan of including social engineering – spearphishing, calls to support tickets, office visits – as part of penetration tests. These activities are risky, and often involve borderline and outright inappropriate behavior. Further, they tend not to produce useful results.

I encourage you to explicitly forbid social engineering attacks in your pentest scopes. Instead, try simulating the kinds of compromises that social engineering attacks lead to, with an emphasis on detection and response. This provides much more satisfying and useful outcomes, without the risks that allowing social engineering introduces.

There are a couple of metaphors that tend to guide my thinking about the practice of security: ratchets and levers.

Ratchets

A ratchet is a kind of one-way gear, with angled teeth and a pawl that allows motion in one direction only. In the physical world we use ratchets to help lift or move heavy loads. Using a ratchet, we can overcome the massive inertia of a heavy object by breaking the movement down into small, easy, irreversible steps.

The 2016 edition of Verizon’s Data Breach Investigations Report is out, and as usual it’s compelling reading. The DBIR is one of the only sources of hard data about information security, which makes it a must-read for anyone trying to run a security program in a data-driven manner.

What follows are the bits that I found especially interesting, and a bit of my own commentary.

I’ve joined Heroku as their Director of Security.

An input form that takes raw HTML. It’s a pretty common thing to see in web apps these days: many comment forms allow HTML, or some subset thereof; many social-network-style applications allow end-users to enter HTML in their profiles; etc. Unfortunately, allowing untrusted users to enter raw HTML is incredibly dangerous; read up on XSS if you don’t know why.

So a common question that comes up in web developer circles deals with how best to “escape” user-entered HTML so that is safe for presentation. Though this seems easy, it’s actually incredibly difficult – see Whitelist, Don’t Blacklist for an introduction. I’ve literally seen hundreds of recipes for stripping unsafe HTML that are about as effective as a screen door on a submarine.