The only anti-phishing program I've ever seen that was even a little effective was at one company I worked at, where there was an ongoing phishing test.

Users were randomly selected to get the test, and each phish was hand-crafted to trick people specifically at our company (but using only publicly available information). Anonymized results were posted quarterly, divided by department.

I only got fooled once, but man, it felt so bad to see Engineering show up on the dashboard with one hit that quarter.

(Sales was usually at the top of the list, which makes sense, since they interface with a lot of folks outside the org)

These are exactly the kind of campaigns that studies show not to be effective (or even paradoxically ineffective). "Effective" doesn't mean "manages to successfully phish" (you'll always eventually be successful); it means reducing the likelihood that concerted attacks will be successful.

The actual response to phishing is to use authentication mechanisms that resist phishing.

Although, why limit it to publicly available information? Security is an onion. If somebody gets access to internal documentation, HR lists, etc, the organization should still be resistant to their phishes.

> If somebody gets access to internal documentation, HR lists, etc,

It's hard to be resistant to phishing at that point and you have bigger problems.

What if Susan in HR falls victim to token theft (let's say conditional access/MDM policies don't catch it or aren't configured, which many businesses don't bother with). Her email account is now pwned, and the company gets an email from her, it passes all verification checks because it's actually from her account.

It's still phishing, but the users have no way to know that. They don't know Susan just got compromised and the email they got from her isn't real. If this is a human attacker and not just bots, they can really target the attack based on the info in her inbox/past emails and anything else she has access to.

So there's no way for the organization to be resistant at that point until IT/security can see thea account compromise and stop it. Ideally, it's real-time and there's an SOC ready to respond. In practice, most companies don't invest that much into security, or they are too small and don't have the budget for a huge security operation like that.

It's a really hard problem to solve

HR shouldn’t be sending links anyway. They should send instructions: go to the portal (on your corporate controlled laptop, so this could be your new tab page) click on the paystubs link, blah blah.

Somebody in every big company is compromised already.

We got hit in a similar way. They didn't use HR's account to email but they grabbed the mobile phone numbers of everyone in the directory. They then started a text message campaign, pretending to be our CEO, demanding that employees go to Target and buy gift cards on behalf of a client.

One person actually did fall for it but decided to physically bring the cards to the CEOs office. Thankfully that exposed the attack and effectively halted any damage done.

These criminals are relatively clever.

i've noticed the gift card stands at Target and other stores around here now have a sign stating "If you received a text from your boss telling you to buy gift cards, you are being scammed" or similar

I’m assuming it’s the “easy” mode and they still have many successful phishing attempts, so it didn’t make sense to go to the next level if the company still fails in easy level.

> If we had universal healthcare in the USA, we'd have to have a common charting protocol and a medical chart exchange.

Isn't this exactly what HIPAA was supposed to address?

Elixir has this as well, IIRC.

That's because it moves from being a project to being a process. I've tried to express this at my current job.

They want to take time out to write a lot of unit tests, but they're not willing to change the process to allow/expect devs to add unit tests along with each feature they write.

I'll be surprised if all the tests are still passing two months after this project, since nobody runs them.

That’s why TDD (Test-Driven Development) has become a trend. I personally don’t like TDD’s philosophy of writing tests first, then the code (probably because I prefer to think of a solutions more linearly), but I do absolutely embrace the idea and practice of writing tests along side of the code, and having minimum coverage thresholds. If you build that into your pipeline from the very beginning, you can blame the “process” when there aren’t enough tests.

The flip that switched for me to make me practice something TDD-adjacent is to replace most manual verification with writing a test. Once I got in the habit I find it so much faster, more consistent, and then I have lasting tests to check in!

I don't typically write tests first so it's not true TDD but it's been a big personal process improvement and quality boost.

> to allow/expect devs to add unit tests

For me such gigs are a red flag and immediate turn down (I'm freelancer with enough opportunities, luxury position, I know).

I would consider it really weird if management dictates exactly what tools and steps a carpenter must take to repair a chair. Or when the owner of a hotel tells the chef what steps are allowed when preparing fish. We trust the carpenter or chef to know this best. To know best how to employ their skills given the context.

If management doesn't trust the experts they hire to make the right choice in how they work, what tools they use, what steps they take, etc. that's a red flag: either they are hiring the wrong people (and the micromanaging is an attempt to fix that) or they don't think the experts are expert enough to make decisions on their own.

For me, this goes for tools (e.g. management dictates I must work on their windows machine with their IDE and other software) for processes (management forbids tests, or requires certain rituals around merges etc) and for internals (management forbidding or requiring certain abstractions, design patterns etc)

To be clear: a team, through, or via a management, should have common values and structures and such. And it makes perfect sense for management to define the context (e.g. this is a proof of concept, no need for the rigid quality here. Or we must get these features out of the door before thursday, nothing else matters.) It's when the management dictates how teams or experts must achieve this that it becomes a red flag to me.

I haven't been wrong in this. These red-flags almost always turned out to hint at underlying, deeply rooted cultural problems that caused all the technical troubles.

> I'll be surprised if all the tests are still passing two months after this project, since nobody runs them.

Wouldn't they just run as part of the build? At least for Java, Junit tests run as part of the build by default.

I'd argue it's the main benefit.

> These are surprisingly often easy to answer

I agree that maintenance costs are often overlooked/ignored, but I'm curious how you get answers on the costs. I've never found it particularly easy to get reliable information on maintenance costs.

I guess what I was thinking was: even if you can't quantify it, you can squint at the comparative advantages and trade-offs and make a qualitative, yet objective judgement call.

Whatever became of the tweel?

Cynical, but probably the most humane take I’ve seen here so far.

There’s still some of that feeling in little pockets around the Internet. The tildeverse (https://tildeverse.org) might interest you; it’s a loose group of servers that offer free shell accounts for hosting simple web pages, chatting, programming, or playing around on a mostly unrestricted Linux box.

I run http://ctrl-c.club, one of the oldest tildes. We’re (mostly) closed to new signups, but if you’re interested, send me an email to admin@ctrl-c.club and we’ll get you in.

That’s… not a senior engineer. Whatever his title may have been.