Re: [Model-t] [e-mail] list description

[Watson Ladd <[e-mail]>]

How on earth do I write a Security Consideration section that
addresses that sort of high level thing?
What does this methodology produce?

When we look at actual vulnerabilities with CVE numbers attached, and
go back we don't see "active remote attack". We see using C is a bad
idea. Look at programs doing what the users didn't want, and the
answer isn't DNS filtering, it's sandboxing. Where is that in your
list of answers? Attacks like "Johnny You're Fired" have a cause:
overly complicated file formats with lots of edge cases.  These are
problems that some of which the IETF can't solve but some where a
better threat model and understanding of security would have solved.

At the same time we see problems like Amazon's architecture around VM
authentication not respecting traditional Unix permission models
because it makes credentials available over HTTP from the machine. So
if you take a standard sort of setup and move it to the cloud, you now
can have a problem sometimes called SSRF, but really just another
Confused Deputy. I believe this was discovered on MULTICS.

We need to have a model that gets people answering the right question,
not the wrong one. And a threat taxonomy at the high level just says
there are bad people online. We know that. That's the problem. How do
we stop them from doing what they want? Well, that's where computer
security comes in, and the goal has to be to recognize the security
properties we want, and ensure the systems we have have those
properties. And the threat model informs what the properties are. It
doesn't matter how big the system. It doesn't matter if it's accessed
by pigeon, phone, microwave link, or 5G. It doesn't even need to be
made of silicon: HFDF was an anonymity attack resulting in location
detection at the PHY layer, as was identifying telegraph operators by
their fist.

On Sat, Aug 3, 2019 at 10:26 AM Bret Jordan <[e-mail]> wrote:
>
> Stephen,
>
> While there are several minor variations on the “Kill Chain” as defined originally by Lockheed Martin in the following paper back in 2011 I think (https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf).
>
> In addition, MITRE has recently produced an ATT&CK framework to help identify and characterize threat actor behavior.  NIST has already produced a Cyber Security Framework that is commonly used when talking about these sorts of things.
>
> STIX on the other hand is a taxonomy for sharing threat intelligence.  Things like threat actors, campaigns, intrusion sets, attack patterns, malware information, indicators of compromise, etc etc.
>
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
>
> On Aug 3, 2019, at 8:40 AM, Stephen Farrell <[e-mail]> wrote:
>
>
>
> On 03/08/2019 15:37, Bret Jordan wrote:
>
> I did not use anything from STIX. Are you referring to the use of
> kill chain phase?
>
> I was. If you're using some other methodology be interested
> in which. (Those information model based approaches to
> describing threats/incidents aren't something I follow in
> detail.)
>
> Cheers,
> S.
> <0x5AB2FAF17B172BEA.asc>
>
>
> --
> Model-t mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.