Security Workshops

This post is inspired by Dave Ladd's Security Education v. Security Training

My favorite quote is

"We require our SDL training to emphasize the basics of secure design, development and test – then allow employees and their management to select the training that meets the needs of their particular product or service"

Such distinction helps project teams set right security objectives and focus while understanding who responsible for what during  the dev process. For example, biz analyst is required to understand customer's pains with regards to security, project manager is responsible to allocate right resources for security activities, architect is required to take security architecture guidelines into account and may be conduct threat modeling (more on this here Threat Modeling Big Chunks), developer is required to write secure code, etc.

There are many workshops out there, and as I understand Dave's point, workshops of "process" type are educational and workshops of "how-to" type are trainings. For example "Security Development Lifecycle workshop" would be educational and "Threat Modeling workshop" should be a training type.

I've conducted Security Development Session In The UK recently. Actually there were 3 sessions (described in more details in the post). They were all educational - each session included focused set of follow up materials targeted to proper audience. My intention was to help each audience to understand "what is in it for me" during the session, once understood it is easier to decided which path to go to  acquire more skills.

Comments (2)

  1. alik levin's says:

    Lifecycle and prioritization seem like a key to successful implementation of Security Engineering. Why

  2. alik levin's says:

    I just finished building another security workshop that covers authentication and identity technologies

Skip to main content