Sprint #2: How bad can it be

Welcome back to the second sprint of OneHourAppSec – how did you get on with Sprint 1?

This sprint we build on the foundation we built in sprint 1 and face one of the most confronting parts of securing software – it will probably go wrong.

It’s ok, don’t panic. 

This isn’t a reflection of you or your software, it’s just math. There are many ways that software security can go wrong so statistically, we will all see a security issue at some point.

This sprint we come to terms with this and take the drama out of it by preparing for the (somewhat) inevitable by:

Understanding what we should do if something does go wrong (from a security perspective)

Understanding how to determine how serious an incident is in our context.

There is a lot to do but we will do it in small chunks to make it more manageable. Let’s get into it 👏

Activities

📽️ [VIDEO] Introducing Sprint 2 (5 minutes)

Welcome to sprint two and the world of incident response.


📽️ [VIDEO] What is a Security Incident and why do they matter to software teams? (5 minutes)

We dive into what security incidents are, how they typically work and why they matter to software teams like yours.


📑 Find and review your organizations incident response plan (20 minutes)

Does your organization already have an incident response plan? If so, it's a great time to go find it and have a look.

  • Does it mention software related security incidents?

  • Does it have details of how your software teams would be notified if there was an incident in progress?

While this may not be your document, reading what has been built before helps you understand what support and process is already in place.Remember to add any thoughts, suggestions or findings you have to your Security Debt tracker.

Tip:

If your organization doesn’t have an incident response plan, you can find some easy to follow guidance for creating your own from CERT NZ.


📽️ [VIDEO] How bad is it? How to decide how serious a software security incident is (5 minutes)

Incidents happen all the time but incidents are not all equal. Learn how to decide how serious a security incident is for your organization or context.


📑 Create your own Incident Severity Definitions (25 minutes)

Now that you understand the process, let’s create reusable incident severity definitions for use in your team. We even made you a template to help you get started.


Previous
Previous

Changing the software development industry, one student at a time

Next
Next

Sprint #1: Start where you are