The Security In Five podcast is a little over a year old and I want to expand it and throw in some more fun, unique episodes. In the spirit of educating and making every more more aware of security topics, I now want to hear stories from the trenches from you. Security Horror stories are what it’s all about.
Everyone in security has a story like this. A story you won’t talk about, can’t talk about, shouldn’t talk about but you want to. Stories that shows the reality behind the scenes in the security world. Insights to the thought processes of ridiculous managerial decisions, technical failures, implementations gone wrong, breaches that were swept under the rug or how much access to live data people have within a company.
You can submit these stories to me and if they are good enough and if I can build a ‘teaching moment’ from them I will use them in a one-off, fun episode.
These stories are going to be deep, dark and potentially have consequences if they are talked about. That’s why I will have rules to submitting them and rules to you for reading them. They are quite simple and it comes down to anonymity for everyone.
How to submit a horror story –
- Email the story to my ProtonMail account – bblogger@protonmail.com, which is secure and private. Stories sent to other email addresses I have will be ignored. Try to send from an email address that doesn’t identify you, if you do I will ignore it but I’d prefer you didn’t.
- No names. Any names in your stories I will change, even if you say they are random. No company names. No cities or location. Nothing identifiable.
- Say what industry and general company size to give context.
- Be detailed and have fun.
The main rule. No matter what details are in submissions, I will not reveal names or companies or when they happened. These are meant to show reality and relate them back to how not to have them happen to your programs or companies.
Some examples of some stories:
- A plan that almost happened to send the entire corporate AD users and passwords as a nightly feed to a 3rd party incase the Federation failed for one application.
- The decision not to use LDAPs or any SSL/TLS internally because the secure transmission caused too much overhead, 2,000+ databases in the datacenter.
- Finding a major security bug that caused account swapping, reported by a user that did it, and not reporting it or alerting customers then destroying all communications about it when it was fixed.
Things like that.
There are more reasons that technical failures and vulnerabilities to why companies get breached. Let’s hear those stories.
What are your horror stories?
Be aware, be safe.
End of line.
