4 ms·

Because security without a threat model is an endless well of paranoia that leads to mere paralysis, an inability to change because of some infinitesimal chance

by msla 4y ago

Because security without a threat model is an endless well of paranoia that leads to mere paralysis, an inability to change because of some infinitesimal chance that someone with unguessed capabilities and unclear goals might subvert a fundamental part of the system. In short: Give me a threat model, by which I mean realistic groups with goals and capabilities, and we can mitigate the risks. Just talking about "security" in a void is pointless at best and harmful at worst, since ill-considered security measures have a habit of leading to even worse insecurity.

nicce 4y ago
In Europe you don’t need to look further than legistlation. Which already defines many things what you should consider in securing. It is not pointless to talk about just ”security” if there is any data which should not be exposed to another party without permission. But if there some other concerns instead of that, then it gets complicated.
- dmitriid 4y ago
  > In Europe you don’t need to look further than legistlation. Heh. Just realized this is true on many levels. For example, if you don't collect more data than necessary (per GDPR), there's significantly fewer things that you need to secure.
ajmurmann 4y ago
"Give me a threat model, by which I mean realistic groups with goals and capabilities, and we can mitigate the risks." Thread models are important, but having a concrete adversary in mind is likely misguided. To whom you are an interesting target is hard to know and can change in a heart beat with economic or political events. You don't want to start looking for possible SQL injection vectors once you know someone is targeting you. I agree though that three threat model should include damage potential and how sophisticated an attacker would have to be.
- generalizations 4y ago
  > You don't want to start looking for possible SQL injection vectors once you know someone is targeting you. Except that SQL injection vectors are only considered an obvious threat for your example, because the associated concrete adversary is already well-known to everyone here. The point is that without a realistic threat model, you have no idea where to draw the line. If you plan to try and anticipate every possible threat (because who knows if your app's data will be targeted by The Russians next week) then just unplug your hosting servers and put them in a locked room.
  - ajmurmann 4y ago
    I think you can make that decision without knowing the concrete actor. Instead of asking if Russia has a concrete interest in hacking my product I can ask if it's worth it to protect against all possibly attacks from nation state actors. For almost all applications the answer will be "no".
lofaszvanitt 4y ago
From a different angle threat model is basically disseminated bullshit in order to make you believe that there are actors whom you cannot oversmart/protect against. In essence you are running in a rigged environment, and better accept the "common truths"...
pjc50 4y ago
Yes. Security, like legal compliance, GDPR, etc, is focused on minimizing risks. The least risky strategy is to do nothing: write no code, ship no product, have no users. Therefore it's a constant pressure against delivery. It's certainly worthwhile to think about, but the best approach is a bug-avoidance one where the tools guide you away from making mistakes but without constraining your ability to get things done too much.
thinkharderdev 4y ago
> by which I mean realistic groups with goals and capabilities TBH I think you are missing the point of threat modeling. It's not an exercise in determining the exact adversary you will face and what capabilities they will have. That is impossible to know with any precision. It's more an exercise in thinking through 1. What your assets are. 2. What attack vectors exist for compromising those assets and 3. What mitigations can be put in place for those attack vectors. In doing that you may reasonably conclude that for a given attack vector, an adversary sufficiently advanced to pull it off would not be interested in you and that is fine. But you should still start from what you know concretely, which is what your system architecture and assets are.
- generalizations 4y ago
  You missed a step there. It's actually closer to: 1. What your assets are. 2. Who is interested in those assets. 3. What attack vectors exist that are feasible/available to the interested parties for compromising those assets 4. What mitigations can be put in place for those attack vectors. Otherwise, as I said elsewhere, there will always be an attack vector, right up to the point where the computers are turned off and in a locked room. The only way to explicitly choose not to take that extreme measure is to figure out who you are, and are not, defending against.
  - jdsnape 4y ago
    Instead of focusing on ‘who’ specifically, step 3 of threat modelling actually focuses on the likelihood of something happening and the impact of it does. From that you can determine whether the cost of applying the mitigation is ‘worth’ applying in terms of reducing the impact of the threat to an acceptable level that the business can accept. Of course, the ‘who’ is part of that consideration of likelihood, but it’s not the only part.
  - thinkharderdev 4y ago
    I'm not sure we actually would disagree on anything concrete but for the sake of argument: > 2. Who is interested in those assets. This is the wrong question to ask. The right question is how important is it to US to keep this asset confidential/available/unmolested. That is a question that is actually tractable and understandable. If you have a service where it is very important that it is always available, then you need to have mitigations in place to prevent DDoS attacks. Whether or not you have some hypothesis as to who exactly might want to attack you is beside the point. If it's important to YOU then you should just assume that there is some threat actor out there who will attack you. On the other hand, if it doesn't matter at all whether said service is consistently available, then it's not worth the time/effort/expense to put in place DDoS mitigations regardless of whether there is any threat actor out there.
MattPalmer1086 4y ago
While it is true that a threat model is really needed to inform prioritisation of security controls and other mitigations, there are many secure coding techniques that developers should be using, but clearly often don't. As a security architect who comes from a dev background, I am acutely aware of the pressures devs are under to ship code. Even so, there are some things you should really try to write securely without a formal threat model. As a professional you should at least be aware of common vulnerabilities in code and not blindly keep creating them, e.g. know your OWASP top ten if you're writing for the web or mobile.
- watwut 4y ago
  > there are many secure coding techniques that developers should be using, but clearly often don't. I will bite here. Which ones exactly should be used and are not by common developer? > know your OWASP top ten if you're writing for the web or mobile. There is no "my OWASP top ten" and being able to list them helps zero in day to day coding work. The practical knowledge about secure coding does not come from OWASP. It actually typically comes from documentation of frameworks you use, their communication about their libraries and then knowledge about process.
  - MattPalmer1086 4y ago
    That's interesting, thanks. I can see how practical techniques will make most sense if they are closer to what you're doing. I'm wondering how to bridge that gap so there is some assurance for the organisation as well as training for the developer.
    - watwut 4y ago
      What it is that you want to teach them in the training? I mean the question genuinely, not as a snark. I am curious about what you (or other security people) see as missing part. I have seen security audit of what we were working on done few times and found it interesting to read. It is good to put that stuff into training materials and repeat it to people. It is actually cool if you can demonstrate attack on their own software (there is always someone who will call your attack theoretical until you demonstrate it). Imo, the best security is the one that does not depends too much on developers remembering to do the right thing all the time. So for example if there is a method that leads to protentional SQL injection or XSS or whatever, prohibit its use and write unit test for it. Basically, static analysis of a code. So then, when someone accidently uses it, the test suite will complain. Hide unsafe things behind internal libraries that force developers do the right thing. Make the right thing easier then the wrong thing. The other good thing are checklists - checklist of ui code, checklist for API, checklist for database, checklist for configuration. In my opinion, if you want assurance about something important, have checking it regular routine part of process and ideally automated. There is always someone who does not know or dont care or is just tired and not focusing. The best compliance is the one that happens automatically as the easiest thing to do.

by msla 4y ago

nicce 4y ago

In Europe you don’t need to look further than legistlation. Which already defines many things what you should consider in securing. It is not pointless to talk about just ”security” if there is any data which should not be exposed to another party without permission. But if there some other concerns instead of that, then it gets complicated.

dmitriid 4y ago
> In Europe you don’t need to look further than legistlation. Heh. Just realized this is true on many levels. For example, if you don't collect more data than necessary (per GDPR), there's significantly fewer things that you need to secure.

ajmurmann 4y ago

"Give me a threat model, by which I mean realistic groups with goals and capabilities, and we can mitigate the risks." Thread models are important, but having a concrete adversary in mind is likely misguided. To whom you are an interesting target is hard to know and can change in a heart beat with economic or political events. You don't want to start looking for possible SQL injection vectors once you know someone is targeting you. I agree though that three threat model should include damage potential and how sophisticated an attacker would have to be.

generalizations 4y ago
> You don't want to start looking for possible SQL injection vectors once you know someone is targeting you. Except that SQL injection vectors are only considered an obvious threat for your example, because the associated concrete adversary is already well-known to everyone here. The point is that without a realistic threat model, you have no idea where to draw the line. If you plan to try and anticipate every possible threat (because who knows if your app's data will be targeted by The Russians next week) then just unplug your hosting servers and put them in a locked room.
- ajmurmann 4y ago
  I think you can make that decision without knowing the concrete actor. Instead of asking if Russia has a concrete interest in hacking my product I can ask if it's worth it to protect against all possibly attacks from nation state actors. For almost all applications the answer will be "no".

lofaszvanitt 4y ago

From a different angle threat model is basically disseminated bullshit in order to make you believe that there are actors whom you cannot oversmart/protect against. In essence you are running in a rigged environment, and better accept the "common truths"...

pjc50 4y ago

Yes. Security, like legal compliance, GDPR, etc, is focused on minimizing risks. The least risky strategy is to do nothing: write no code, ship no product, have no users. Therefore it's a constant pressure against delivery. It's certainly worthwhile to think about, but the best approach is a bug-avoidance one where the tools guide you away from making mistakes but without constraining your ability to get things done too much.

thinkharderdev 4y ago

> by which I mean realistic groups with goals and capabilities TBH I think you are missing the point of threat modeling. It's not an exercise in determining the exact adversary you will face and what capabilities they will have. That is impossible to know with any precision. It's more an exercise in thinking through 1. What your assets are. 2. What attack vectors exist for compromising those assets and 3. What mitigations can be put in place for those attack vectors. In doing that you may reasonably conclude that for a given attack vector, an adversary sufficiently advanced to pull it off would not be interested in you and that is fine. But you should still start from what you know concretely, which is what your system architecture and assets are.

generalizations 4y ago
You missed a step there. It's actually closer to: 1. What your assets are. 2. Who is interested in those assets. 3. What attack vectors exist that are feasible/available to the interested parties for compromising those assets 4. What mitigations can be put in place for those attack vectors. Otherwise, as I said elsewhere, there will always be an attack vector, right up to the point where the computers are turned off and in a locked room. The only way to explicitly choose not to take that extreme measure is to figure out who you are, and are not, defending against.
- jdsnape 4y ago
  Instead of focusing on ‘who’ specifically, step 3 of threat modelling actually focuses on the likelihood of something happening and the impact of it does. From that you can determine whether the cost of applying the mitigation is ‘worth’ applying in terms of reducing the impact of the threat to an acceptable level that the business can accept. Of course, the ‘who’ is part of that consideration of likelihood, but it’s not the only part.
- thinkharderdev 4y ago
  I'm not sure we actually would disagree on anything concrete but for the sake of argument: > 2. Who is interested in those assets. This is the wrong question to ask. The right question is how important is it to US to keep this asset confidential/available/unmolested. That is a question that is actually tractable and understandable. If you have a service where it is very important that it is always available, then you need to have mitigations in place to prevent DDoS attacks. Whether or not you have some hypothesis as to who exactly might want to attack you is beside the point. If it's important to YOU then you should just assume that there is some threat actor out there who will attack you. On the other hand, if it doesn't matter at all whether said service is consistently available, then it's not worth the time/effort/expense to put in place DDoS mitigations regardless of whether there is any threat actor out there.

MattPalmer1086 4y ago

While it is true that a threat model is really needed to inform prioritisation of security controls and other mitigations, there are many secure coding techniques that developers should be using, but clearly often don't. As a security architect who comes from a dev background, I am acutely aware of the pressures devs are under to ship code. Even so, there are some things you should really try to write securely without a formal threat model. As a professional you should at least be aware of common vulnerabilities in code and not blindly keep creating them, e.g. know your OWASP top ten if you're writing for the web or mobile.

watwut 4y ago
> there are many secure coding techniques that developers should be using, but clearly often don't. I will bite here. Which ones exactly should be used and are not by common developer? > know your OWASP top ten if you're writing for the web or mobile. There is no "my OWASP top ten" and being able to list them helps zero in day to day coding work. The practical knowledge about secure coding does not come from OWASP. It actually typically comes from documentation of frameworks you use, their communication about their libraries and then knowledge about process.
- MattPalmer1086 4y ago
  That's interesting, thanks. I can see how practical techniques will make most sense if they are closer to what you're doing. I'm wondering how to bridge that gap so there is some assurance for the organisation as well as training for the developer.
  - watwut 4y ago
    What it is that you want to teach them in the training? I mean the question genuinely, not as a snark. I am curious about what you (or other security people) see as missing part. I have seen security audit of what we were working on done few times and found it interesting to read. It is good to put that stuff into training materials and repeat it to people. It is actually cool if you can demonstrate attack on their own software (there is always someone who will call your attack theoretical until you demonstrate it). Imo, the best security is the one that does not depends too much on developers remembering to do the right thing all the time. So for example if there is a method that leads to protentional SQL injection or XSS or whatever, prohibit its use and write unit test for it. Basically, static analysis of a code. So then, when someone accidently uses it, the test suite will complain. Hide unsafe things behind internal libraries that force developers do the right thing. Make the right thing easier then the wrong thing. The other good thing are checklists - checklist of ui code, checklist for API, checklist for database, checklist for configuration. In my opinion, if you want assurance about something important, have checking it regular routine part of process and ideally automated. There is always someone who does not know or dont care or is just tired and not focusing. The best compliance is the one that happens automatically as the easiest thing to do.