5 ms·

Anderson, Security Engineering (Wiley) would make an excellent addition to this list. (The blog post omitted anything infosec saying the field is “part of QA”

by heads 3y ago

Anderson, Security Engineering (Wiley) would make an excellent addition to this list. (The blog post omitted anything infosec saying the field is “part of QA” but it’s not like this list is pure CS — a lot of engineering topics aka “applied computer science” are on the list already.) Security economics is important when building real world software because one has to know one’s enemy in order to decide what to defend against. It is literally the most “street fighting” topic in the field.

tptacek 3y ago
For people who call it "infosec", it probably is, or an admixture of QA and IT.
- pvg 3y ago
  Wait, what do sophisticated people call it and if we adopt it, will they stop saying ‘nation state’?
  - tptacek 3y ago
    It's like 8 different and mostly unrelated disciplines, so, "hardware security", "software security", "vulnerability research", "exploit development", "software reverse engineering", "cryptography engineering", maybe "systems security" if you want to put OS security in a different bucket from software security. And then all the IT and risk management stuff (network security, corporate security, &c). This is off the top of my head. Most of this work is totally unlike QA. Even the parts of it that are like QA (vulnerability research, say) are pretty unlike QA; the bugs you find in QA tend not to be driven by adversaries, so you get to work with a relaxed set of constraints. QA work is much more process-focussed, about repeatability and coverage, and less about detailed study of how systems work. In hardware and cryptography, the work closer in spirit to vuln research is called "verification". There's superficial vuln research that any QA person can (and should! but probably doesn't!) do. But if "looking for bugs" is "QA", have fun explaining to people writing Tamarin proofs for protocols that they're just QA engineers. None of this is to belittle QA work, which is very difficult to do well, and which has its own subfield of ideas and research and tooling and stuff.
    - pvg 3y ago
      Oh sorry, I meant ‘infosec’, the QA thing seems obviously silly. Is your objection to it that it lumps too many things together?
      - tptacek 3y ago
        Yes, it almost doesn't have any meaning at all as a term. It's an umbrella for a bunch of disciplines that are less similar than, say, QA and software development. It can also, as you intuited, kind of be a "tell" for people who aren't thinking seriously about the computer science of security. It isn't automatically, but it pretty clearly is when you're using it in the same breath as "security is just QA". It is the CISSP of terms.
ramimac 3y ago
https://againsthimself.medium.com/security-engineering-proceed-with-caution-6bd4db706968 https://againsthimself.medium.com/security-engineering-proce... A recently published commentary on Security Engineering would be a good supplement, naming the flaws seems a meaningful mitigation for them

by heads 3y ago

tptacek 3y ago

For people who call it "infosec", it probably is, or an admixture of QA and IT.

pvg 3y ago
Wait, what do sophisticated people call it and if we adopt it, will they stop saying ‘nation state’?
- tptacek 3y ago
  It's like 8 different and mostly unrelated disciplines, so, "hardware security", "software security", "vulnerability research", "exploit development", "software reverse engineering", "cryptography engineering", maybe "systems security" if you want to put OS security in a different bucket from software security. And then all the IT and risk management stuff (network security, corporate security, &c). This is off the top of my head. Most of this work is totally unlike QA. Even the parts of it that are like QA (vulnerability research, say) are pretty unlike QA; the bugs you find in QA tend not to be driven by adversaries, so you get to work with a relaxed set of constraints. QA work is much more process-focussed, about repeatability and coverage, and less about detailed study of how systems work. In hardware and cryptography, the work closer in spirit to vuln research is called "verification". There's superficial vuln research that any QA person can (and should! but probably doesn't!) do. But if "looking for bugs" is "QA", have fun explaining to people writing Tamarin proofs for protocols that they're just QA engineers. None of this is to belittle QA work, which is very difficult to do well, and which has its own subfield of ideas and research and tooling and stuff.
  - pvg 3y ago
    Oh sorry, I meant ‘infosec’, the QA thing seems obviously silly. Is your objection to it that it lumps too many things together?
    - tptacek 3y ago
      Yes, it almost doesn't have any meaning at all as a term. It's an umbrella for a bunch of disciplines that are less similar than, say, QA and software development. It can also, as you intuited, kind of be a "tell" for people who aren't thinking seriously about the computer science of security. It isn't automatically, but it pretty clearly is when you're using it in the same breath as "security is just QA". It is the CISSP of terms.

ramimac 3y ago

https://againsthimself.medium.com/security-engineering-proceed-with-caution-6bd4db706968 https://againsthimself.medium.com/security-engineering-proce... A recently published commentary on Security Engineering would be a good supplement, naming the flaws seems a meaningful mitigation for them