Difference between revisions of "Security notes / Glossary"

From Helpful
Jump to: navigation, search
m (Unsorted)
m (Red Team)
Line 233: Line 233:
  
  
That itself is vague, because isn't all security testing trying to get in?
+
"red teaming" is usually meant as 'think as an attacker, not as a defender
  
: Does it mean doing what wasn't considered in the design? Putting in some more effort?
+
...sounds cool and all, but what does it really mean?
:: Not really, that can describe anyone doing any useful exploit.
+
How is it different?
 +
Isn't all security testing trying to get in?
  
: Is bringing in someone external red teaming?  
+
: is it testing what wasn't considered in the design?
:: Maybe, but then why a new term for pen testing?
+
:: no, you should be doing that anyway - you should check more what the designer though of
:: Also, red team also ''implies'' there is a blue team being educated and trained. That's the ''very point'' of the exercise - otherwise it's ''certainly'' just another term for pen testing.
+
  
 +
: is it bringing in someone external?
 +
:: Maybe, but isn't that called penetration testing?
  
: Does it mean people thinking outside the box to find new angles, rather than just running that portscan or metasplot again?
+
: is it findinf new angles, rather than just running a few established detections?
:: That can work well, but there's so many established ideas that work. (That's why we call them established)
+
:: That can work well, but there's so many different established techniques that work and are important - that's ''why'' they are established
  
: Is it a test that is ''prepared'' to use distinct angles (electronic, physical, social) to get in?
+
: is it being prepared to use distinct angles (electronic, physical, social) rather than just one?
:: Maybe, but that's not uncommon, but you can often go very far with one or two.
+
:: Maybe, but if your task is "find any opening", you can often go very far with one or two
 +
:: and if your job is to use all all three, or "find ''all'' openings"
 +
::: that's not what most red teamers are thinking of
 +
::: It's also often practically infeasible to do exhaustively
  
: Is it a test that tries all?
 
:: That's usually practically infeasible.
 
  
 +
: If the blue team is kept unaware, then is it really a blue team?
 +
:: In the exercise we're referring to, blue teams only exist when there are two teams doing an active exercise.
 +
:: This ''may'' happen in network jobs, because there an IDS is part of the loop, and things may be set up as an exercise.
 +
:: But in physical jobs they are often intentionally kept unaware, because an attack with defenders in their everyday mode is often a much better test.
 +
:: ...so this red/blue stuff is a just not a very good name
 +
:: ''Maybe'' in the specific thing you are testing it makes sense to keep them unaware, to see if they even notice.
 +
:: ''Maybe'' in the specific thing you are testing it makes sense to alert them, to see how they deal with a known attack. This is the only use of the terms that even resembles the military exercise
  
  
So red teaming is usually meant as 'think as an attacker, not as a defender', being prepared to use electronic, physical ''and'' social surface, and model relevant threats.
 
  
That's clearer, but only halfway.
 
  
 +
 +
AFAICT, there are are a lot of people who ''do'' use 'red teaming' and 'penetration testing' more or less interchangably, with nuances.
 +
 +
And often semantics - even when the ''topics'' of nuance are often agreed on, the details are often not.
 +
Perhaps the difference is that pen testing often has more of a scope and is more of a 'see if there are holes in the perimeter and report them', whereas red teaming may be 'do whatever, see how far you can get', e.g. seeing what additional attacks may be feasible from inside.
 +
 +
...but then, there are companies that employ their own red teams, basically trying to break their own system with guarantees that it's not a leak.
 +
 +
 +
 +
 +
There is a good argument that '''It's not red teaming unless there is a blue team being educated and trained to protect the system better'''.
 +
 +
That's ''very point'' of the exercise it was named for.
 +
 +
If you're just writing a report of what was wrong, you ''may'' just be specifying patches, not educating on how to build it better, and it's ''certainly'' just pen testing (with a cooler hat).
 +
 +
 +
 +
'''Threat modelling is always important'''
  
 
Frankly, what you usually want to focus on is threat modelling:  
 
Frankly, what you usually want to focus on is threat modelling:  
 
: What is most important to protect?  
 
: What is most important to protect?  
: What is the likeliest way there?  
+
: What are the likeliest ways there?  
 
: Are those ways protected?
 
: Are those ways protected?
 
: Can you demonstrate a weakness, along with its impact?
 
: Can you demonstrate a weakness, along with its impact?
 +
  
  
Line 269: Line 298:
 
they care about whether a vulnerability is going to cost money and/or make them look bad.
 
they care about whether a vulnerability is going to cost money and/or make them look bad.
  
 +
And maybe second that a decent team didn't find any obvious flaws,
 +
or that the things they found are not going to do much damage.
  
Basically, show them everything you did.
 
Yes, part of the fix is in redesign,
 
but part of itbut being aware how
 
and things like checking that a system trips on all the things it should is something you can only do thoroughly with both involved.
 
 
But actually, what we just called a blue team isn't really, because they are usually kept unaware.
 
 
Blue teams only truly exist when there are two teams doing an active exercise.
 
This ''may'' happen in network jobs, because there an IDS is part of the loop, and things may be set up as an exercise.
 
 
But in physical jobs they are often intentionally kept unaware,
 
because an attack on them in their everyday mode is often a better test.
 
  
  

Revision as of 17:37, 26 October 2021

Security related stuff.

Practical


Theory / unsorted

how to do a login system badly
how to do encryption badly
Disk and file encryption notes


Attacks

Access control

Least privilege (principle)

The principle of least privilege means each actor in a system should be able to access no more than it needs.


For example, you can say

your web server should be denied to real all of the filesystem, except its own documents
your backup program should
be able to read most everything, but...
not be able to run anything (beyond its own components)
not be able to write anything except to the backup disk and its own logs


This is part of why functional accounts are often created for each such part: It's easier to handle this in broad terms even in simpler DAC setups, with just filesystem permissions.

When you want to crack down on this more thoroughly and more visibly, look at things like SELinux (because it adds MAC).


Note that the isolation in VMs and OS containers, are implicitly least-privilege as well: no connection to the outside unless permitted.


See also:

Discretionary Access Control (model)

Discretionary access control (DAC) means access to an object is at the discretion of the object's owner.


...more precisely, the identity of subjects. Usually that's owner-based, though e.g. capability systems often allow transfer to other parts.

Mainly contrasted with MAC

Examples:

permissions in most filesystems

Mandatory Access Control (model)

Mandatory access control (MAC) means that the system that decides access between objects, instead of (or on top of) the object owners.


Often means labeling objects with particular categories, and having rules based on these categories.

Such (often-broad) labeling is often done for practical reasons: it often makes the rules simpler, which makes it more clear they express what you intended.


MAC usually means design up front, and reconsidering that full design on each change.

This is also why it often assists DAC, because

  • while MAC is good at partitioning off parts of a system in broad terms (e.g. web server may only read under /var/www regardless of permissions),
MAC it is less flexible at anything you can't describe fully at the design stage (like people sharing specific files securely).
  • while you can sort of implement DAC with MAC, this is often so messy
to the point that it may be harder to verify as being correct


Role-Based Access Control (model)

Role-based access control (RBAC) does not refer directly to a way of implementing access control (like DAC and MAC), but to the the focus on roles and inheritance, that are often also present in DAC, MAC and others.


It's a moderately detailed abstraction, considered a thing of its own, and can be used to describe/implement DAC and MAC solutions, as well as others.


Related notes

If you squint, there is sometimes very little difference between a category that a MAC system works on and a group that a DAC works on.

That is, very similar to users

The difference lies largely in who may change them - the admin, or the relevant user.

This is also roughly why there is value in mixing them. E.g. stricly separate web server, database, and other in terms of many resources. And have users as a third general pile, they can figure out among themselves and mostly just care about filesystem DAC anyway.

Hacking terminology

Passive recon

Attack vector

Attack surface

Attack factor

Red Team

Unsorted

Forward secrecy

Basically, it refers to protocols that, instead of using one secret key for everything, negotiate unique keys for each session based on a secret key.


This because that session key might be found out if someone invests significant time in finding it for a session they recorded from the network.


Even if they actually find that, it does not reveal the secret, or any other session keys, and the term 'forward secrecy' basically points out that the secret key does not lose value after such an event.


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

Man in the middle

Two generals problem

The bitter ex test

Forward secrecy

Worm, virus, trojan, etc.

Performative security, LARP security, cargo cult security

End to end encryption