Author: Mikail

I’m often asked by students and those thinking about a move into cyber security: “How do I break into the field?“

My answer hasn’t really changed over the years, but I get asked often enough that I figured it’s worth putting into a quick* blog post. I’ll give you a sense of how I think about hiring, what I look for, and hopefully give you something more useful than some of the generic, unhelpful advice out there.

Just to be super clear – everything here is 100% my personal opinion. This is what I look for when hiring for my own teams, regardless of seniority.

This post is focused on the technical side of cyber security – engineering, architecture, offensive security, defensive security. I think it’s a good foundation, even if you eventually end up specialising in a less technical field like governance, risk, or compliance.

* turns out this wasn’t the “quick post” I thought it would be – it took me three weekends in a coffee shop to get this finished 🙃

Over the past year or so, I’ve come across the occasional remark or comment about InfoSec teams and phishing simulations; typically how they’re run extremely poorly.

Most recently I came across this thread on Twitter and thought I would share my thoughts on phishing simulations and the effectiveness of them; based on my own experiences and understanding. My opinions could change as more data becomes available on the topic.

A mouthful of a title but in this blog, I’ll try to answer this question based on my own understanding and experiences deploying WebAuthn.

Firstly, if you don’t know what Web Authentication is (commonly referred to as WebAuthn), it might be worth having a quick read of my previous blog post as the WebAuthn standard is the foundational building block for passkeys.

In this post, I will be going through some of the essential Branch Protection Rules you should have on all* of your GitHub repositories. GitHub is constantly releasing new updates all the time but my recommendations stand as of January 2022.

I’ve also added some gotchas I’ve tripped over discovered whilst deploying such rules across nearly a thousand repositories.

*Assuming we’re talking about corporate GitHub organisations… and by all, I mean ALL. Branch protection Rules should be the rule, not the exception. Have exceptions if you need them (you will!) but otherwise apply it everywhere.