January 19th, 2022
Everybody’s career path into and within
“Information Security” — about as broad and
ill-defined a field as any — is different. We all
come from different backgrounds with different
experiences, and even if our job titles may be the
same, in practice we are bound to perform different
tasks.[1]
But some skill sets tend to intersect. I’ve tried
to compile a list of primarily technical “core
competencies” before, but that
only covered so-called “hard skills”. “Soft skills”,
on the other hand, are actually a lot harder, but of
course there’s overlap here indicating a conceptual
difficulty in categorizing “technical” and
“non-technical” skills. Overlap, you say? To the Venn
Diagramminator!

Oh, this is deep. I know. But bear with me. Let’s
claim that we have certain technical skills
as well as some non-technical skills. So
far, so obvious. But we also have a weird little
skill set comprising that odd area that is a result
of just working “in tech”. And then there’s
a bunch of this, that, and the other. But let’s zoom
in, first on the technical skills:

That’s right: I’m recycling one of my
earlier Venn diagrams. Of course there’s more to
the technical skills, but let’s try to very broadly
categorize them as Computer Science,
Programming, Operations, and
Networking. They all overlap and intersect:
everybody has their own, personal Venn diagram of
those skills, and comprising sets do not imply a
requirement to possess all the skills:
instead, each circle represents a set of
possible skills.
I do think it’s important to draw the distinction
between e.g., Computer Science and
Programming: you absolutely can do either one
without the other, but they do complement one
another[2]. So let’s zoom in once
more. Operator, enhance!

Core concepts in Computer Science that I consider
useful and applicable here include:
What | Why | Example |
very basic algorithmic complexity | useful to understand: the impact of your programmatic solutions, what level of analysis is feasible; generic problem scope; etc. |
hash tables are O(1) average; nested loops may lead to O(n^x); how password complexity requirements push brute force cracking; impact of recursion |
cryptographic primitives and concepts | useful to understand protocols, analysis of architectures, development, analysis of compromise impact | hash functions and HMACs, symmetric/asymmetric encryption, nonce, signatures, RNGs, block- vs stream cipher, entropy |
pointers and buffers | useful to understand: reference, indirection, memory management, buffer overflows |
strlcat(3) vs strncat(3), sizeof != strlen, pointer arithmetic (p[x] == *(p + x) |
Enough data structures to know that you want a hash, not a list | useful when coding up even simple tools to process some data | see above re O(1) lookups |
Conceptual difficulty of common problems in CS | useful to assess feasibility of proposed solutions | halting problem, traveling salesman, dining philosophers, … |
Does everybody who works in infosec need a
background in Computer Science? No, but it helps in
most cases. Can you learn these concepts without
formally studying Computer Science? Of course, but
that doesn’t change anything about it being
Computer Science. Are there many more areas that
could or arguably should be included here? Sure, why
not! Is posing questions and then answering them a
particularly annoying style of trying to make a point?
Also yes.
But then what kind of skills do we generally see
under programming? Beep, beep, bzzzt,
re-zoom, enhance:

I do distinguish
between programming and software
engineering, and here I merely list some of
the programming skills that are useful to the majority
of cybersecurity practitioners, including, but not
limited to:
- Automation of repetitive tasks
- Code reading
- Core concepts and paradigms
- Classes of code vulnerabilities
- Proof of Concept development and validation
Most of us are processing data in some fashion; we
have to be able to read code written by others, e.g.,
internally for product security reviews or externally
to understand a vulnerability or proof of concept
exploit etc.; many of us also need to verify exploits
and vulnerabilities, and being able to stand up a
proof of concept ourselves is obviously helpful.
Comparing these to the CS skills hopefully illustrates
why those would be useful.
But reading, writing, and running programs is
only part of the story. Even if we don’t actually
operate our own infrastructure ourselves, understanding
how it works has significant impact on our ability to
protect it:

I decided to somewhat arbitrarily single out the
following areas as examples:
What | Why | Example |
HTTP Services, load balancers, proxies | How traffic enters into and travels through your network defines your attack surface. |
HTTP protocols supported by your edge proxies, TLS termination |
Configuration Management | Useful to understand e.g., how to deploy configuration changes across your fleet, whether you are reactive or prescriptive, what aspe |