Training, graded by prior knowledge
Three levels, from foundations for everyone to training for SOC analysts. With exercises on our own rigs rather than on slides.
People who already know something need something else
Training that suits everyone suits nobody. A developer needs something other than reception, and a SOC analyst something else again. So our training is graded by prior knowledge, and each level has an aim of its own.
What they have in common: people work. Attacks run on our own rigs, the participants are at the keyboard, and what gets shown can be followed and repeated.
Foundations, for all staff
Half a day to a full day, in groups up to twenty-five, on request as a series across several dates.
IT security for users
The basics and the habits that count day to day: passwords and multi-factor authentication, suspicious mail, handling data and devices, and the question of whom to report a suspicion to.
Recognising social engineering
The forms attacks on people take: mail, telephone, the route through reception. With examples from our own tests and the patterns by which they can be recognised.
IT security for managers
For management and the board: duties under NIS2 and the German BSIG, liability, decisions on the day, and how to tell whether your own organisation is prepared.
Technical, for development and IT operations
One to three days, with exercises on vulnerable applications we provide for the purpose.
Secure coding, foundations
For developers: the weakness classes from the OWASP Web Security Testing Guide on real code, how they arise, how they can be avoided, and how a test finds them.
Secure coding for web and architecture
Building on that, for web development and architecture: authentication and sessions, permission models, interfaces, and the question of which decision in the design prevents later gaps.
Foundations for IT operations
Hardening, permissions, segmentation and logging. With an eye on which configuration stops an attack and which only slows it down.
For security staff
Two to five days, practical, with a lab environment per participant.
Offensive security and penetration testing
The approach, tools and method of a test, from reconnaissance to chaining findings together. For security staff who are to test themselves.
Security monitoring and SIEM
For SOC analysts and security engineers: data sources, normalisation, detection rules and their coverage, dealing with alerts that carry nothing.
Blue team operations
Detection and response in depth: triage, analysis of artefacts, containment, and the feedback from an incident into new detection rules.
Two formats that are not training
A live hacking session demonstrates an attack and explains it, without anyone working themselves. It suits staff meetings and client events and reaches people who would come to no course.
A phishing simulation measures rather than teaches and repeats several times a year. Both complement training; neither replaces it.
How a training course comes about
Half a day to a full day at level 1, one to three days at level 2, two to five days at level 3. In house or remote, in groups that suit the level.
Settle the level and the group
Who is to take part, and what should the group be able to do afterwards. The level follows from that, not from the participants' job titles.
Cut it for your organisation
Examples from your sector and, if a penetration test came first, its findings. Anonymised and with no reference to individuals.
The course
People work. Attacks run on our own rigs, the participants are at the keyboard, and what gets shown can be followed and repeated.
Afterwards
On request a phishing simulation to measure the effect, and a contact for questions from the business. At the technical levels the lab environments stay available for a while.
Common questions about training
Training for all staff on the attacks that aim at people: phishing, calls under a pretext, the route through reception. It matters because those routes go past every technical measure.
The benefit lies less in recognising individual mails than in reporting them. Whoever reports gives the organisation the chance to respond, even when somebody has already clicked.
Passwords and multi-factor authentication, suspicious mail and what marks it out, handling data and devices outside the office, social engineering on the phone and in person, and the question of whom a suspicion gets reported to, and how quickly.
Measurably it shows in the reporting rate of a phishing simulation before and after the training. Organisationally, in checking back becoming the rule where politeness used to prevent it. And as evidence: NIS2 requires training expressly, including for the management.
Foundations once a year, and for new staff when they join. In between, short formats work better than long ones: a phishing simulation each quarter with immediate feedback achieves more than a whole day once a year.
Through the reporting rate and the time to the first report in a simulation, measured before and after. At the technical levels, through an exercise in which we execute attack steps and record what the team notices of them.
Yes, and we recommend it. Examples from your sector and from your own systems work differently from general ones. If a penetration test came first, we use its findings, anonymised and with no reference to individuals.
By making reporting consequence-free. Whoever reports a mistake and gets grief for it does not report the next one. That includes the management taking part in the training themselves, and a reported mail producing a visible response.
Yes. The usual pattern is a phishing simulation afterwards to measure the effect, and a contact for questions from the business. At the technical levels we keep the lab environments available for a while.
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.