Best Practice

Back to list of all Outcomes

Timebox your exercises

When giving students a (hacking) exercise make sure they know the time allowed. At the end of the timebox, show the solution to the exercise live on the video projector so everyone sees it at least once.

Explain actual risks

Security issues cannot be considered in isolation so you should be able to measure their value/risk over, for example, functional changes or other requirements. Developers need to learn how to balance all these requirements appropriately.

Include corporate coding standards

Use code examples from, or aligned with, the company’s (secure) coding standards to show insecure code and how to fix it during a developer training.

Have an icebreaker

Have a gimmick - something novel for the participants - for example, breaking a physical safe or picking a lock.

Learn the whole lifecycle

learn the whole lifecycle: sandbox examples, discover the vulnerability, use the exploit to gain access and then issue a fix.

Red Team + Blue Team = Purple Team

Make sure attacker and defender perspectives are covered; don’t limit your training to fixing vulnerabilities.

Provide context

Give an overview of the training/exercise application used so the students have sufficient background information for their own trial attacks.

Internal security meetUp

Use a format similar to after-work Meetup where a mentor (e.g., Security Champion) goes through one topic per session. A monthly schedule should be maintained to keep up the community aspect of this format.

See for a proposal setup of such a MeetUp.

Back to list of all Outcomes

Edit this page here