Transcript
Shana Dacres-Lawrence: In the early days of computing, architecture and security barely acknowledged each other. Architecture was more rigid, monolithic in her thinking, obsessed with making things work. Security, he was more audit driven, compliance focused, had a few physical security, but nothing else. Architecture was out there really trying to solve problems but security stood awkwardly in the sidelines. Architecture only really called security when something went wrong.
Then the early 2000s, the internet boom, things got complicated. Suddenly there was threats everywhere. Threats were sliding into architectures, DBs. Suddenly there was more catfishing. More threats were emerging in the solutions for architecture. She had to evolve, so she became more microservice driven, agile in her processes. She adopted more ways to ensure that she was able to grow and scale to meet demand. Architecture, on the other hand, he also upped his game. He became more proactive in his approaches, started to adopt more secure by design practices. Security even made it into architecture frameworks, like TOGAF. There were no labels. There was no public commitment. It was still very much, we're in this, but we're not really in this together.
Today, there is a commitment, a public commitment. They're deeply connected. They have built a zero trust household, have embedded DevSecOps into their model. Architecture ensures scalability, resilience, adaptability, whereas security helps to protect those very values, defending against breaches, downtime, and vulnerabilities. Threat actors have become more sophisticated, but they're threat modeling. They're helping to fortify their assets against the outside threats. It sounds like a happy ending. There is union. There is love. There's a healthy dependency. There's also betrayal.
Professional Background
I'm Shana Dacres-Lawrence. I'm here to talk to you about the betrayals that can occur within the intersection of security and architecture. My experience, I've spent the last 13-plus years in multinational consultancies where I've had the privilege of going from both an engineering into architecture roles from both a security and a software mindset as well. I really started my career in software development using secure by design principles or secure coding principles. Having to ensure that everything I built to be specific, contained within specific guardrails to meet the security structure of those solutions. I was what you can call liberated when I moved on to an accessibility-driven application where no such concerns were in place. It was all about the users and how they were interacting with the solution.
Over the years, I've developed to keep both of these in mind, both from a user centric approach to also how do we maintain and uphold the security principles? I've had the unique opportunity from working within consultancies to move between different industries and different domains and actually get to see the relationships between security and architecture play out across a range of industries and across a range of organizations. I've learned more often the hard ways about the troubles that can occur at these intersections. Outside of my day job, I'm also the founder of ArchitectHer, which is a platform for helping to empower women to succeed in technology architecture. We do everything relating to helping to elevate more women in technology and also putting on events, developing skills and technologies to help showcase, and also shining a positive visibility for women that are in architecture.
Context
To betray one is to betray both. This talk is really my efforts to share some of the lessons I've learned firsthand around the struggles that can happen between these intersections, between security and architecture, and how to bridge the gap to safeguard against the union. I'm really pitching this talk for everyone that really cares about it, even those that are in security. Also, to those that are in engineering and understanding the mindset that the security team have to work with when you're working with them. Given that, we will explore the three types of betrayals that I come across more often. There are many forms of betrayals, but I've tried to categorize them into three types, and I'll detail that to you.
Then we'll go into the five defense strategies that's really helped to build up this relationship to ensure that it is a lasting union, one that can stand the test of time. What is betrayal? Betrayal is the breaking or violation of the presumptive contract, trust, or confidence. We all know this in a relationship when you've been betrayed by your partner. It can lead to trauma, feelings of hurt, anger, disappointment. In the relationship of security and architecture, it's about the compromising, the foundation and trust upon which resilient systems are built.
Types of Betrayal - Physical Betrayal
Let's have a look at the three types of betrayal within security and architecture. I've categorized these as physical betrayal, emotional betrayal, and trust betrayal. Physical betrayal, structural weaknesses. This is about delivery over security. The need to get things out faster, which sometimes means that we prioritize delivering and meeting our customer's need over ensuring that we're embedding our core security principles. It can also manifest by ignoring our resilience principles. That could be our ability to recover from failure. How fast can we recover from failure? Availability, our ability to just withstand and update in the face of failure. Also, it can stem from misconfiguration. This is something we see quite often. Once in a while we see it come up and then it goes away again. An S3 bucket was left with the default settings. That's a typical structural weakness that you've left the default settings in and that's resulted in the destruction.
An example of when I suffered a physical betrayal was when I was in the role of a security architect. Like I said, I've moved between security and architecture, solution architecture quite often. In this particular situation, I was a security architect working on a team where we're developing a particular solution to help build a new identity solution for a customer. The software team wanted to put in place SMS as the core authentication method. As we in security know that SMS is one of the weakest forms of multi-factor authentication. It's easily intercepted. Architecture and security was at odds with this. Security wanted to protect the system, uphold our values. Where architecture wanted to ensure that we're able to deliver faster because this method was well known by their customers, well understood. It meant that they were able to deliver it faster because they knew the integration patterns. We couldn't agree. Ultimately, we brought it to the business.
As you do, sit down in a big discussion. We both lay out our tradeoffs, our approaches to why we think one over the other is more beneficial. Why we should implement SMS and why actually we should implement a different, more secure method. In the end, the business chose to go with the architecture team to get it done faster. Security was left betrayed, left out in the open.
A really good example of this in the public domain and the public destruction that this can cause is one that we all felt around the CrowdStrike incident. CrowdStrike, a cybersecurity firm, had an IT outage that left 8.5 million Windows devices failing, really. It was a result of the betrayal of architecture. The outage was attributed to flaws in the security update process. The process was in place, but it was circumvented because of the need to deliver faster, get it out, get the solution in place faster. It really betrayed the integral structure of the system. They put delivery over test assurance, which resulted in the betrayal of the system.
The destruction, it was widespread. It grounded flights. It halted hospitals. 8.5 million Windows devices disabled. I think your only saving grace is if you were on a Mac. Fortune 500 companies felt it. It was recorded that this incident caused about $5.4 billion in losses. A major airline reported that because of their inability to recover from this incident quickly, they were losing or they lost up to $500 million, which they're also taking action against. What's worth pointing out here is that this incident not only just impacted one industry, it impacted a range of industries, from burger huts to broadcasting. It was widespread. As you can see, physical betrayal can really show itself, manifest itself in many ways, but it's really down to the structural weaknesses that can occur within the intersections of security and architecture.
Emotional Betrayal
Let's have a look at emotional betrayal. Emotional betrayal is around assumed loyalty. You have assumed that security will be loyal to you. You have assumed that you have a good communication. You had a quick chat with the security team. They said they were on board, but in reality, were they? On the opposite end, security sometimes even have the label of being the no, no, no kind of candidate. "No, you can't do it this way. No, you can't do it that way". Especially given the domain you're in, that may be even worse. Architecture, on the other hand, displays the same kinds of behaviors, the lack of communication, but maybe giving a helicopter view, not providing the details of what's going on in the solution.
Only giving, it depends, or it's an implementation detail, and not really providing the context to which the security team really need to know. We've all fell victim to it. It can also stem from misalignment, verbal or documented misalignment. Like I said, you've talked about it, but you never really agreed upon it. You thought they were on board, but really, were they? It can also show its face when one partner exerts too much control. Depending on the industry you're in, this can weigh either end. When I've worked in more public sectors, I feel as though security has more of the control. They're quick to block, quick to jump in and say no, no, no. Whereas if you're more in the private sector, the ability to get things out faster and deliver quicker, architecture and engineering have more of the control. The need to get things out the door usually results in that domain having more of the control. For me, I've seen this when it shows up in decision-makings.
One of my first experiences of going through a governance process, if you ever have been through an architecture governance process, it was before COVID. We were all in the office developing a solution using new cloud technologies at the time. My team and I sat down, we looked at the design and thought, yes, this is the solution that we want to take forward. We circulated it within the teams, made sure that we informed and consulted the right people. We even walked over to the security architects and the security engineers, and went through the design with them. They fed back, gave us advice around how to improve it. On the day of the governance board, I went into the presentation and detailing how we were going to design this new solution with all these brilliant cloud technologies.
Security was the first to raise their hands and say, "No, this is not going to work. We have all of these weaknesses in this solution". I felt betrayed. We had spoken about it. We had gone through it. What's changed? I really was reflecting on this a lot. When I went home and I spoke about it with my partner, I was saying how betrayed I was, how I felt that I assumed it was going to be loyal to me. In this case, my partner pointed out, why did you assume this? They never said they were going to be loyal to you in the first place. I had a bit of an epiphany in that moment. It was assumed loyalty. There was no formal agreement in place.
How we've seen this in the public domain. Our Barclays one is really interesting. We saw this in early January. Barclays is a UK bank and they had a glitch in January, right on payday. It was the first payday right after Christmas. Most people, if you're me, spent all your money on presents, on making Christmas wonderful for your family. You're really looking forward to that first payday. On the 31st, Barclays Bank had a glitch. You didn't have access to your money. You couldn't view your balance. You couldn't even make a payment at the checkout. This lasted for quite a few days. Customers had to abandon their carts, were unable to view their online banking or even process their payments for critical services.
This glitch, the result of it hasn't been shared within the public domain or the reasons for it wasn't shared in the public domain. I suspect it was down to misalignment, a lack of good communication, a betrayal of architecture. The destruction, it was widespread. Availability issues, users were unable to access their money. That's bad. Critical services, data inconsistencies. You'd go and look at your balance and it would show something totally different. If it was higher, amazing, you'd be feeling good. If it was less, you'd be panicking. It would be really terrible. It affected so many of their customers that they've had to put aside $7.5 million in compensation just because of the damage, the destruction it caused. The damage to their image, it was really terrible. Emotional betrayal can play out in the form of assumed loyalty. You assume that your counterpart would be loyal to you in this situation.
Trust Betrayal
The last one is around trust betrayal. Assumed trust, the most dangerous of them all. You assume that the system would be secure. You assume that it would be resilient. You weren't taking into account the fact that the architecture, the system, the engineering is evolving, it's changing every day. If you're doing continuous deployments, you're adding new services into the architecture, compounding the risk. Lack of structures and control, so not enough proactive measures in place, not enough testing, not enough third-party controls. The typical, "We've never had a security breach. We've never had a recovery issue. We've never had a resilient issue". I once worked on a project where we were looking to develop a user-facing solution that meant that we had to go to the market and consult with third-party vendors on some of their products.
One of the products that we were working with, their team came in, sat down, gave us an overview of how they were going to meet our requirements to ensure that we protected our customer data. We had very specific requirements around how the data had to be, where the data had to be retained, so the regions within where it had to be retained, how the data needed to be deleted. Also, how the data needed to be archived. Going through these discussions, the team outlined exactly how this was meeting our solutions. Having worked on the solution in the past, I knew that it was not meeting our requirements in the way that they were articulating it. It was doing a soft delete rather than a hard delete. They were really trying to get away on technicalities. It's a soft delete, then it's a hard delete. That would have really infringed our security posture for the organization. If you don't catch these things in a moment, this can really result in betrayals that you don't even see coming, the ones you have to really look behind you for.
In the public domain, a really good example of assumed trust is the tale of Change Healthcare. In April last year, Change Healthcare, a subsidiary unit within one of the largest healthcare units within America, UnitedHealthcare Group, was attacked and 4 terabytes of their data was stolen. What you need to know is that in 2022, UnitedHealthcare acquired Change Healthcare, and they integrated their systems. An attacker was able to take advantage of this. UnitedHealthcare had assumed that the security posture, their security principles was being adhered to, that they were maintaining the same levels. It was a clear betrayal of security, a betrayal of trust. They had assumed that the trust was in place, that the company that they acquired was compliant with the protections and the security controls that they laid out.
In reality, they had a server with a portal on it that was unprotected, an admin portal, no multi-factor authentication, and attackers were able to take advantage of this. They were able to gain access to this portal and move laterally through their systems to get into UnitedHealthcare, and really bring down, steal 4 terabytes of data and hold it for ransom. The destruction, it was widespread across America. American people felt this destruction within their healthcare, within their payment system, when trying to buy prescriptions, when trying to make sure that they're meeting their health needs. It took down critical services for them.
The CEO for the group was even brought in front of Congress to explain what happened, and he had to confess to the fact that they paid $22 million, equivalent in Bitcoin, to buy back 4 terabytes of their data from attackers. 190 million people were affected by this. The cherry on top is they were held to ransom again for the same data. As you can see, the destruction, really widespread.
We've gone through some of the betrayals that I've witnessed more and more often as I move between security and architecture domains: physical, emotional, and trust. Do you recognize some of these betrayals? Have you been betrayed? The relationship between security and architecture is one that we must try to uphold. Try to ensure that the destruction, we put measures in place so that we limit the amount of betrayal that can come up between this relationship.
Defenses Against Betrayal
Here are five defenses against betrayals that I've used in different environments that's really helped me to ensure that I uphold the security posture and actually build a lasting relationship with security, and from an architecture mindset as well. These are open communication, tools and tech, automation, hands-on validation, and a collaborative culture. These will help you move from seeing red into a cool blue of understanding each other, having empathy for each other's domains. I tell you, when I've applied these defenses in isolation, I'd see success, but then I would be betrayed on something totally different. When I applied them all and tried to build a consistent relationship between the two teams, it was when I've seen the most success.
Open Communication
Let's have a look into them. Open communication. This is about ensuring that the relationship between security and architecture is built on communication. There are people at the end of the day. Ensuring that you're clear on your non-functional requirements, both from an architecture and a security perspective. Eliminating assumptions, assumptions about the security posture, assumptions about the solution, assumptions about what your solution can withstand from failure, or even what it needs to be able to withstand from a business perspective. Positive reinforcement. Like I said, there are people at the end of the day. Being clear and having a positive approach to our communication styles rather than a negative, off the bat, no, no, no, positive reinforcement really helped to build that open communication. This will help avoid the betrayal of emotions, so emotional betrayal. The key tip here is consistency builds trust. The two domains will be watching to see if the other one aligns with their action.
Tools and Tech
Tools and tech. Investing in frameworks, tools and technologies that integrate seamlessly into your architecture and into your engineering structure really helps to ensure that you're able to not just say what you're going to do but prove it also. Applying the zero trust mindset. Use tools and technologies that integrate seamlessly, ensuring compatibility, reducing complexity. Apply standards and patterns like fitness functions in your coding to ensure that development practices are being adhered to. Invest in stand-in architecture.
Monzo Bank have a really great example of a stand-in architecture that they use and they've shared it publicly. I'd encourage you to go and have a look at that and see how you can apply it in your organization because these techniques can really help you avoid physical betrayals. The key tip here is to adapt a shift-left approach. Incorporating security and resilience practices into your software development cycles right from the beginning. That's everything from threat modeling to failure detection and reporting. Use methods and frameworks like Failure Modes and Effects Analysis that helps you to identify where and how your solution can fail, how long it will fail for, and how you'll be able to recover from it to then understand the priorities around your solution.
Automation
Automation, this is being able to detect and respond to anomalies and breaches. Everything from blocking certain domains, workflows, compliance checks, audit checks, checking of your infrastructure, your Terraform, to ensure that your deployment method, your practices, your security patches are being automated. You're not relying on someone being there to be able to update, to check all the time, to validate. Again, doing the zero trust, always prove methods. Ensuring you have a clear DevSecOps model and path to live.
The language around the DevSecOps model is very well known within the industry. Ensuring that you have a clear model to get things into your production environment. There's a really great quote that says, if your path to live is broken, you can't get anything into production. Your path to live is just as important as your production environment. You have to protect it in the same ways. That will help you avoid trust betrayal. Because again, you're proving the applications, you're proving the systems and the controls you've put in place. The key tip here is to be intentional, not transactional. Identify key areas where automation can provide the most benefits and focus your efforts there.
Hands-on Validation
Hands-on validation, so engaging directly with the system to ensure that the functionalities of the design and security objectives are being adhered to. This is coming down to applying controls or even going through penetration testing, simulations, failover testing, understanding how your system recovers from failure. Not just withstanding failure, but recovering from failure. Is your data able to recover? Are your systems able to recover? Also, balancing the need for speed and security. We know of the tradeoffs between getting things out really quickly and also ensuring that the principles are being adhered to. Try to balance those in a way that you are still adhering to your security principles, but balancing the need to get it out in a way that helps you maintain your security posture.
Proactive adaption, having a mindset of a proactive approach rather than a reactive approach to your security and your engineering to identify risk and issues. This will help you to avoid trust betrayals. The key tip here is about, it's not possible to test for every scenario, but you will have to react to every scenario. Understanding the scenarios that can happen within your system and know how you need to react if they ever come up.
Collaborative Culture
Collaborative culture. One that I've seen worked really well is when you embed security and architecture into each other's teams. This is about security being embedded into your engineering team, working very closely right from the beginning so you can foster that emotional intelligence, understand each other's point of views because security have different objectives. They're thinking about the risk of the system, threat actors, how vulnerabilities can manifest in the system and then propagate. Being able to understand those from an engineering mindset really helps to understand why they say no against a lot of our approaches and helps you to develop a better understanding, empathy towards their reasoning. Because they're really the ones that are on the hook, that will get called out for a lot of these, and not to articulate the risk they're taking within the systems.
Using the architecture advice process. Making sure that you are involving security and architecture in the decisions that you're making. That they're consulted and that each of them are not playing a role that is not blocking to each other. Security on one hand is assurance. Sometimes they're enforcing certain principles, and can be seen as doing a lot of the policing. You want to take that back and ensure that you're working collaboratively with the teams. Being agile and opening your approaches. This is around making sure that you're able to make decisions in a way that you're considering each of those points of view.
Reacting to change, not just changes within your engineering, but changes within the wider organization, the wider culture, the wider world that we live in, because threats are evolving every day. Security have to evolve to meet those threats, to react to those threats. One change that might be efficient today or one principle that might be efficient today may no longer be efficient today. They have to evolve and adapt their approach. As an engineering team, we also have to be able to consider those mindsets as well. It will really help you to avoid emotional betrayals. The key tip here is that security should guide architecture, but architecture should also shape security. One should not exert too much control over the other. The two must evolve together, create resilient, adaptable, more secure systems.
When all of these defenses are applied together, the relationship between security and architecture helps to evolve. You're building a partnership that is built on trust, on empathy, on ways of working that helps to ensure that you understand each other's points of view. You're also putting in place protective controls to not just assume trust, assume loyalty, but to prove it. Once you're able to prove it and validate, then you continue to build trust. It's a cycle. Those are the five defenses against betrayal. My invitation to you is, don't wait for betrayals to happen within your organization to then react to them. Consider how you can protect against these betrayals. Put the safeguards in place so that you don't end up being betrayed by your counterpart. Out of these five defenses, which do you choose more naturally? Which do you have in place at the moment? Which would you need to put in place to ensure that you're building that collaborative culture, that safe environment where security and architecture can continue to thrive and grow and withstand against betrayals?
Recap
We've gone through the three types of betrayals that can happen within security and architecture. There can be physical betrayal, known as structural weaknesses, emotional betrayal, which is assumed loyalty, or trust betrayal, which is down to assumed trust. We've spoke about how they can manifest, how they develop within our organizations, within our systems, within our conversations.
Key Takeaways
The five key takeaways that I would like to leave you with are, consistency builds trust. Be consistent in your communication, in your approach, in your ways of working. Adopt a shift-left approach. Embed security early on in your conversations. Give them the full view of what's going on, the context of why you're developing a solution in a particular way, so they can understand the holistic view of the system, and not just a particular point that you may just be wanting to detail to get through governance with. Be intentional, not transactional. Identify areas where automation can provide the most benefit, and focus your efforts there.
Remember, it's not possible to test every scenario, but you will have to react to each and every scenario that comes up in your architecture that may result in betrayals. Think about how your data is persisted, how you would recover your data in the event of failure. Think about the whole system architecture from both a security standpoint and an architecture standpoint, a solution and engineering standpoint. Security should guide architecture, but architecture must also shape security. One should not dictate or exert too much controls. The two must evolve together, create a resilient and adaptable system that is both secure and meets user needs. I've gone through the principles that I put in place to help build and maintain this relationship to ensure that we don't have destruction, betrayals within security and architecture. I hope that you can take away some of the lessons I've learned from my own experience and apply them in your own organizations and try to adopt them.
Questions and Answers
Harmel-Law: If you are betrayed, as either a security person or an engineer, how can you bounce back from that?
Shana Dacres-Lawrence: How do you recover from a betrayal? In my experience, once the betrayal has happened, I tend to try and reflect on it and see what could have caused it. Like in the example I gave around going into a governance situation where I was sure that security would be on our side. We had gone through the design with them. We had assumed the loyalty was there, but it was not. To help protect against this and to bounce back would be to try and build up on your communication styles, have the conversation and see what was missing.
If it needed to be more formal, we went through this. What happened? Do we need to write it down? Do we need to have more collaborative controls to ensure that the viewpoints that we have, what we took away from that conversation is well understood. Have decision documents that helps you to record the conversations that you've had, the decisions that you've made, and help to uphold those core values about working together and building relationships that will help to manifest throughout your organization.
Participant 1: As an engineer, as a software developer, I find the security stuff very complicated. Do you have some tips for this knowledge flow, how to transfer the knowledge or understanding between the two teams? Do you have tech talks or how to encourage this communication, that it's really honest and good?
Shana Dacres-Lawrence: I think a really good way to do that is down to our people skills, having the conversations. Where I've seen it worked really well is where we embed the security engineers or the security architects into our engineering teams. They provide the context of actually, this is our security principles. If you do it this way, this is the kinds of threats, this is the kind of risk that you're inviting into our systems.
Another way to understand it, or frameworks is around threat modeling. You can Google and understand how threat models are developed with security teams to then develop an understanding of what they're thinking about, what kinds of threat actors they're thinking about when they're trying to derive the risk of a particular solution and understand how vulnerabilities can manifest within the solution you're proposing. I really would encourage more conversations with your security team.
Try to have those open and honest conversations. We tend to give security a hard time, but I look at it the other way sometimes. They're on the defense because they're hurt. They've felt it. They know what it's like to have to stand up in front of their superiors and say, actually, something has gone wrong and it was the result of X, Y, or Z. Because of that hurt, they're like, ok, we can't let this happen again. They're on the defense. Being able to have those conversations and being clear that actually, if we put these practices in place, or if you think about it from this way, it would really help to build those conversations, develop the same kind of mindset or even empathy for the security team and the security principles that they've laid out, the security NFRs that the system needs to be able to withhold.
Participant 2: Do you feel like there's a really similar approach that could be taken?
Shana Dacres-Lawrence: We're all looking at architecture from different angles, but at the end of the day, we're all people. It's all about engaging the different perspective from different angles and understanding the perspective of the team, the domain that you're interacting with, and trying to develop approaches that help to build upon open communications, having different perspectives, developing solutions in mind of what a particular domain or journey is on.
Participant 3: In my company, we started on a security project relatively recently, and now, I find it very difficult to talk to the security area. Essentially, from my perception, it's a black hole from time to time, these briefings. How can we create a culture of meeting in the middle and creating meaningful communication and collaboration?
Shana Dacres-Lawrence: That's around how we can build more communication, especially given that sometimes security can be seen as a black hole. I look at it in terms of, in organizations where I've been working in, security is usually quite a small team. The engineering team is quite large and you're developing many components, many services, many systems, and the security team is usually a small team having to understand all of those components, those services, that solution, and they're spread quite thinly. Try to build in practices from the offset. Having regular check-in. I used to do regular meetings with our security team once a week on a Wednesday, 1:00. That's our security check-in. We'd have an hour with them, we'll go through some of our ideas that are developing, some of the solutions that we're thinking through.
Some of the constraints we're having with the design, especially if it's from a security constraint, and really try to understand the considerations that we need to build into the design so that when it comes to assurance, the security team really knows where the product or where the service or the component is coming from, some of the thoughts that's gone into it. Because they've been consulted on the mindset that you're having, the approaches that you're thinking about, and try to build that in quite early on. Have regular touch points, have review cycles, build in automation frameworks in place that you can prove that you're adhering to your security models and your security principles.
See more presentations with transcripts
