How to Run a Security Workshop for Developers.
GDS (i.e. government digital services) gave an interesting talk about running a security workshop. Provided as a reaction to a very poor and sexist externally source workspace.
People tend not to learn from history so this is a means of giving them experience.
This was another example of being empowered to cause a change in culture.
Security errors using actual source from the organisation… Including the development environment generally used, and past examples from the code base.
Collaboration based exercises, rather than competition.
Instructions and help for tech set up sent out well in advance
Setup local network set up on a Raspberry Pi – to provide servers and a sandbox while hacking.
Short retrospective at time for feedback
Several people had run similar workshops since – which has to be a ringing endorsement. I’d happily run or attend one of these. There is a lot of work required though.
The Handling Secrets Breakout…
This is an area of weakness for many organisations. Wow! you should hear some of the stories. Even the confident and competent people live in fear of being caught out by bad actors within their organisation. As usual, the assumption of your network being penetrated and limiting damage is the order of the day.
Watch Out for the Weakest Links with the Biggest Payoff
- Credentials for cloud services
- Data access – database connection credentials an infamous problem– “In SQL select is the most dangerous command”
- Vulnerable build chains – a way to breach the perimeter of 3rd parties
- 2 factor auth for login, and the importance of protecting logins.
- SSL keys great for ease of use and protecting the perimeter.
- SSH should be unavailable on production micro-service servers. The aim is a blackbox with low attack surface.
- No root login anywhere – for many reasons
- Selinux – argh! I’m not a big fan – a lot to learn for esoteric benefit. Maybe there are some wizards/bots out there these days.
Role based access – the start-up “we have three engineers and they are all devops” people are in a quite different place from the enterprise “over my dead body” school of thought. I think we can all guess which is more “role-based”.
Having said that, many start-up people did have policies and those that didn’t were very interested in how to implement them, because much like “version control be vital in groups, and improve productivity for an indiviual dev” so it is that role based data access is the right thing to do in order to prevent massive mess-ups. GDPR reared it’s ugly head.
Several tools were mentioned…
*The Unix “pass” command seemed to have good support for retaining passwords locally – and has a Mac port and a Windows equivalent. https://www.passwordstore.org/
Some multi user / enterpise options were:
- Secretserver….this was considered by users to be horrible
Regardless, in addition to controlling passwords 2-factor authentication was considered vital. yubikey was the tool of choice for this. Other options include Google.
There was some debate about trusting keys to third parties but this was countered by the observation that email pretty much universally being purchased from 3rd parties e.g. Google and Office 365.
The question as usual led back to the adage “ask not whether you will be compromised; ask what you will do when you are.”
Data Protection – The Gathering Storm
New data protection legislation GDPR – big problems for small operators and a big issue for monolithic systems without traceability already built in.
Datadog and Forest were brought up as monitoring tools for microservices.
Online coding puzzles during learning hour, was suggested as a good way to develop coding skills.