Purplecon 2019 mikala easte, risk management without slowing down, https://purplecon.nz/talks#mikala-easte, https://www.youtube.com/watch?v=2S6acN_QY_Y&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=13&t=0s
most organisations start out relying on people and their expertise when making decisions, but this doesn't scale well and leads to bottlenecks and pain. larger corporates rely on processes, controls and systems, but these can overwhelm smaller companies. i'd like to share some thoughts on how to set up lightweight risk management processes to empower teams to make informed decisions and not just rely on what the security person thinks of it.
- halfassing the job is better than not doing it
- just keep a risk register, write everything in it
- review it – even accepted risks, because the world outside might have changed
- involve multiple people in the risk-setting process
Purplecon 2019 ben dechrai, to identity and beyond!, https://purplecon.nz/talks#ben-dechrai, https://www.youtube.com/watch?v=_5FT5DAMVY4&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=8&t=0s
it's unusual to develop applications that have no identity requirements nowadays. whether it's securing access to resources, synchronising data between devices, or providing a customised experience, any new project will soon need that login form.
while you might start out with a simple login form and a backend user directory, these soon grow into their own beasts, when requirements call for multi-factor authentication, or machine-to-machine authorisation functionality.
these requirements and associated maintenance costs are often at odds with the desire to focus on building new features that actually bring your users value, or fixing bugs that currently bring them pain.
in this talk, you will learn about oauth, openid connect, and json web tokens; where they came from, how they work, and how they can simplify your projects, from single-page apps to the apis that drive them, and everything in between.
- Auth0 – use OpenIDConnect!
- (what about webauthn?)
Purplecon 2019 bl3ep, a novice red teamer's guide to self help, https://purplecon.nz/talks#bl3ep, not streamed
advice and learnings from a newbie's first year: how to get better hacking yourself, hacking others, and defence against the se arts.
- mh – stress? say “I'm excited” and hack your own response system
- mh – visualise the stressful activity in details first, going well
- social engineering attacks are a good exercise for general non-IT staff
- Validate the request. Call back. Don't “reply”. Don't leak PII by being helpful. Use a different channel for validation
Purplecon 2019 james, deploying kubernetes safer(ish), https://purplecon.nz/talks#james, https://www.youtube.com/watch?v=1aBIFsqpBVU&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=12&t=0s
sometimes evil conglomerates, large companies and/or totally regular and normal individuals prefer to run kubernetes themselves, instead of using a public cloud provider – perhaps they don't trust the intergoogles, perhaps they want to experience the incessant joys of maintenance and upgrades themselves, or perhaps (the real reason) they wanted to justify their sweet, sweet devops stickers on their laptop.
sure, not trusting someone else's computer make sense in some threat models, the (sometimes overly-enthusiastic) diy approach does mean they open themselves up to a whole host of other problems – google probably does know how to deploy, manage and secure kubernetes better than anyone else, since they kinda built it. they've probably even got better stickers.
unfortunately, setting it up is hard. there's so many moving parts and the vaguely dodgy how-to posts on random blogs always seem to be a few versions behind – and they feel like they get away with it by saying “definitely probably don't do this in production, but it's totally fine to do for testing, what's the worst that could happen?*”
this talk will take you through some of the parts of the kubernetes setup that are commonly ignored (“oh yeah we’ll definitely $100% get to that later”), or excluded from scripts you piped from curl to bash, or are pretty easy to accidentally get wrong if you didn’t know about this other thing that wasn’t made immediately obvious. if you’re an auditor, these are your super tasty critical severity fairy-bread tickets. if you’re a defender, these are the things that differentiate your totally awesome cluster of orchestrated hotness from a totally awesome cluster of orchestrated hot mess. if you’re an attacker who’s popped a shell and found themselves trapped in a container of emotions, these are the things that make you have a big sad when they’re done right.
- How did you install it? (wget | sudo bash ???)
- localhost api bypasses all auth* checks by default
- Don't let containers talk to your localhost api!
- did you give your container a token to talk to k8s? how is that secure??
- etcd is supposed to be on multiple nodes, if you don't bother it can be DoS'd
- etcd setups rarely use auth* but should
Purplecon 2019 moss, choose your own adventure: password reset, https://purplecon.nz/talks#moss, https://www.youtube.com/watch?v=-gpfKW_8EJw&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=5
you build or are part of a team that has a thing on the web that does stuff for people. and those people would appreciate it if other people couldn't pretend to be them on your website doing their secret squirrel stuff.
so, you decide to have people login in with a password. it'd be mighty nice of you to give people a way to recover their accounts when they misplace their passwords.
password reset flows are a choose your own adventure where the players just want to be able to secret squirrel again, and if you're in charge of one let's learn about some game overs everyone would like to avoid.
- Lifecycle of password reset, from the perspective of the reset token, might reveal new ways to think
- To understand lifecycle, expiry, multiple requests, multiple reuse (especially the corporate email gateway that clicks on all links?), success and failure states.
- But don't let attackers discover your PRNG seed
- May be a good place to use a state machine :–)
Purplecon 2019 anton black, against lies, h*cking lies, https://purplecon.nz/talks#anton-black, https://www.youtube.com/watch?v=3FLwN7OJAjQ&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=8
did you know that the more blue teamers are sent to handle a security incident, the worse that incident will be?
using science and statistics to make decisions about how you run security is a great idea – 𝘪𝘧 you can interpret and represent your data accurately. but statistics is rife with potential pitfalls that can lead you to all kinds of false conclusions.
with some help from planet earth's own blue team, we'll learn how to recognize and work around these problems to not only use your own data for good, but to also catch flawed analyses when you see them around you.
- Identify confounding variables/assumptions
- Observational studies can't identify causes, and “all” infosec studies are observational (therefore incomplete science)
- Interventional studies are too expensive, or ethically questionable
Purplecon 2019 william, banging fists on table state machines state machines, https://purplecon.nz/talks#william, https://www.youtube.com/watch?v=VbtsQjbnNw8&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=3
writing software is hard. really hard. almost impossible one would say. we can see this from . as we all are walking talking fleshy bug emitting machines that sometimes emit good code as a lucky side effect, we need all the help we can get to increase this luck factor.
state machines help us to reason about our programs, how they work, how they wont work, and why they didn't work – and from there, how we can design programs to never fail at all. there are state machines all around us. let me show you how we can use them in code for security and robustness.
area and assumed knowledge:
area – secure software development.
assumptions – some programming knowledge, but demos will be in rust and c. i will not use advanced or tricky code for any demo to make it as accessible as possible.
- Not being a developer, I didn't get as much from this as others would have done.
- But I'm familiar with state machines as descriptions of systems, the biggest example being the TCP/IP example (https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
- They require some rigor, which is in general a good thing!
- They help you look at a problem from different perspectives
- They're part of “document first, then code to the specification” rather than “open an editor and start hacking” iterative/explorational coding
Purplecon 2019, shahn harris, embracing empathy, https://purplecon.nz/talks/#shahn-harris, https://www.youtube.com/watch?v=bvB8nEVka80&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=2
empathy is a personality trait which is not often discussed in the world of infosec. in an industry with highly authoritative technical personalities, curious technical explorers and fully transparent decision makers empathy is the odd one out, why care about what other people think or feel when you have the mandate to enforce policy/solutions/architecture/technology as you have funding and “because security”.
in this talk i will take you through how in my now near 20-year career predominately in the enterprise space i have tried to be anything but empathetic, the feeling of impostor syndrome i carried around for years as the way i worked and achieved results was not covered by any conference talks/certs/training/industry groups. and how through necessity i went from realizing that while my approach to infosec had always been classed as “pragmatic” it was empathetic. and that empathy worked wonders in the most trying time of my career.
- mh
- Defeating impostor syndrome by accepting being a different “type” from others
- Perhaps the black hoodie death metal flames security image is harmful to more than just conferences?
- 'Enterprise' personality profiling might not be “correct” (many of them are wildly inaccurate) but sometimes just being reminded that people are allowed to be different is importent
Purplecon 2019 sera, iam confused: a deep dive into how permissions work, https://purplecon.nz/talks/#sera, https://www.youtube.com/watch?v=t0wkQinlRso&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=4
one of the hardest things to understand in the world of cloud computing has to be iam – what is a role? what is a policy? how do i keep my engineers away from production systems? how do? the aim of this talk is to try and give some practical examples to help security teams understand whats going on, and how to use this to keep their infrastructure running smoothly and safely.
Purplecon 2019 sauramaia, how to human in groups, https://purplecon.nz/talks/#sauramaia, https://www.youtube.com/watch?v=rq6IWQbjdMI&list=PLS45xFo74VF546tbfXXtKDO03cVrAalM6&index=2&t=0s
if you’ve ever tried to convince your high school friends that being racist is kinda terrible, or your work friends that they should use a password manager, this talk is for you.
changing people’s minds is hard. each group has its own version of what’s normal. this talk is about how to work with the brain tools we’ve got to make the computer tools we want.
- Change causes conflict and can hurt feelings
- Security boundaries probably represent change ...
- Join a group (perhaps via an advocate), consider the Overton Window of ideas, and using no negative language “should no must you etc” present your reasons