Signs of Triviality

Opinions, mostly my own, on the importance of being and other things.
[homepage] [index] [] [@jschauma] [RSS]

(Technical) Infosec Core Competencies

June 9th, 2021

Screenshot from 'Jurassic Park': It's a Unix
system - I know this! Every so often, I get asked how people can enter into information security, what they should study or what certifications they should pursue. I don't have a good answer to this question. Or rather, I don't have an easy answer to this question.

I don't find much value in any specific certification program, and I know that everybody's path is different, so I'm hesitant to give any more specific advice but a broad recommendation to work with your organization's security team on practical projects to gain experience and an understanding of how the team functions.

However, at the same time, there are a number of things that I regard as, well, a common body of knowledge in the field, a set of core competencies.

They are, in no particular order, and with no claim to completeness:

  1. How to read a CVE announcement and assess the impact based on its CWE / CVSS score and description. Understand that CVSS scores are relative and impact in your environment may be different.
  2. How to read a hyped, name- and logo branded, corporation backed vulnerability announcement -- as well as the relevant RFCs and actual research paper, if any, instead of just the breathless webpage -- and distill the actual, realistic threat to your environment.
  3. The difference between a vulnerability, a threat, risk, an exploit, and attack surface; the likelihood of an exploit based on an adversary's motivation, goals, and capabilities; being able to ballpark the cost of defense within a given scope.
  4. The difference between authentication (authN) and authorization (authZ); between secrecy and authenticity; between authenticity and integrity. Be able to translate these concepts across different contexts.
  5. The difference between symmetric or private and asymmetric or public key cryptography; between encryption and hashing; between a key derivation function and an HMAC used for message authentication.
  6. You don't need to be cryptographer, but you should know roughly what the cryptographic right answers for your developers' questions are -- and why.
  7. The difference between encryption in transit and encryption at rest.
  8. Know to use TLS >= 1.2, but you don't need to know the details of all the ciphers and algorithms. But you should understand mTLS and client cert validation vs. server cert validation conceptually.
  9. Understand the x509 PKI concepts, trusted CA bundles, cert chains, and common client behavior.
  10. Know how to use 'openssl s_client' and 'openssl x509' to troubleshoot TLS connections, including STARTTLS.
  11. HTTP basics: be able to make manual HTTP requests via telnet(1) / openssl s_client; know enough HTTP headers and the general concepts of CSP; be able to use in-browser developer tools to troubleshoot, debug, and replay requests.
  12. Enough of the JavaScript and HTML DOM to understand the different XSS attack types conceptually.
  13. How to use curl(1) to post data to and pull information from an API; use jq(1) to manipulate JSON.
  14. Be able to use tcpdump(1) to at least get the gist of what's going on on the wire. I.e., protocol, type, port, TCP S/R/P/F/., sequence numbers, payload...
  15. Be able to use e.g., Wireshark to drill down into specific flows, filter and pick outliers out of the noise, debug TLS with logged pre-master secret.
  16. Be aware of the different ICMP types beyond echo request/reply: time exceeded, fragmentation required, destination unreachable...
  17. Be able to spot certain CIDRs. E.g., for IPv4: 127/8, 169.254/16, 224/4, 240/4, RFC1918; for IPv6: ::1, fc00::/7, fe80::/10, ff00::/8
  18. Understand that RFC1918 does not imply the host cannot be reached from the internet; internalize that NAT is not a security control.
  19. How to send arbitrary packets between two hosts, e.g., via nc(1) or bash /dev/tcp.
  20. The difference between "Connection refused", "Connection timed out", and "Name or service not known/host not found".
  21. Be able to use dig(1), nslookup(1) and host(1) and understand why they don't care about what you put into /etc/hosts.
  22. Understand basic DNS resolution. I.e., lookups from client->stub resolver->resolver and resolvers<->auths.
  23. Understand domain registration, NS records, TTLs, and zone delegation. Grasp the difference in threat model between plain DNS, DoH, and DNSSEC.
  24. Understand cache poisoning as a concept and as applied to different protocols, such as ARP, DNS, HTTP Proxy, ...
  25. Have a general awareness of the physical internet, peering, ASNs, BGP hijacking, and how (and when) governments can (and do) censor or intercept/inspect (parts of) the internet for their jurisdiction.
  26. How to use ktrace(1) / strace(1) / dtrace(1) to figure out just what files or sockets a program is accessing.
  27. Be able to use nmap(1) to identify a host's open ports and fingerprint them.
  28. Be able to use SSH port forwarding, SSH pubkey options (from=, command= / ForceCommand), ProxyCommand, and use of SSH agents.
  29. Basic Unix skills, pipes and common tools: grep(1), sed(1), awk(1), sort(1), uniq(1), diff(1), comm(1), tr(1), ...
  30. Know how to use screen(1) / tmux(1) to keep long sessions uninterrupted, to resume if needed, to juggle multiple remote terminals in a single window.
  31. Really understand the Unix permissions model: owner, group, others; permissions on directories (e.g., 1777, 0711), Unix groups; su(1) and sudo(1); how setuid/setgid works.
  32. Understand TOCTOU attacks, mktemp(3), and umask(2).
  33. Be able to convert timestamps between formats and know to look for UTC offset when correlating log entries.
  34. Enough shell scripting to automate the execution of repeated commands, including flow control using loops, functions, and variable expansion.
  35. Enough Python, Perl, PHP, C, Go, Java, and JavaScript to be able to read all the random code you come across and at least make some sense of it.
  36. Enough C to understand how a buffer overflow works and how to spot one. (90% of the time a sprintf(3) of a user-generated string into a fixed-size buffer.)
  37. Enough SQL to be able to explain Little Bobby Tables and to pull records from multiple tables.
  38. Enough input- and shell meta-characters escaping to detect, abuse, and fix unsanitized system(3) / popen(3) command-injections (in the various languages).
  39. Be able to efficiently use your preferred package manager to identify file/package ownership, dependencies, package integrity. Be able to create a package in your commonly used package manager format (.deb, .rpm, ...) for a non-trivial piece of software to understand packaging, install scripts, signatures, validation etc.
  40. Enough AWS* to be able to spin up an instance when needed. Grok the difference between NACLs and Security Groups. Be able to manage simple IAM resources and to inspect and lock down an S3 bucket.
    *Azure, GCP, whatever, although, honestly, AWS remains the 600 lb gorilla, so...
  41. Enough Kerberos to understand the concept of client authentication versus service authorization and replay attacks.
  42. Enough PGP to be able to send/receive, encrypt/decrypt, and sign/verify encrypted and signed messages.
  43. Understand SMTP basics, email headers, etc. Know enough about SPF/DKIM/DMARC to identify those headers and understand what they are telling you.
  44. Shamir's 3 Laws of Cryptography:
    • Absolutely secure systems do not exist
    • To halve your vulnerability, you have to double your expenditure
    • Cryptography is typically bypassed, not penetrated
  45. Schneier's Law (Any person can invent a security system so clever that she or he can't think of how to break it.) and not to attempt to invent your own cryptographic protocol.
  46. Be able to explain core concepts like Zero Trust, Defense in Depth, Least Privilege, Failing Closed, and Kerckhoff's Principle vs. Security by Obscurity.
  47. How containers are different from virtual machines, and what their respective trust- and control boundaries are.
  48. How to file an actionable, useful bug report. Know how to manage your own ticket queue.
  49. When to seek input from others: there's not just domain specific, but plenty of general security expertise outside of the information security team.
  50. Nothing, absolutely nothing about cryptocurrencies. "Crypto" means "cryptography". That's all you need to know.
Screenshot from Wikipedia's page on
Cryptosporidiosis, noting that 'crypto is a parasitic


Now granted, the above list is shaped by my own personal background and experience, and you may do well without many of them, making up for gaps with experience and knowledge in areas that I lack. That's quite ok.

You may also notice that a lot of this overlaps with a general understanding of... well, computering on the internet, with operations and system administration concepts. This is no coincidence. Good ops is good security.

A fair bit of what I regard as essential in this field is covered in my video lectures; if you are interested, please do check them out and don't hesitate to hit me up with any follow-up questions you might have.

Oh, and if you note the absence of all the "soft skills" here: well, those are harder. Perhaps another time...

June 9th, 2021

See also:


[Behavioral Economics in Information Security] [Index] [URLs: It's complicated...]