Ex-Twitter exec blows the whistle, alleging reckless cybersecurity policies

Twitter's always hedged their bot stats with the MDAU caveat (e.g., "we're not estimating all the bots who log into Twitter, just the ones that are meaningful for advertising and revenue purposes"), so while these allegations are not at all helpful, they're not necessarily a serious blow to Twitter's position (Mudge is a hacker, not a contracts attorney, and a lot of the allegations he makes regarding regulatory law aren't necessarily supported by his evidence).

However, there's enough here, provided by a highly-credible technical expert, and under consideration by the US Congress, that Musk's litigation team has a strong opportunity to find at least something that holds up as a material misrepresentation, even if relatively minor, and then link it to the broader effect of this document, which could very well rise to the level of a material adverse effect.

So, where bots are concerned, bad but not disastrous; for everything else -- well, let's just say that Musk's litigation team are burning incense to the gods this morning, while a whole bunch of Twitter execs are going to be spending the next few weeks getting grilled by their own retained counsel, at an even more exorbitant hourly rate than they were paying before.

> They have pipelines of exploitation for everyone that gets "discovered" into contractual nightmare deals, they require tons of free labor and costly hurdles just to become notable and visible on the platform

For what it's worth, as someone running a high-five-digits account, it is possible to get notable on Twitter - you just have to put in a ton of work to make quality content people are actually interested in.

Eval yourselves with the NIST Cybersecurity Framework and you’ll get a good idea of where to work on. It’s useful to guide an early stage security program doing all the things.

Also, build a risk matrix of security risks the company can face by impact vs likelihood of the risk happening. Get someone senior to sign off on it.

Use the NIST CSF and the risk registry with senior leadership support to guide the work you do.

Itll be easier if you think about security as understanding your risk posture as an org, and that risk is either fixed at your level, carefully escalated to outside your teams for a fix, or labeled and accepted risk. security teams should never be the ones to accept risk, so get a a manager to see and acknowledge in writing whenever it’s decided to just roll with a known vuln you’re Unable to fix without more time/money/tech. Try to fix as many risks as possible at your level as to not build an alarmist rep. Then, that leaves space to escalate into cross-team fixes (and you can point to the NIST CSF and the risk register with a senior leader’s sit side as a baseline reason for why they need to fix it).

There is a best practice... but the issue is that the "best practice" is something that gets abused for cargo culting and stopping at the discovery of the best practice.

Some time back, I got a copy of "A Practical Guide for Policy Analysis: The Eightfold Path to More Effective Problem Solving" so that I could properly quote back the use of best practices.

https://en.wikipedia.org/wiki/Best_practice

With most times people are looking at best practices, they skip to the decide step without defining the problem - that's even been done here. Is there a best practice for non-cybersecurity at private business? Well, yes - but first, what is the problem that is trying to be solved? There's no "get this book of everything to do and you're good". On the other hand a "we have customer data that includes PII data, we need to secure the data and prevent casual examination of it in house" is a problem that can be looked at and a best practice can be found.

The best practices involve a survey of looking at other organizations and seeing what they have done - what worked and what didn't.

> Part IV "Smart (Best) Practices" Research - Understanding and Making Use of Whatlook Like Good Ideas from Somewhere Else

> It is only sensible to see what kinds of solutions have been tried in other jurisdictions, agencies, or locales. You want to look for those that appear to have worked pretty well, try to understand exactly how and why they may have worked, and evaluate their applicability to your own situation. IN many circles, this is known as "best practices" research. Simple and commonsensical as this process sounds, it represents many methodological and practical pitfalls. The most important of these is relying on anecdotes and on very limited empirical observations for your ideas. To some extent, these are - one hopes - supplemented by smart theorizing. This method is never perfectly satisfactory, but in the real world the alternative is not usually more empiricism but, rather, no thoughtless theorizing.

> Develop Realistic Expectations

> Semantic Tip First, don't be mislead by the word best in so-called best practice research. Rarely will you have any confidence that some helpful-looking practice is actually the best among all those that address the same problem or opportunity. The extensive and careful research needed to document a claim of best will almost never have been done. Usually, you will be looking for what, more modestly, might be called "good practices."

---

A "here is a list of all the best practices, follow these" is the wrong way to try to use best practices but rather relabeled cargo cult security.