Human Buffer Overflow: How To Deal With Cognitive Load In High-Performing Teams - Juliane Reimann

Thanks for the introduction. That was very nice. Yeah. Um, by the way, tonight is the next stuntish in the cafe. I'm Ysef Plats. So, if you don't have any plans, you can just go there. Um, yeah. Thanks a lot for coming to my talk about the human buffer overflow. I'm very happy to have the opportunity here to talk about that topic because it's something that I think about a lot. You already heard about what I do professionally. So, I want to share something with you about my early private life. I don't know about you, but as a kid and as a young adult, I spent more hours than I'd like to admit playing strategy games like Settlers of Katan,

Civilization, Sims. Did anyone of you also play that? Are you familiar with that? Very good. So, you maybe can relate. with what I say. So, I loved building those uh nice little worlds for the tiny persons on my screen. Um, it was really nice at first, but very quickly my nice playground turned into a mess. So, and no matter how hard I tried, and maybe I was not very good at it, that's also possible. There was never a perfect balance between people, resources, money happiness. And so one moment I was was flushed with resources and then suddenly my settlers were starving because I didn't build another farm. I was too busy to build a cathedral to reach some other level. So

yeah, it was really not so easy to keep a good balance and not only with the village I built or the house I maintained, but also from time to time there were external factors like my neighbors doing an invasion. So I had my army that I had to get into a position to defend what I built. It felt like how we Germans say fluin which translates to herd a sack full of fleas or as I learned you can also say hurting cats which seems seems to be impossible. So it was constantly reacting never quite catching up everything moving in all directions at once. And sure in a game like that that tension is part of the fun. It's a

challenge that you accept. But when the same feeling shows up in your work, then that's not not a good feeling. And that's exactly how it can feel like being a software developer today or also a security engineer. So between writing clean code, shipping fast, staying up to date, learning new tools, collaborating across teams and also making sure that everything is secure, the teams and their brains can get overloaded and that is what this talk is about. So what happens when people like systems overflow when security tasks add to the load and yeah the question is how we can how can we design better processes that don't break the human buffer. So in this talk I want to tell you about the

cognitive load theory. I want to talk about how security adds to the cognitive load that to the already existing load that security uh the software development teams have and I want to show you some examples for addressing the additional load that security creates. So let's start with the cognitive load theory. What is cognitive load? So I'm a big fan of the book team topologies. Maybe one of you knows that. Um, it's a book that talks in detail about communication pathways in organizations, about team structures, and also about cognitive load. That's where I discovered this topic. It's not a cyber security book, but it's a book about organizational design and team interaction in modern software development. I highly recommend that you

read it if you don't know it already. Yeah. In my work as a cyber security consultant, I work a lot with developers and development teams. And let's be honest, more than more often than not, I am one of the persons putting more on their plates. So, I come with security assessments. I talk about security requirements that have to be addressed. I may introduce new tools that they have to learn and I ask questions that interrupt their train of thought. And that got me thinking how exactly does security make the load heavier and I want to share with you now what I learned about cognitive load and what role security plays for it. The term cognitive load

has been established by um the Australian psychologist John Swweller in 1988. So it's quite old that concept. Um his paper cognitive load during problem solving effects on learning became the foundation of cognitive load theory and since then many researchers have built on it and gained deep insights about how the human brain stores and processes information. Let me give you a quick overview what they found. So you might be familiar with the terms long-term memory and working memory. And a quick note, so this is not an exact medical illustration of the brain and the location of memory, but to make make it more visually appealing, we have this. So in cognitive law theory, the long-term memory is where knowledge is

stored and the working memory is where we actively process information in the moment. Research has found that the working memory is kind of limited. is only capable of holding up to about seven items or elements of information at a time. And in comparison, the long-term memory can hold seemingly unlimited information. What is particularly interesting about how these information are stored and how uh both types of memory work together is part of the research that uh Swella did. So the research is based on a study in which chess players were tasked to solve chess problems. They were presented with board configurations from real chess games. That's important that they are from real chess games. And the study

showed that experienced players were much faster in finding the best next moves. um while chess noviceses spend much more time in finding in in analyzing the configuration and and finding the best next move. The same was not true for random board configurations where the pieces were just randomly placed somewhere. So the experts were not faster in that case. This led the researchers to realize something interesting. The experienced players weren't just faster. They were using kind of mental short shortcuts called schemas to recognize patterns on the board and quickly decide on the best next move. A schema can be described as a categorization of elements of information that is stored in the long-term memory and accessed when

needed. And that's not only true for complex things like chessboard configurations. It's much more basic. Anything we learn as humans is stored as schemas in our long-term memory. For example, that we know how to behave at a conference or how a conference works is also a schema that we have learned when we first visited visited a conference or airports are also a good example. So maybe all of us have been at a at an airport. We don't know. We don't need to know every single airport in the world to know how generally an airport works and what we have to do there. So, we store this as schemas in our long-term memory. Schemas are important because they reduce load

in our working memory by [snorts] letting us solve problems without juggling every single detail at once and making decisions without starting from scratch every time. They are very essential when we have to make decision decisions under pressure. So Swell's research mentions mentions two approaches of problem solving that derive from his observations. The schemadriven approach that I already mentioned. So where a person accesses their existing knowledge to recognize a pattern and use that for problem solving. And then we have something that's called means end analysis. And that describes a strategy where a problem solver must simultaneously consider the current problem state and the goal state and the relation between those. Then some problem solving operators also

the relations between those operators. And if a goal stack or a sub goal stack has been defined then this must also be maintained. Wait is this working? Yeah. Okay. And you see that it easily becomes more than seven items that we can hold in our working memory. So it's a very demanding mentally demanding process that consumes a lot of cognitive processing capacity. This type of problem solving was observed with the inexperienced chess players who didn't have a schema to categorize the B positions and to draw on experience to guide the next move. The cognitive load theory describes three types of cognitive load. Intrinsic, extraneous and germanine cognitive load. And I want to quickly explain to you what those three types

are about. So the intrinsic cognitive load is the mental effort related to the problem space and the inherent complexity of a task. So it depends on how many interacting elements need to be held in the working memory at the same time in order to understand or solve a problem. And an example for that would be from the chess world. Uh learning how the pieces move, what the rules are, uh the concept of check, checkmate. So this is just inherent for learning chess. In the world of software development, examples could be something like learning the syntax of uh a PHP class or Java. The intrinsic cognitive load cannot be reduced. It's inherent and we just have

to deal with it. The extraneous cognitive load refers to the way information or tasks are presented or handled, not the task itself. So, but how we have to work with it. And at our chess example, that would be the cognitive effort that we need to learn from a poorly written book about chess. or if we try to learn chess from someone who is really bad at explaining. So that would uh create a lot of extraneous cognitive load for us. In the world of software development that could mean uh undefined or manual processes that developers are expected to remember. For example, manual deployments or manual confir configuration of services or workflows where they have to switch between

different tools. Extraneous cognitive load is controllable and it can be reduced uh with better processes or with automation. And then we have the third type of cognitive load is the gerine cognitive load that refers to the mental work involved in connecting new information to what you already know which forms new concepts and builds long-term knowledge. It's considered the good kind of cognitive load because it leads to learning and to long-term retention and high performance. In our chess example, that would mean that we analyze a specific board configuration and apply the rules that we already know. Uh apply strategies that we already know to what we see and then maybe recognize a tactic. Um in the in the development context,

that might be figuring out how different components in a given system interact. with the experience that we have, we can analyze that and come to some conclusions. So that also requires effort, but it's the kind of effort that helps developers grow uh [snorts] recognize patterns faster and make better decisions in the future. And what I have just shown you applies to individuals, but it also applies to teams. And that's the level I want to focus on [snorts] because modern software development and cyber security are both fields that are complex. Um they require knowledge rich knowledgri problem solving tasks and high amount of information have to be processed here. There is a lot of skill needed. So

that's why I'm focusing on teams and >> [snorts] >> uh it's something that research about teams also has found that um well functioning and wellp performing teams uh need a lot of trust to work well together. So the complexity of the different domains playing together and the pace of development and delivery makes it also nearly impossible for individuals to keep up with everything on their own. So now let's talk about the role of security now that we have understood the concept of cognitive load. I already mentioned earlier that in my role I'm often one of those people who add to the existing load bringing security assessments and raising issues and introducing new requirements. And reading about cognitive load in context

of team interaction and software development, I started asking myself, so what does security as an extra layer of complexity do to a team's cognitive load? And more specifically, which activities are adding load and what kind of load are we dealing with? So my first step to approach this question was to generate a list of typical security tasks and circumstances that development teams encounter. and I grouped them into six areas. I will not read everything in that table to you. Maybe you can just flip over it. But the six categories that I created are cyber security knowledge development workflow, security testing processes, communication barriers, and psychological aspects. And this may not be a complete list. You

can find more typical security related tasks. That's okay. Um, but it's it's a point to start thinking about these tasks and activities. I realized that every security activity introduces cognitive load by nature or by design. So I wanted to focus on understanding what kind of cognitive load those activities are cing because when we have a clear picture about that, we can think about it in a structured way. >> [snorts and clears throat] >> um how we can address and reduce the cognitive load in for those specific tasks. So I started categorizing them and I colorcoded it for you so you get a quick overview. So blue is the intrinsic cognitive load, red is the extraneous

and yellow the germanine cognitive load. What we see is that most of the activities are [snorts] of the type extraneous cognitive load. So that kind that can be controlled and can be reduced. I want to go over the three categories quickly and separately so that we get a better picture of that. So let's look at the intrinsic load first. So tasks that are just complex by nature. So like understanding common vulnerabilities and risks, understanding security terms, for example, Zust or threat modeling or yeah uh dust, you know, all of those terms that we use that might not be common knowledge. uh secure implementation of features like uh authentication, how to imple implement proper authentication, how to implement uh encryption and

interpreting scanner results is also something that holds a lot of intrinsic cognitive load. All of those activities require a very specific knowledge from the area of cyber security that you can't necessarily deduct from the knowledge you already have as a developer and from problem solving perspective. A developer with no or little experience in cyber security has no schemas at hand to find adequate solutions. So the effort for solving those problems is accordingly high because of the many unknowns, the terms, the concepts, the methodologies, the tools. The complexity is inherent and can't be removed. But we can reduce the load over time by helping teams building up schemas. So some ways to do that is for example a dedicated training on

common vulnerabilities and secure software development practices, pair programming of experienced and inexperienced developers, a clear and inclusive communication from the security team, not assuming that everyone knows what z and dust and threat modeling is. um a living knowledge base with definitions and examples and also something like joint expert sessions between the security team and development teams. There might be more things that you can think of that help reduce the intrinsic cognitive load. Those are some examples for that. Let's look at the extraneous cognitive load. the part that is not inherent to the task but created by the way security is introduced or handled. This list is a bit longer and I won't read it to you

but I'm sure you can also find more things to add. So some of the solutions here might be defining a clear point of contact for example like a security champion if the organization has a security champions program. So as a go-to person in the team centralizing security guidance and tool information in a knowledge base uh often times I see that in organization that knowledge is scattered >> [clears throat] >> uh over different um platforms areas whatever. So if it could be also different confluence bases um yeah so a centralized approach would help here. um automating security scanning and reducing tool switching if possible. [snorts] Integrating security into planning with visible backlog items to so so security is no longer an ad hoc

uh [clears throat] activity. It often feels like that for for the teams improving the workflow with IDE integrations or Jira integrations for security scanning tools where possible. I know this is so many tools hold automated integrations but um [snorts] I know it's a little bit complex in reality but still something that you can look into improving the communication between different stakeholders and also making sure that policies are understandable from a from a development perspective and cultural aspects are also playing a role. here like fostering a shift left mindset and defining a clear software development life cycle. And for the points that have an emotional or psychological component, building a security community in the organization might also help as a safe space for

asking security related questions. That's also the one thing important here for the one gerine task [clears throat] on my list. Feeling safe to experiment and learn about secure development. That's also of course a cultural topic. Um a positive security culture fosters this good collaboration between the development teams wi within and also between development teams and security team knowledge exchange formats and things like that uh help here to create that safe space for learning. Okay, I only have a few minutes left. So let's dive into the real life examples. The first one I brought you is called the pipeline abstraction layer. PAL luckily a nice uh word for that. So PAL is a platform service we built that

helps development teams to integrate security scanning tools into their CI/CD pipelines in a standardized and containerized way. So we provide the code for the pipeline configuration and they just add a few parameters and add it as a job in their pipeline. So this approach has been realized by my colleague Michael Vaga who is now with GitLab. So that matches very well. The key idea is that there are no custom integrations, no tool specific configuration work to do and no maintenance on the shoulders of the development teams. We use PAL for zast scanning for container scanning and infrastructure as code scans at the moment and this can also be um extended. So how does the pipeline abstraction

layer reduce cognitive load? The development teams get a clear standardized way to integrate security scanning with preconfigured images. The integration is well documented and centralized. Maintenance of the images is centralized as well and done by the security team. and the teams automatically automatically get the latest versions of the tools. So the solution is also optimized for supporting multiple CI/CD systems and the development teams don't have to deal with two specific UI or configuration and when we want to switch the tool under the hood as security team we can do that and we already tried that it worked quite well so I'm happy that this uh concept worked so in a second we have I think we have

[snorts] room for a second example example the adaptive questionnaire for SSDLC on boarding. [snorts] So for a while in one of the companies I do consulting with there was no clear process for the SSDSC on boarding. They were just the teams were just required to do secure software development with [snorts] no further details. So they reached out to us to the central security team and asked for clarification and support and we had a meeting and explained to them what was required. We asked them questions about their application to find out which kind of um security scanning tool was suitable for them. So in case of a bpoke application that would be a zust scan in

case of a commercial offtheshelf a threat modeling would be better. And so at some point we needed another solution. So we built this adaptive questionnaire um that teams can just pull up and they are walked through the important questions and depending on their answers they get um only the questions they are re that are relevant for them and there is a lot of things in the background as well. So we ask for the application type. There are checks in the background if the app is already onboarded because that also happens sometimes that teams don't know they are already onboarded. Um they get all the setup information via email and tickets are created in the background for tracking the onboarding

process. So the main goal here was to enable the development teams to start the onboarding press pro process independently and get all information they need from a centralized place. I think we are out of time now and that's fine. I had another example but we can skip that. So thanks a lot for your attention. [snorts] Um I have a slide with some resources for you if you're interested to dig deeper into the cognitive load topic. Yeah. And that is thank a lot. Thanks a lot for your attention. [applause]

>> [applause] >> Thank you very much, Julian. Dear audience, who would like to raise the first question? You can see there's a catch box. So, anyone can just raise the hand and you get the catch box for your first question.

Hey. Um, thank you so much. That was an amazing talk. I just want to ask what was the third example? I'm really [laughter] >> It's about a security champions network. Um it's it's a security champions programs are a means to create that security culture that you need for collaborative learning and uh for improving the collaboration between the security team and the development teams and that's what I wanted to show you. So this is also one of the things we did uh with one clients to improve the culture and help create a safe space for learning about security for the developers. Nice. Who's next?

Um so one thing I have I have noticed is that in many cases people use Excel not because they love it but because it's the only thing available and very often just introducing new tools to have fancy forms or these additional things face [snorts] the stronger barriers. So what could be a good way of of simplifying tasks with the tools that are commonly available? >> Yeah, I understand that you cannot walk away from Excel completely in many organizations. That's also totally okay. I was thinking of a case where teams got a Excel questionnaire with 200 questions just sent without further instructions and they never reacted to that. So it was not not really working for the

security team because they never got a response. So [snorts] in such a case I would break it down and just try to phrase the questions very understandably and easily and um make I don't know maybe break it up into different sections and if if they are still not able to deal with it maybe you you need a meeting to walk them through and have a more interview style thing. Yeah. >> Okay. And let's say thank you again to Yan. [applause] Thanks a lot.