Adam may come to regret asking this.🙂 Because I most definitely have thoughts about some of the analytical lessons and methods taught, explicitly and implicitly, to those learning to "think like a lawyer" that can be useful much more broadly.
First, I think I have to talk about the power of reasoning by analogy.
If you get a legal education in an nation that has an Anglo-American system of legal traditions, you'll spend a lot of time reading case law and learning how to dissect case precedents.
And, eventually (at least in US law schools), to make written and verbal arguments about them yourself.
The whole exercise of extracting legal rules and figuring out how and whether they apply to a current circumstance is really an exercise in reasoning by analogy.
Once you start to get somewhat good at such things, you start to understand a bit about how powerful reasoning by analogy can be. When done well, it allows us to draw on powerful insights of those from the past and take advantage of experiences without reinventing the wheel.
Now, in doing so one must always be careful not to treat as similar things that should not really be treated as similar. And key parts of leaning how to reason and argue about precedent case law involve exactly that.
Second, I think the process of legal education teaches you to be better at separating evaluating the merits of an argument from what opinions you have generally about those that are making it or would benefit from it being accepted.
When you start reading those cases I mentioned, you'll quickly start coming across ones where you dislike what a certain party was doing, but you see the legal merits of what they are arguing in front of a court.
In other words, you see either why the law is on their side or why, for policy reasons and the greater good, the law should be on their side given certain facts in the case that will also be true in many other cases.
Separating out dislike, even revulsion, for one making an argument from evaluating the merits of that argument is a really hard thing. But if you commit yourself with intellectual honesty to the study of law (and, in many roles, the practice of it), you'll have to deal with that.
Third, the fact that in many exercises in legal education--and in many situations in some roles in the practice of law--you don't really get to choose which side of an argument you'd prefer to be on is helpful to your analytical development.
Being assigned a side and told to make the best arguments for or against something actually trains you in evaluating the strengths and weaknesses of positions in more rigorous ways.
If you're really learning the lesson, you start to see that many disputes which might appear clear cut are more closely balanced than many might appreciate.
Fourth, and finally (for now), I'll quickly mention learning the rules and techniques of techniques of litigation (at least under US law) , and some useful analytical lessons I've taken from that.
If you want to practice litigation in the US, you have to learn the rules of evidence and procedure.
Doing so hopefully gets you to think probably more than you ever have about what kind of proof really should be persuasive to you when it comes to accepting or rejecting claims.
(Note: Many who have been educated in and/or practiced law can find the effects of thinking like this seeping into interactions in their personal lives.
Trying to explain to your spouse why a point they're making is actually irrelevant isn't likely to go well.)
When it comes to trial practice and advocacy, let me also throw in a word about learning lessons from cross examination and how to deal with experts.
Cross examination in a court of a law can be one of the greatest devices for ascertaining truth there is. And the process of learning how to prepare cross--the in-depth study of the facts, the bringing of detail-oriented scrutiny--tremendously builds your analytical muscles.
Finally (really finally) the study and practice of litigation teaches you how to evaluate, scrutinize, and critically compare claims made by experts. Especially where there are competing experts on different sides. (And you can *always* find an expert to disagree with another.)
Whew. Anyway, those are my off-the-cuff🙂 thoughts about the question.
[fin]
• • •
Missing some Tweet in this thread? You can try to
force a refresh
BTW, one thing to remember:
The single most commonly abused technique attackers use to go from initial foothold to total domain compromise is actually just using privileges the foothold account + machine has due to direct or nested/indirect membership in highly privileged groups.
Reading intrusion and pen test reports on a regular basis really gives you an appreciation for how disastrously common this is.
Likewise with the technique of using privileges on the initial host to move to an account/box that in turn is a member of highly privileged groups.
Aside from preventing the attacker from initially landing someplace that has access to high privileges or allows control over some other accounts/box that does, the next highest priority in modern AD defense is, I'd argue, is preventing Kerberoasting.
From a security standpoint, what would you do if you wanted to setup a new Active Directory installation today *and* wanted it to be at least decently secure?
In answer, many fashionable IT/tech people would just give you just a laugh. But really, what would it take?
A quick🧵:
Well, first priority: You want to create a rational number of privileged accounts (admin & service accounts) and have them be able to login only from specified groups of hardened devices.
Ok.
But this is much the same thing you should be doing on literally any identity platform.
(Specific to AD, you'd probably want to use authentication policies/silos to do this. And you'd also want to put all highly privileged accounts in the Protected Users group, for reasons we'll discuss in a minute.)
Okay, after finally reading/puzzling through CrowdStrike's Root Cause Analysis (the way the 20 vs 21 inputs thing actually worked is confusing as hell) I can empathize a bit more with CS's people. And I finally think I can explain what happened here in layman's terms:
🧵
Basically, CrowdStrike wanted to have the ability to frequently push out new detections to spot malware very frequently and very fast.
The way this worked is that something called a Template Instance would essentially contain matching rules for spotting activity of concern.
Now, CS thought these Template Instances weren't dangerous enough from a reliability standpoint for each new Template Instance, or each new Channel File that bundled many Template Instances together, to need to be run through live testing on real systems.
So, it's easy to agree with the guy here, as far as what he says goes: big tech & security firms all represent, explicitly and/or implicitly, that their products are suitable for critical infrastructure uses. They should test them appropriately.
But, not to put too fine a point on it, the CEO of Delta should really know that big tech & sec firms have not infrequently been proven to be full of 💩 in terms of what they represent about their products, how they are built, and what they are suitable for.
Could one have predicted that CrowdStrike would be so reckless as not to actually do even the most rudimentary testing on the type of updates involved in this situation? Maybe not.
But it's entirely possible that another problem that would have slipped by such testing could...
From 2020-2023, UnitedHealthcare Group's then-CISO "orchestrated a complete reinvention of the cybersecurity program." Facilitating "rapid business expansion through frequent acquisitions, averaging approximately two companies each month."
😬😬 cybersecuritysummit.com/speaker/cardwe…
Meanwhile, it's a little harder than you might think to find out who UHG's senior year officer who nominally overseas cybersecurity is supposed to be.
There's no real mention of one on UHG's page for senior executive leadership biographies. unitedhealthgroup.com/people-and-bus…
But why not?
After all, if you're an organization that is aware of the increasing threat posed by MFA-aware phishing attacks you're probably quite interested in moving to phishing-resistant auth.
And device-bound passkeys are pretty good in terms of phishing-resistance.
(You would, AFAIK, have to own or compromise a trusted certificate authority to perform a phishing attack on a user authenticating with device-bound passkeys.)