__INSTRUCTOR_BIO__

JF Provost (Malvik)

Founder and CEO, Malvik Security

Before We Begin

You are about to spend a significant amount of time on this platform. You will build infrastructure from scratch. You will execute real attacks against systems you configured yourself. You will write detections, break them, rewrite them, and test them again. That is not a casual commitment. So before we get into the technical material, you deserve to know who is on the other side of these lessons - and why these courses exists at all.

Write down the following quote on a post-it. and stick it on your monitor or somewhere visible. When training is difficult take a look at that quote again. This should motivate you throughout the course.

"We train like we fight, and we fight like we train"
- U.S. Army General George S. Patton

It is a cornerstone philosophy in military training, emphasizing that training exercises should simulate combat conditions as closely as possible to ensure readiness. Cybersecurity is no different.

Who I Am

My name is JF Provost. I am the founder and CEO of Malvik Security Inc., a Canadian cybersecurity consultancy that specialises in purple team engagements, detection engineering, and hands-on training programs for security teams. You can find me on LinkedIn.

My path into cybersecurity was not a typical one. I spent 11 years in the Canadian Armed Forces as an Aerospace Control Operator, a role where you track aircraft in real time, the team has to make split-second decisions under pressure, and operate in environments where a missed contact, delayed call, or miscommunication can have consequences measured in lives, not tickets. Mission-critical is not a metaphor when you are sitting in a NORAD-integrated operations centre watching radar feeds at 3 AM.

Six Years Teaching Under Pressure

Of those 11 years, six were defined by teaching. In the Canadian Armed Forces, instruction is not a side duty — it is a core operational function. I trained new operators on different type of systems, tactical communications, threat identification, and the standard operating procedures, so they can keep the lights up at 2 AM. I wrote courseware. I ran exercises. I evaluated whether a student was ready to sit live and unsupervised because if they were not ready, the consequences were not a failed exam. They were a missed intercept, or the life of our great country could be at stake.

That experience shaped how I teach today. I do not lecture at you. I build things in front of you, explain every decision, and give you the information you need to build it yourself. When you get stuck, I will tell you exactly where to look. When something breaks, I will show you why because in six years of military instruction, I learned one thing above all else: the student who understands why a procedure exists will adapt when the situation changes. The student who only memorised the steps will freeze.

The Military and Cybersecurity: Similar War, Different Rules

People ask me how military operations relate to cybersecurity. The honest answer is: they are the same discipline in different domains. Both are fundamentally about situational awareness - understanding what is happening in your environment, identifying threats, making decisions under uncertainty, and executing a response before the adversary achieves their objective.

In the military, you operate with radar feeds, intelligence reports, and rules of engagement. In a SOC, you operate with log telemetry, threat intelligence, and detection rules. The mental model is identical: observe, orient, decide, act. The OODA loop was designed for fighter pilots, but it describes exactly what a detection engineer does when a new alert fires.

There is one critical difference.

In the military, operations have a tempo. There are deployments, rotations, stand-down periods. You go to the battlefield, and you come home.

In cybersecurity, the battlefield is 24 hours a day, 7 days a week, 365 days a year. There is no ceasefire. There is no off-season. Adversaries do not observe holidays, weekends, or business hours. The moment you stop watching that is exactly when the most sophisticated attackers move. The MITRE ATT&CK framework documents over 200 techniques, and threat actors are executing them right now, against networks that think they are safe because the compliance audit passed last quarter.

That reality is why detection engineering matters more than any other discipline in cybersecurity. You can build the tallest walls you want. If no one is watching the sensors, the wall is a decoration.

This course teaches you to be the person who watches and who builds the sensors worth watching.

What I Do Today

Malvik Security operates at the intersection of offence and defence. We run bilingual (English and French) consulting and training company, working with organisations that have moved past checkbox security and want to know - with evidence - whether their detections actually work.

That means we do not hand you a 200 pages penetration test report and walk away. We sit with your blue team. We execute techniques from the MITRE ATT&CK framework in real time. We watch together as your SIEM either fires the alert or stays silent. And when it stays silent, that is where the real work begins.

What sets Malvik Security apart from typical consulting firms is that we build practical purple team engagements, collaborative exercises where the red team and the blue team are in the same room, working toward the same goal: measurable improvement in detection coverage. Not a score. Not a pass/fail. A feedback loop that produces detections you can prove work because you tested them against the real technique.

A penetration test tells you what an attacker can do. A purple team engagement tells you what your defenders can see. That distinction is the foundation of everything in this course.

Where I Contribute

Beyond client work, I am an active participant in the Canadian cybersecurity community — not because it looks good on a slide deck, but because this industry gets better when practitioners share what they know openly.

BSides Ottawa — Defender Village Lead. BSides is a community-led cybersecurity conference that brings together professionals, researchers, and students for hands-on workshops, technical talks, and collaborative networking in an accessible, "unconference" atmosphere. I lead the Defender Village at the Ottawa chapter, where blue teamers and even red teamers gather to share techniques, run workshops, and demonstrate real-world defensive capabilities. It is one of the few spaces where defenders get the spotlight.
CIO Association of Canada — Board Member (Ottawa Chapter & CISO Division). I sit on the board of the CIO Association of Canada, contributing to the Ottawa Chapter and the CISO Division. This is where strategic cybersecurity leadership meets policy — the conversations that shape how Canadian organisations approach security at the executive level.
Speaker — SOC Evolution & AI in Security Operations. I speak at industry events on how Security Operations Centres are evolving, how artificial intelligence is changing the analyst workflow, and why the human element remains non-negotiable — even as automation accelerates.

The Centaur Analyst: Where My Research Is Heading

If you follow my work outside this course, you will hear me talk about a concept I call The Centaur Analyst. This is not something we cover in this course, but it is the direction my current research and professional work is heading, and I want you to understand it because it is the future of this industry.

The concept comes from chess. After Deep Blue defeated Garry Kasparov in 1997, something unexpected happened. In “freestyle” chess tournaments - where humans could partner with AI - the winners were not the strongest grandmasters and not the strongest engines. They were average players with disciplined processes for collaborating with their AI partners. They were called centaurs.

I am working to apply that same model to security operations. The future of the SOC is not a fully automated pipeline that replaces analysts. And it is not an analyst drowning in 10,000 alerts with no tooling. It is the Centaur Analyst - a human operator paired with AI copilots that accelerate triage, enrich context, and surface the signal. But the analyst remains accountable for validation, judgment, and the final security decision.

AI can correlate a thousand events in a second. It cannot decide whether the business accepts the risk. That decision belongs to a human — and it always will.

This course builds the foundation that makes the Centaur Analyst possible. You cannot collaborate with an AI copilot on detection triage if you do not understand what a detection is, how telemetry flows from endpoint to SIEM, or what a Kerberoasting attack looks like in raw event logs. The skills you build here, reading Sysmon events, writing detection rules, understanding attacker tradecraft — are exactly the skills that separate an analyst who can leverage AI from one who is replaced by it.

First, you learn the fundamentals. Then, you augment them. That is the order. This course is step one.

Why I Built This Course

I built this course because the training that exists today has a structural problem.

On one side, you have offensive security courses. They teach you to compromise a domain, dump credentials, move laterally, and write a report. Excellent material — but it ends at the perimeter of the attacker. It never asks: did the blue team see it?

On the other side, you have blue team courses. They teach you to configure a SIEM, write correlation rules, and respond to alerts. Also excellent — but the alerts are pre-built, the scenarios are sanitised, and the attacks are described in a textbook instead of executed live.

The gap between those two worlds is where real-world breaches live. It is where the attacker moves laterally for six hours and the SOC never fires an alert. It is where the SIEM has 40 rules and none of them cover credential dumping from LSASS. It is where the detection engineer writes a rule but never tests it against the actual tool the adversary uses.

These course exists to close that gap. Not with theory. Not with slides. With infrastructure you build, and attacks you execute, so you can prove your defense work — or work on it until it does.

How This Course Is Taught

Before you go further, I want to set clear expectations on the teaching style of this course so there are no surprises.

The Tone

I teach the way I brief — direct, structured, and without filler. If a concept is important, I will explain it thoroughly. If it is not relevant to what you are building, I will skip it and tell you why. I do not pad lessons with background theory you will never use. Every sentence in this course exists because it connects to something you will build, attack, or detect.

That means:

I will not hedge. When something is the right approach, I will say so. When there are trade-offs, I will lay out every side and tell you which one I chose for this course and why. You will never read “it depends” without a complete explanation of what it depends on.
I will not sugarcoat. If a tool has limitations, I will tell you. If a technique is difficult, I will tell you that too. If you are about to make a mistake that every student makes, I will warn you before you make it — and explain what happens if you ignore the warning.
I will not assume knowledge I have not taught you. If a concept appears in a lesson, either I explained it in a previous lesson or I am explaining it now. I do not expect you to arrive with a SANS certification. I expect you to arrive willing to do the work. If I missed a point, I expect you to keep me in check and let me know in the lesson's comment or on the Malvik Security Discord. Be reasonable! Building your own methodology to find answers is also very important.
I will show my reasoning. When I make an architectural decision - like placing Kali on the management network instead of a dedicated attacker VLAN - I will explain the arguments behind it. You will never be left wondering “why did we do it that way?”

The Structure

Every lesson follows the same pattern:

Context. What are we doing and why does it matter in a real environment?
Build. Step-by-step instructions to implement it yourself. Everything you need will be included
Verify. How to confirm what you built actually works. Not “trust me, it works” — specific tests you run to prove it.
Connect. How this piece fits into the larger architecture and what it enables in the lessons ahead.

I do not give you a wall of commands to copy-paste without understanding. If you are typing a command, you need to know what every flag does and why it matters. If I ever say “run this,” the next line will explain what it does.

It is very important that you do not blindly copy and paste commands without understanding what it does

The Pace

This course moves at a steady, deliberate pace. I do not rush through configuration to get to the “cool” attack lessons faster, because a misconfigured lab means your detections will not fire and you will not understand why. The lab build lessons in Module 2 are the foundation for everything that follows. Take them seriously. Follow every step. Verify every result.

If you get stuck, do not skip ahead. The lessons are sequential for a reason - each one depends on the one before it. If your Elastic Agent is not sending logs, nothing in the detection modules will work. If your pfSense rules are incorrect, your network segmentation will not behave as expected in the attack lessons.

The Expectation

I expect you to do the work. This is not a course you watch passively. Every lesson has infrastructure to build, commands to run, and results to verify. If you read the lesson without building the lab, you will understand the concepts — but you will not have the muscle memory, the troubleshooting instincts, or the portfolio piece that comes from doing it yourself.

In return, I commit to this: I will not skip steps, leave gaps, or waste your time. Every lesson earns its place in the curriculum. If it is in the course, you need it. If I missed something, I expect you to tell me. We hold each other accountable for our work.

Let's get to work.

Meet Your Instructor

Instructor