AskAppSec - BSides Munich 2023

When I started out my AskAppSec challenge, I've asked around for recommendations on communities and conferences in the security space. Jay Harris encouraged me to look for a local BSides event as in his experience these were usually friendly, welcoming and a great opportunity to network. Now that I've attended my first one with BSides Munich, I can only confirm that impression! Just loved it.

Workshop Day

The advantage of local events is that no travel is required. The downside, however, that you have to commute to get there in the first place. This turned out quite tedious with public transport and its quirks, construction works, emergencies, and so on. Additionally, getting up very early compared to my usual working days meant I was already tired on arrival. And I was nervous! As with any new conference I'm at, I never know what awaits me and how I'll deal with that. It got better over time as I've been to tons of conferences. And yet, the anxious excitement keeps coming back, especially if I don't know anyone from the community yet who could offer a safe space. This time I got lucky as Claudius Link was coming. We met at SoCraTes, even gave sessions together this year, and we've just started planning an initiative for next year (stay tuned). In any case, it's really helpful to have a familiar face in the crowd!

On arriving, registration was smooth without any hassle, organizers and volunteers friendly and helpful, and I was positively surprised about the welcoming breakfast offered. In general, food was excellent and plenty throughout the day, including a variety to choose from for people having different needs and preferences. This makes an event already more inclusive and it's a detail I do pay attention to in order to gauge the overall spirit and atmosphere.

This first day was dedicated to workshops only. I noticed how few people were around. The workshop tickets were gone very quickly, yet there was lots of space. Super sad to see, especially considering the whole event being free. People reserving tickets yet not showing up meant they took away the opportunity from others who would have participated. Kudos to organizers who reminded folks frequently upfront to kindly give tickets back when realizing they couldn't come.

There were plenty of workshops to choose from, covering lots of interesting topics. For me, Claudia Ully's full-day workshop "The Hitchhacker's Guide to the Mobile Galaxy" was a clear winner as I want to dive deeper into mobile security and I can use the gained knowledge at work. I was not disappointed at all, this workshop was amazing! I loved how smooth the setup was, especially given that mobile has lots of requirements. It was awesome that while there is quite some theory needed to get everybody on a shared page to start from, the focus was on hands-on exercises. Claudia encouraged us to join forces, help each other and ask questions, which really made this a safe space to learn. The content was structured in a way that made it very accessible for people not having experience in the mobile space yet, while also providing lots of technical details valuable for people who came with prior knowledge. We went from mobile history and basics to Android specifics, static analysis, reverse engineering, to a discourse on iOS, to hooking into things with Frida and objection. And all that in the theme of Douglas Adam's "The Hitchhiker's Guide to the Galaxy"! Claudia even had a "42 - Don't Panic" towel with her, how cool is that? If you ever have the chance to catch one of her workshops, do it - fully recommended.

After such a full day of learning, I was pretty tired - and yet didn't want to miss the chance of socializing. Hence, I joined Claudius and a friend of his for drinks to conclude the day in great company.

Conference Day

The second day came, the main part of the conference with a program full of talks. And a whole lot more people! Same here, registration was quick, organization smooth, food was plenty and the venue a great choice, too. Lots of friendly and helpful organizers and volunteers around, and amazing speakers with a variety of topics to learn from.

The program consisted of two tracks which presented a difficult choice. Here's an overview of the talks I've picked.

• Keynote "The Seven Sins. And Virtues. Of IT Security. And how they affect our world." by Mario Heiderich. The conference theme was all around the 7 SYNs. What would the seven sins look like in cybersecurity, and what about the seven virtues? Mario's conclusion resonated with me: we cannot jump to the ideal state, yet we can take small steps and continue to learn.
  
• "(In)direct Syscalls: A journey from high to low" by Daniel Feichter. This talk dove right into the technicalities of Windows system calls and how red teamers can make use of them to bypass system controls. Packed full of details for a complex topic, this talk could only scratch the surface given the limited time. Daniel encouraged everyone to try it out and consume further material on the topic.
  
• "SOC Analyst’s Arsenal: Essential Tools, Tips and Tricks for Effective Investigations" by Samuel Kavaler. A talk full of hands-on advice and tool recommendations for the everyday work of a SOC Analyst. For people in different roles like me, it's been also interesting to learn which kinds of tools are used and for what reasons.
  
• "Bio-Lock The future and ethics around DNA Cryptography" by Tayla Sellschop. Cryptography is a whole topic in itself, yet what if we bring DNA into play? It offers a large storage space, while also not requiring as much computing power and hence power consumption, so it could become a sustainable solution in the future. On the other hand, there are a bunch of problems attached to using your own personal DNA - how would we feel about data breaches then? Yet as Tayla demonstrated, our DNA is already everywhere!
  
• "Secure containers - Do component reduction strategies fix your container security nightmares?" by Michael Wager and Michael Helwig. Really interesting overview of how we could tackle container security by using "distroless" images, only containing the application and its runtime dependencies without any other operating system programs. They are a lot more secure and less open to vulnerabilities, so why not make them the new default? At the same time, they also have disadvantages that might make them less attractive in their current state. Interesting topic to look into further.
  
• "Christmas Hancitor Campaign" by Artem Artemov. Loved this talk showcasing how proactive identification of threat actors and their victims can help prevent impact. Great storytelling of the investigation of a curious case and the actions taken to reveal more information until the puzzle pieces finally fell into their places and harm could be prevented. Incident response does not always have to happen in hindsight, it can start way earlier!
  
• "What We’ve Learned from Exposing Atlassian on the Internet: In-Depth Analysis from an Offensive Perspective" by Oleksandr Kazymyrov. A great story of "what would happen if..." and what you can learn from it to improve a system. Relevant for everyone having services publicly exposed to the internet behind SSO. Loved the testing mindset of always going a step further to identify what else can be accessed publicly and misused in an impactful way.
  
• "DevSecOps culture" by Ali Yazdani. This talk resonated a lot with me, from misconceptions shared to the cultural mindset shift required - I've seen this over and over again when working in testing and quality! Especially loved the emphasis on easing clear communication across roles as well as solving a problem together hands-on, no matter your role.
  
• "My CI/CD pipeline contains all security tools available! Now what...?" by Jasmin Mair. Another awesome talk where I just kept nodding! How many times have I heard some variation of "let's add some more tools" to solve a problem or satisfy a demand. Yet without the respective culture change nothing is solved just by having more tools. People need to learn the tooling, understand findings and figure out how to work towards a better outcome. Jasmin encouraged everyone to see it from a developer's perspective, being overwhelmed with hundreds of tools, each with their own interface and quirks, with every tool adding complexity and pain points. She made clear that proper tool evaluation and adoption is an investment and will take time, yet it's worth it.
  
• Keynote "Security by design" by Ana Oprea. The closing keynote draw a full circle to the opening one, also referring to the conference theme of 7 SYNS and how we can foster the virtues. Ana drew a connection between security and reliability and how designing for one of those aspects can help the other one and vice versa. I also liked that Ana emphasized risk assessment considerations and recommended techniques like threat modelling. She reminded us that people won't always realize they are a target or underestimate adversaries and their driving motivations.
  

By the way, slides can already be found on the website, and talk recordings will be published soon.

As I was taking sketchnotes, my biggest challenge was to switch rooms as there were often no breaks scheduled in between talks. It somehow worked out yet was more stressful than I hoped for, and it was strange to leave during questions, missing the answers. On the other hand, the breaks that had been scheduled worked out nicely. The program offered quick ones sufficient for bio breaks, and longer ones to digest what we've heard, refuel with nourishment, and connect with people.

The folks I talked with were really friendly and welcoming. Special thanks to Ben Wandel, Claudius Link, Sebastian Porst and Sergio A. Figueroa for our great lunch table! In general, I didn't notice much condescending behavior or being frowned upon due to aspects like my role or gender. I observed quite some diversity with this regard among the participants. Representation was even higher among the organizer and volunteer group, and it nicely showed in the conference concept and program.

Conclusion

This conference is driven by community and you can feel it. It was organized with care, ran smoothly, people appreciated the offer and seemed to have a good time. All this provided as a free event. Kudos to organizers and volunteers, thanks to sponsors for making this possible! 

I went home with my mind being full of all the things I've learned, my soul with all the new connections I've made, and my heart with the feeling that this is yet another place and community for me to become truly part of and belong to.

This definitely won't be my last BSides Munich and BSides event in general, I'm already looking forward to future ones. So, my first security conference was awesome - what are your recommendations for the next?

---

UPDATE: Fahri Korkmaz also wrote a blog post about BSides Munich. He shared lots of notes of talks I didn't attend, plus a lot more details on talks I did. Really worth checking it out and diving in deeper!

AskAppSec - Security Champions

The first time I heard about security champions programs was from Tanya Janca and the idea stuck with me ever since. If you haven't come across this concept yet, here are a few good resources on it.

• Building Security Champions by Tanya Janca
• Security Champions (OWASP)
• Security champions series by Snyk
• The Security Champion Framework by Chris Romeo, Izar Tarandach and Brook Schoenfield
• The Security Champions Podcast: Tanya Janca - A Recipe for Security Champions

For the first time, I'm in a company that not only has established a security champions program, it's also the first time I became a champion myself! Therefore, the topic grew even more relevant for me in the past months.

Recently, I came across several rather negative, or let's say frustrated viewpoints on security champions programs. People I met said it just never worked for them. Some shared they were not having real organizational buy-in and the program was merely a point on a checklist to tick off for the company to look good. Chris Romeo shared lots of security champion antipatterns in his Reasonable AppSec newsletter that made me think. "Why Security Champions Are Not the Silver Bullet" by Matthias Rohr is another thought-provoking piece pointing out that other initiatives might work better in certain contexts. What I don't hear much about in my bubble, though, are success stories from security champions programs. I do remember one person at Booster Conf talking about their program that managed to raise awareness and spread knowledge. Yet that's... basically it.

It's my first experience with such a program and I only see its current state after having run for quite some time. Therefore, I can't really tell how effective our program is and if it improved the situation compared to the one beforehand. From what I've observed, it does indeed seem to work quite well so far. It did manage to bring people together and scale the efforts of our InfoSec folks through having invested volunteers as contact persons and security advocates in each product development team, hence building bridges. There's clear guidance for lots of security topics and good practices. In the teams we have on demand support and feedback from InfoSec at any point from idea to production. At least from my personal perspective, collaboration works really well. We have buy-in and time set aside for security topics and can actively help drive security efforts for our products and the company. Huge shout-out to our awesome InfoSec folks at this point!

That being said, we recently also talked about how our program can be evolved. The conversation was initiated by an InfoSec person sharing Snyk's Security Champion Playbook and asking people for improvement ideas we could try. I did share my personal point of view of what I'm missing or what would help me benefit from the program even more. We're all working remotely and as of now asynchronously as security champions. It's not a secret how much I am a fan of synchronous collaboration, so that's what I would wish for more. Be it in the sense of regular calls with champions and InfoSec, or frequent pairing and ensembling sessions to work hands-on together. This could be on specific learning topics, general fun challenges like Capture the Flag (CTFs) sessions, on our regular security related tasks, or on solving current challenges in the teams - together. Joining the regular InfoSec call where folks exchange current news would be a great addition as well. 

We haven't decided yet what exactly to try out next. I'm curious what other ideas people have, what worked for them best so far and what not at all. More real experiences that we can all draw inspiration from. So, let me ask you: what makes security champions programs effective?

AskAppSec - Painless Usable Security

Imagine security being painless, easily usable and just the usual way we do things. Imagine this for both those who develop products and those who use these products. Wouldn't that be amazing? My optimism tells me it's possible, and yet we're often far from it.

In one way or another, I kept thinking about this for the last months. At SoCraTes and FroGS conf, I've facilitated sessions on the topic. We gathered lots of insights together with participants, hearing what struggles they faced and what opportunities they found. What we can do to change the narrative. Many thanks to everyone who contributed! Here are the points that came up repeatedly when asked what's painful.

• Fear. It's scary to ask questions, especially about security. Security teams (if you even have them) might be very detached from teams' everyday realities and not approachable, might even be condescending, or just wave around a policy without being helpful. There's a lot of secrecy and gatekeeping going on as well. And what if we make a mistake and people blame us? What if I see something yet have every incentive encouraging me to look the other way instead of reporting it?
• Fatigue. So many alerts, we're overwhelmed already. So many false positives reported by tools, which makes it even easier to ignore yet another scanner result and just bypass it so we can move forward, as we're pressured to do. Security theater is huge at play here as well, everyone talking how important security is without ever seeing real actions taken. Why not just tick those boxes in the easiest way so we can say we comply without actually fulfilling the spirit behind regulations.
• Future. Well, security is indeed a future problem, isn't it? Yeah, that risk exists, yet will it really ever happen? We'll rather cross the bridge when we come to it. We have so many other things to do after all. And as we can't invest in prevention now, let's put security last by default. Hence, we can ignore issues we see, as no real pain is perceived - until suddenly the pain is super high.
• Friction. I know this is the more secure way, yet I have to jump through ten hoops, get approval from hundred people and then sign this contract with my blood - or... I just do this one-liner change. Procedural problems are real. Poor experience is real. Difficult cross-team collaboration and dependencies are real. And they have very real impact on behavior. If something is way too much effort for what it's worth, we're usually not going this extra mile (or at least aren't rewarded for it).
• Futility. Security is just such a huge area, security work is never finished, we'll never know everything. The system is so complex. We lack knowledge and we have so much else to know already. We struggle to see the actual impact of vulnerabilities anyways. We can only know the system is insecure, not the other way around. All this feels really futile, so why invest at all.

This list resonates with me a lot, and I see these points in my own work context as well. Especially when there's a whole backlog of things that we know we need to improve, yet struggle with balancing competing priorities. Fatigue is a real challenge indeed, like fatigue of pointing out problems and proposing solutions that just don't cut the list of most valuable things to do right now.

I've also talked with several people in the communities I'm in, where security was sometimes perceived as painful due to other reasons. Like, why is security the only quality aspect that is considered and gets buy-in, what about all the other ways in which we can harm our users, our own people, our product and company? Why do we get external experts for security yet not for other topics (like accessibility)? Why do security policies just always make things harder? What is it that security slows us down while not achieving actually more secure outcomes?

Finally, there's the angle from friends and family not working in tech. Security? Well, that's often perceived as the thing that annoys you, that you skip. Oh my, another update, why do people have to change things all the time. Oh no, another factor to log in, why does everybody need to do this nowadays. My goodness, another popup to click away so I can do my job and go on with my life. I heard a lot of statements like this, usually accompanied with frustration and anger. Or with shrugging things off. I don't care if they have my data, what would they do with it anyways. Yeah, I know this company has proven to do bad things and yet they offer the best usable solution compared to more secure competitors.

So how can we reduce the pain and friction, increase usability and make security the easy route to take? In all my conversations, the following points came up repeatedly.

• Ease development experience. Anything that makes security easier and reduces friction and cognitive load from the start can help. Include thinking exercises like having evil personas you could use for user stories, and doing threat modelling to raise awareness before designing and building solutions. Provide good code examples. Have secure defaults, in frameworks, infrastructure, your own product. Keep things in shape and up to date. Enable folks to deliver fast and well, so we can respond fast and well to new threats. Planning for mistakes (that will inevitably happen) and recovery, and foster a culture where postmortems are considered an invaluable learning opportunity.
• Collaborate with security experts early on. No ivory towers, no jargon being thrown around. Instead, security folks being approachable and helpful, enabling team after team, pairing and ensembling hands-on. Security champion programs that actually build bridges and help scale good practices. Do this early on and continuously to make use of the best leverage. Then consider getting external persons to point out problems and receive advice, be it in the form of consultants, audits, bug bounty programs, or coordinated disclosure. 
• Be clear about risks to help prioritization. Not only do we need to assess risks, risks can also have vastly different impact depending on our specific context. Terrible consequences in one might be reasonably ignorable in another context. Learning what's most relevant in yours, and probing the risk appetite of the organization helps figure out priorities.

One thing that stuck with me is what both security and UX folks repeat over and over: security that's not usable is not security. Just as Jared Spool points out, "If it’s not usable, it’s not secure." Because people simply won't do it or find their way around. They have a task to accomplish, a goal to achieve, a job to do. If security blocks them instead of supports them, it might as well not be there in the first place.

• Insecure & Unintuitive: How We Need to Fix the UX of Security by Jared Spool
• Secure Design Concepts w/ Tanya Janca
• Security and usability: you CAN have it all!
• How good UX leads to great security by Josh Ben-David

The same applies to development teams. If practices leading to more security aren't usable, or don't fit in our everyday lives, they simply won't happen. We have to find ways to make it the easy and frictionless route, anything else is simply not sustainable.

This whole topic reminds me again of testing and quality, as so many things do in security. It's a lot about culture, it's a lot about advocacy and change. In the end it's about people. I'm wondering now: the team transformation tactics I found to help move towards holistic testing and quality, could I try them out for moving towards painless usable security as well? I probably should give it a try. Now that I'm thinking about it, I realize I literally just did apply them the last weeks. And before as well.

Let me give an example. One of our current focus topics is keeping our dependencies up to date. Updating them is one part, yet having a team reliably keep doing so is a whole different story. What I did was building on existing energies; in this case, building on existing practices that already worked for the team. And just last week for the first time it worked out well enough. People felt responsible and updated dependencies on their own without my nudging. It was clear, it was easy, it was part of everyday work. It didn't cause friction. Okay granted, I'll have to observe and evaluate this experiment further, yet on first glance it does look like less friction than before.

When it comes to security improvements for our product, I believe we need to work a lot more and a lot closer with UX folks and product designers. This expertise is invaluable and yet too often underrated. The resources listed above give lots of pointers why.

That leaves me wondering: why not also work together with UX and design to find more painless, usable, secure ways to build more painless, usable, secure solutions? There's a lot more for me to think about and try out.

I'm sure people made their own experience with this intersection of security and usability as well as respective pain points, be it for their team, organization, product or just generally in life. Therefore, let me ask you all: what's your approach to move towards painless, usable security?

---

UPDATE: This post didn't receive much response from the community yet. Really appreciated this person taking the time to share their thoughts and experiences!