An incident is an event that is not part of the standard operation of a service and that causes an interruption or a reduction of service.
In simpler words, an incident is an unplanned interruption of service.

Contents of a post-incident report
(The post-incident report alternative names: incident report, postmortem report)

• Timeline: what exactly happened and at what times?
• Metrics: how well did we react?  (time to detect, time to react, time to close)
• Procedures: were they adequate? were they being followed?
• Root cause analysis: is the root cause understood?
• Lessons learned: what corrective actions can we take?

Tip: If the incident caused financial loss, attach the current and potential security controls to the timeline. Which controls limited the loss, and which controls could be acquired in the future? Also, it’s a good idea to calculate potential losses if the existing controls would not have intervened. This will help establish the overall return of security investment (ROSI).

Why a post-incident report?

1. To understand and address the root causes
2. To build lessons learned
3. To maintain an accurate archive of past incidents

Case study: How Google is learning from failure
https://landing.google.com/sre/book/chapters/postmortem-culture.html

A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring.
When to create one? Interruption of service, data loss, monitoring failure, etc.
3 best practices: avoid blame, keep it constructive, collaborate and share.

For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior. A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had.

The blameless culture

When I come across charts like this, this or this, my reaction is to point to obvious: that the information is unreadable by 1 in 12 men and in 1 in 200 women. Being one of them certainly helps to see the problem 🙂
Pointing it out is certainly good for raising awareness, but it’s not enough. Driving change is what ultimately matters. And the good news is, in most cases the change is really easy. So easy that I can resume it to two action points:

1. Don’t use color alone to convey meaning. Use icons, written content, and other visual elements to reinforce clear communication of the content.

https://accessibility.digital.gov/visual-design/color-and-contrast/

2. Make sure there’s sufficient contrast between graph colors so people with color blindness can distinguish the colors.

https://accessibility.digital.gov/visual-design/data-visualizations/

That’s it! Seriously. Add some symbols to your chart bars and pick a colorblind-friendly palette. Implementing the two points above will make your data visualization efforts more inclusive. If you want to go the extra mile and show some empathy, then

Test what it’s like to view your designs through a color blindness simulator

https://accessibility.digital.gov/visual-design/color-and-contrast/

The take away here is that “Designing for accessibility is not that hard“. As in the case of football, “This is not rocket science. It’s really about easy fixes“:

"This is not rocket science. It's really about easy fixes"
Great to see the @FA taking steps to a more inclusive game #ColourBlindAwarenessDay https://t.co/1IPshVjAMd

— Dorin Moise (@dorinmoise) September 6, 2018

Some notes following the Enterprise Cyber Security Europe event, 19 September 2018, Amsterdam.

• @ThomLangford: When trying to hire, look for passion. Technical skills can be taught later on. Also, look for the people who care about what they do, who are full of energy, who are constantly pushing their limits and who are filled with passion. 

• Humans are indeed the weakest link in any security system, because brains are hard to upgrade and because emotional manipulation is easy. 
• So how do you deal with the human risk? 3 possible avenues:
  • throw technology at it
  • improve your internal processes (ex: out of band validation)
  • or develop a continuous and adaptive security awareness program, where people at Terranova seem to know what they are doing. 
• Awareness is for everybody, training is for similar groups of people (ex. a department), education is for the ones who genuinely want to learn
• The story of the women codebreakers at Bletchley Park is fascinating
• Total cyber crime revenues: in the region of $1.5 trillion annually
• Time to detect a data breach: between 99 and 197 days depending on who you ask. Either way, it feels like an eternity
• You can actually turn a data breach into a positive development for your organisation if you manage to be humble, transparent and willing to improve things
• Booking.com is having an interesting ‘everything is a test‘ culture (over 1000 experiments going live at any given time). The company brands itself as a ‘developer-first enterprise’. You must make an effort to find a compromise solution between security and usability
• Preparing for the GDPR should have been easy as long as you have a user-oriented mindset. Don’t forget about the tools for user data export and user data deletion.