I finally got around to some focused self-study and completed a https://stackskills.com course for the Security+ certification preparation. The tl;dr is that it’s all pretty introductory/high-level subject matter, but still useful for getting into that headspace. Peep my notes here if you’re so inclined https://github.com/rpavlov/security-plus-notes
Recently my partner’s website was defaced, in that it was serving new, different content at the old url. It is a simple static site hosted on github, which made the severity of this exploit initially puzzling. How could this happen? The site accepts no input and the DNS settings looked normal.
Luckily, this was one of those easily searchable and already known issues with Github pages. The short of it is, if you don’t have a CNAME file at the root of your project and someone else beats you to it, they can claim your custom domain and Github will happily serve their index.html instead! Other providers often require you to have a TXT record in your DNS records, but GH does not require proof of owernship in order to set a custom domain in the repository settings. The final take-away is you can’t trust even the big players to make sound technical decisions.
Here’s a great and even more detailed breakdown.
It turns out habitual blogging is difficult, but persistence is it’s own reward. Time to reflect on 2018 and then think about where to steer the ship, or pull the elephant if you prefer animal metaphors.
I opted to continue client work after getting the opportunity to build/manage the cloud infrastructure and development processes for a couple of companies. It leveled up large chunks of my knowledge, and allowed me to learn tons about DNS, network configuration, security, secrets management and a myriad of other sysadmin related things. In addition to the usual troubleshoot this and fix that of regular software development.
My previous career goal set around this time last year was to gain dev-ops and sysadmin experience in order to transition into more security oriented work and projects.
Back to security study
How me, a programmer, learn security?? Turns out I’m not the only one to have this idea. Here’s another classic. To that end, I’ve resumed self-study and practice according to a vague curriculum I’m putting together. More on that in another blog post.
This year I managed to:
- Nurture closer relationships with people I care about, respect and admire.
- Move to Berlin. Living elsewhere is incredibly refreshing.
- Live minimalist. I reconsidered what stuff I actually need. But also, which luxuries brings me joy? A good soundsystem + music, easy access to a gym, and a nice kitchen for example. Regardless of where in the world I am, if there is a place to lift heavy things nearby that’s already a huge quality of life improvement.
- Work out a lot, and start Muay Thai and BJJ training.
- Re-learn german. Going forward hoffentlich mehr auf Deutsch.
I’ve been meaning to get into the process of taking notes while reading books. Lets start with Nonviolent Communication by Marshall Rosenberg.
All communication must be grounded in a state of compassion towards the other person.
Four tenents of Nonviolent communication
- Observe: I observe the situation or concrete actions.
- Feeling: how the above observation makes me feel.
- Needs: what needs/values/desires of ours are connected to the feelings we have identified.
- Request: the concrete actions we request from the other person in order to enrich our lives.
Alienating types of communication
- Moralistic judgements (blame, insults, put-downs, labels, criticisms, comparisons)
- If my partner wants more affection than I’m giving her, she is “needy and dependent.” But if I want more affection than she is giving me, then she is “aloof and insensitive.”
- Denial of responsibility. We deny responsibility for our actions when we attribute their
- Our condition, diagnosis, personal or psychological history ( I drink because I am an alcoholic).
- The actions of others. This is important in order to not come across as accusatory.
- The dictates of authority.
- Demands. You can never make a person do anything.
Separate observation from evaluation
- When we combine observation with evaluation, people are apt to hear criticism.
- Keep evaluations at bay: “John is angry” is an evaluation, “John shouted, pounded the table, etc…” is an observation. Furthermore, he could in fact be hurt, scared or anxious.
Identify and express your own feelings
- But also, distinguish between feelings and thoughts. “I feel inadequate as a guitar player” is an assessment, instead of “I feel impatient/disappointed/frustrated as a guitar player” which are feelings.
- Use words that refer to specific emotions, rather than something more general. “I feel good” could mean excited, mellow, etc..
- Distinguish between how you feel and how you think others are reacting to behaving towards you. “I feel misunderstood” instead actually been anxious or annoyed.
- Connect your feelings with your needs. I feel _____ because I ____ : “I’m disappointed because I was hoping to see you.”
- Judgements of others are alienated expressions of our own unment needs. Futhermore, expressing our needs we have a better chance of having them met.
Handling a negative message
You have four option when hearing something negative: “You’re really self-centered and a trash-person”
- Take it personally, and accept others’ judgement.
- Blame others. “Actually, you’re the one who’s self centered”
- Sense your own feelings and needs.
- Sense others’ feelings and needs (the best choice).
Common responses that prevent empathic listening include advising, one-upping, educating, consoling, story-telling, shutting down, sympathizing, interrogating, explaining and correcting. Intellectual understanding blocks empathy. Simply be wholly present. Listen and attempt to understand what unmet needs people are expressing.
For the past several months I’ve been pursuing a self-directed education in information security and immersing myself in a wealth of amazing topics. It’s an incredibly broad field, and daunting in its complexity but then what isn’t. I figured writing about it would solidify some concepts and organize my thoughts.
My time is currently mostly devoted to reading while I collect tools and provision a sandbox. I settled on this amazing free course from the University of Helsinki for a more structured approach https://cybersecuritybase.github.io/
The way I use, write and reason about code has changed significantly. This paper categorizes software flaws into two groups
The classic bug. This could be an error throw due to an invalid reference, missing resource or just faulty logic. The list is extensive.
This is where it gets interesting. These flaws are deeper yet all encompassing and include things like error pages leaking information, offloading auth to the client, poor sandboxing and assumption of trust between services or just plain old misconfiguration and leaving things exposed.
Design systems assuming they will eventually be compromised, limit trust and live/die by the principle of least privelege
Don’t mix data and control instructions. Allowing untrusted input data to be executed like any other code leads to injection vulnerabilities and control-flow hijacking.