Don't like this style? Click here to change it! blue.css
Alright, so let's reflect a bit.
Did you grow from the experience?
So there are other approaches to learning secure software design.
One is to learn the lessons and procedures of the rest of the industry and become an advocate for following generally good advice. Here's what that kind of looks like:
Head to the SEI C Standard. Poke around a bit.
Here I could have stayed on the dev side the whole time, and we could practice looking at writing code that follows these types of rules. Maybe contextualize them with some case studies or something, but to internalize the right way to code low-level products.
There is a high chance that this would be more practical for a corporate coding position.
Given a set of rules like this we could use a "static analysis toolchain" to evaluate source code for violations of these rules.
Checkout ROSECHECKERS the corresponding rules checker.
This is sort of like TypeScript and Linting as general software practices.
These days you can probably get an LLM to make a static analyzer for you based on your preferences.
I'd get bored.
Also I think that learning rules from on high doesn't foster the intellectual power I want for you.
Like if someone gives you a life rule to follow, like never walk under a ladder. You follow it. They die. You keep spreading the rule. We end up spreading ladder rules to everyone and no one really knows why.
My version of that is to walk under some ladders, get hit in the head, have other people walk under ladders and you hit them in the head. Now you understand when to get worried about ladders, when not to, and more importantly to pay attention to the crazy people on ladders and their hammers rather than the ladder itself.
Call it FIRST PRINCIPLES thinking.
Do I think the CMU students in their version of this class will make more secure code than you? Well maybe. But I expect you to be more likely to discover the next wave of exploits.
Let's look at the more DevOps version of Secure Software Design:
Look at a NIST Secure Software Development Framework
How about Microsoft's version: SDL
Maybe I'm just never grew up, but I think that these sort of things are dehumanizing. "Let us create procedures and rules for how things are done here." This is thinking from the era of needing factory workers. I say build your people up and hire slowly and carefully. Foster their sense of ownership in those teams. We aren't replaceable parts.
This is purely my preference for how life ought to be lived. So we did hacking.
Let's poke at the MITRE ATTACK framework.
There are some roles in a large cyber team that are worth knowing about:
So you want to be a 1337 h4x0r?
What did I not teach you (probably because I suck at it):
Had a blast, hope you got a lot of value.