One of the biggest challenges facing security leaders today is how to simply keep up with the onslaught of ever-growing cybersecurity threats to the organizations they’re trying to protect. According to recent research, 74% of organizations felt like their security programs weren’t really adding value to the business, and almost half feel that they don’t believe they have what it takes to ensure they can demonstrate the value of their security programs to the Executive Team and the Board.
As a result, many security organizations feel stuck in the past. They feel overwhelmed by the stress of reacting to operations events, and they are still struggling to be seen as partners who enable business rather than the Department of NO, who inevitably causes endless delays and additional costs to high-profile, strategic business initiatives.The challenge for most security leaders isn’t that they don’t know what to do. The “what to do” has been out in the world for quite some time. And where they might not be sure, there are armies of consultants, vendors and industry publications incessantly reminding security leaders what they should be doing—while scolding them for not doing it, like you’re some kind of delinquent child who doesn’t know any better.
So if the challenge isn’t knowing what to do, it’s often either not having the confidence you know how to do it or simply having no faith that the promises of any approach claiming to deliver results will actually be true.
You would be relieved to be able to say “YES!” when each new project came along, because you were confident you understood how your existing security controls would mitigate or avoid the cybersecurity risks associated with it.
You would be thrilled to respond faster – and even, remarkably, do nothing at all – when your team found out about new projects. “But, how could you not need do anything?” you might ask.
The answer is actually pretty simple: you’ve been there, and you’ve done that before. Not only that, but you can prove it too—not just on paper, but with live operational metrics. Metrics that show the controls you need are not only already in place, but that also demonstrate they’re working properly—right now.
You may know that the best way to be able to prove you’re doing the right things and to anticipate the security needs of your organization is to have a robust and reliable security architecture in place. And you may even have invested in trying to build one, either using SABSA® or some other methodology or approach.
But if you really tried to do this, there’s a good chance that you also ran into some problems. It may have been harder than you thought it would be to put something practical in place, or even to just show progress. You might not have been prepared for the additional time and overhead required when you’re trying something new, and, as a result, you found there was little support or understanding from either the team or the business customers you were ultimately trying to enable.
We know from doing enterprise security architecture for a long time now that, while it does get easier, sometimes it feels a lot like you’re lacing on your hiking boots for the first time, are able to manage a few gentle hills, and are then told that the very first thing you need to do before you can use the architecture you know you need is to just climb that mountain over there first. Don’t worry, it’s only Mt. Everest. But once you manage to climb it, it’s all downhill from there, and it gets so much easier.
And, in the face of this seemingly momentous undertaking, you decide that perhaps it just isn’t the right time. Maybe later, we can come back to it, you say to yourself. But somehow, it just never happens.
The truth is: it does get easier. But part of the truth is also that, like Everest, the road to conquering this challenge is littered with the bodies of the unfortunate souls who gave it a valiant try, but who, in the end, just weren’t ready for that particular test.
As a security leader, what you really want is something that seems pretty straightforward. What you want is to make sure your security program is set up from top to bottom to enable your organization to deliver its objectives and realize its goals. In other words, you want to make sure you can prove you support delivering the organization’s mission in a way that ensures everything and everyone is as safe as possible—at all times.
And you want to make sure you can do it as quickly as possible.
This ultimate aim and responsibility is what we call the mission and purpose of security:
To enable the organization to achieve its mission, as quickly and safely as possible.
While this may seem like a pie-in-the-sky pipe dream – especially when you’re trying to use some of the well-known security frameworks to do it – it is something within your reach as a security leader to actually deliver. And when you do, it will go a long, long way to getting you closer to being a trusted insider within the Executive Team, rather than being stuck on the sidelines trying to make your voice heard above the roar of the crowd.
The Principles of The Agile Security System
The Agile Security System defines a set of seven principles, and each of the seven principles is related. This means that they consistently reinforce the idea of what being effective in security actually means. And ultimately, they serve as the basis to guide the decisions you and your team make, and to provide the foundations of the behavior you and your team must deliver as part of being effective.
Now we’re going to present and define, the principles of the system—the principles that will guide the delivery of a consistently effective security program. These are the principles that will ultimately deliver the mission and purpose of security: to enable the organization to achieve its mission as quickly and safely as possible.
Principle #1: every security decision we make – every day – is intended to deliver our mission and purpose: to enable the organization to achieve its mission as quickly and safely as possible.
The first principle is the essence of the whole system. It summarizes everything that the system is, because it highlights that it’s the decisions we make that determine whether we’re effective. At the same time, the principle tells us the definition of what effective means to us, because being effective means delivering our mission and purpose. That’s why the mission and purpose is part of the principle itself.
Because it’s the decisions that we make that ultimately result in our success or failure. And since our role is to enable and protect the organization, if we fail, so will our organization.
Principle #2: understand the customer’s world
The second principle highlights the key aspect of a mission and purpose. We know what ours is supposed to be, but what may not be obvious is that the focus of any valid mission and purpose is on those who benefit from it. The customers of it.
That means, our focus must be on what our customers need to be successful, and not primarily on what we need to do or how we do it. It must be based in the customer’s world, and it’s impossible to know what that means if we don’t understand our customers and their worlds; the things that they’re trying to achieve; the environments in which they operate; and the things that are important to them.
Principle #3: build shared models
The third principle tells us what we need to do with the understanding we have of our customers’ worlds. It won’t do any good if everything we know only exists in our heads—the collective heads of the security team. Yet isn’t that what happens today? When something breaks, or when someone has a question about why things are the way they are, don’t we generally rely on just asking the person who knows? Don’t we do that…because it’s easier?
Our third principle tells us that this approach isn’t good enough anymore. If it’s something we know, either about our world, or our customers’ worlds, then it must become part of a shared model. And a shared model is one that is collectively built and maintained by the whole team—and not just the security team, but the extended team across technology and the business customers as well. These models create a consistent picture of the world of the organization that everyone uses to answer the questions they have about their worlds. And if the answer isn’t there, then the models get updated. And the models get validated – every day – because they’re how everyone stays on the same page, so if something isn’t right, then it gets noticed, it gets discussed and it gets fixed.
Principle #4: communicate with transparency
The fourth principle tells us about how we communicate both within the team and with our customers. No more silos. No more isolated messages. No more conflicting messages, because the basis of the communication about the way our world as security supports the world of our customer is through the shared models we create and maintain by following Principle #3.
And we communicate transparently and frequently about what’s going on in our world. We constantly and proactively reflect our understanding of our customers’ worlds gained through Principle #2 so that we can reliably detect when we’re starting to drift and when our priorities may no longer be aligned.
Principle #5: violently encapsulate complexity
The fifth principle ensures we’re successful in battling the primary enemy of the effective security program: complexity. By following this principle directly, we apply it consistently to the models we create following Principle #3 and in the way we choose to communicate and engage with our customers when we communicate following Principle #4.
It’s impossible to understand the entirety of anything at once. We need to define sensible ways to slice through the complexity of the whole so we can isolate and talk about what’s really important for any given decision we need to make. By reliably and consistently following this principle, we can have the confidence and focus on only the truly necessary information and input required for a decision, and we only communicate the essential and most relevant facts and concepts to our customers.
Principle #6: establish assured confidence
Confidence without assurance isn’t confidence at all. At best, it’s hope, and at worst, it’s delusion. The sixth principle helps us ensure our confidence of the consistency in our decisions, in our effectiveness and in the operation of our chosen security controls is justified and validated to the satisfaction of our customers—and ourselves.
This principle ensures we’re constantly seeking answers to the questions: are we doing the right things? Are we doing them the right way? Are we doing them in the right place? Are we doing them at the right time? And, in conjunction with following Principle #1, it ensures that we answer them from the perspective of delivering our mission and purpose as security.
Principle #7: learn and adapt
The seventh principle reminds us of the essence of what being “agile” truly means. It helps us cultivate the mindset we need to stay connected to our customers and be prepared for the enviable changes that will take place in both our world and theirs. The lessons we learn about what worked and what didn’t; about how things are likely to change; and the rate at which they do so are all important things that make us better prepared to make the next decisions we need to make.
And this learning can’t take place in isolation, thanks to our other principles, and in particular Principles #3 and #4, because we need to document what we learn in our shared models. We need to use those models to communicate effectively across the team and with our customers. Even in our models built with Principle #5, what seemed like a good weapon against complexity today might not be sufficient when the world changes tomorrow. It also means that when we follow Principle #2 and develop our understanding of the worlds of our customers, that this picture isn’t static. By putting the two principles together, it can only be a vivid and dynamic picture that must be constantly kept up to date.
The Practices That Build Habits
On their own, the principles of The Agile Security System are powerful tools to increase the effectiveness of your security program. However, they’re not enough to give you the confidence and the consistency required to demonstrate that effectiveness every day. The mechanism you need to ensure consistency is a well-defined set of practices that are the specific behaviors you will use when you follow the principles of the system.
- Be curious
- Do your homework
- Ask great questions
- Listen reflectively
- Validate your assumptions
- Anticipate policy exceptions
- Read critically
- Use the Baseline Perspectives™
- Draw fearlessly
- Apply SABSA recursively
- Engineer confidence
- Maintain the Architecture Wall™
- Communicate with your models
- Pause and reflect
The intent of the practices is to give you both consistency and confidence that you will do the right things, no matter if you have all the time in the world or if you’re fighting total exhaustion trying to contain a major incident. These practices can only truly deliver their value if they have been internalized to the point where they become automatic. They must become the habits by which your security team does their job, every day.
The 14 practices defined by The Agile Security System work together to ensure the principles are followed and to influence the behavior and activity of the team. When these practices are integrated as habits, you will have the best possible chance to successfully deliver the mission and purpose of security we mentioned above: to enable the success of your organization as quickly and safely as possible.
Creating Visable and Actionable Architecture
The Practice of Visual Architecture with the Architecture Wall™
The figure illustrates the Architecture Wall in action as part of documenting the architecture of an actual project. The elements on the wall were all created by following the practices of the system and are represented using the models, templates and worksheets that support those practices.
The Architecture Wall becomes the focal point of the entire security program, and it provides the standard way to describe the organization, creating a shared picture in the minds of the whole team – including your business customers – of what’s really important in the organization and how those things are related. These models evolve and adapt over time according to Principle #7, but it’s critical they are visible, because the worst models you can create are the ones you never use.
And if you’ve struggled to build security architectures in the past with SABSA or any other approach, an added benefit is that the result of following the practices of the system is an architecture with all the power and value of SABSA—because the architectures you create with the system are real SABSA security architectures themselves. So if this is important to you, it’s the fastest and easiest way to full SABSA adoption you will find anywhere.
The insistence on visible architecture, shared models and transparent communication, if followed, guarantee the end to rows and rows of discarded strategy documents that sit collecting dust and whose thickness are in direct proportion to the money spent – and likely ultimately wasted – in producing them.
Instead, the architecture is used by everyone on the team to make daily decisions, from whether to be worried about a particular threat intelligence report, to what the priority and impact of a potential new product would be, to the potential scope and impact of a risk assessment, to the organization and relationship of the deployed security controls. One model. One consistent picture. One effective team.
How To Get Started Delivering Agile Security
The best part about the system is that it doesn’t take months of training and practice before it makes a difference. Building an initial visible architecture and creating the first shared view of the worlds of security and your customers can literally be done in hours, not days or weeks. Hours.
But this is possible only once you’ve developed the habits of the system and are able to apply them consistently. However, as stated above, it doesn’t take mastery of the system to demonstrate major improvements in the effectiveness of both your program itself and the way you engage and communicate with your security customers about it—especially the Executive Team and the Board.
And once you’ve built your architecture, you’ve established the foundation on which you can build the effective security program your organization needs that will traceably connect your operational security strategy to the value it delivers in supporting the current strategy of the organization.
The single best way to find out more about how to get started with applying The Agile Security System in your own organization is to sign up for our DAILY security leadership tips and offers from our Founder and Chief Executive, Andrew S. Townley. Every day, you'll see how The Agile Security System – and SABSA generally – can add value to your security program and enhance your security team's integration with the organization. Once you see the best place to start, then you can act right then and there.
However, if you'd like a more formalized approach to getting started enabling and protecting your organization using the Principles, Practices and Perspectives, you might find our flagship security architecture education program a better fit. To find out more about the Building Effective Security Architectures (BESA) program, and maybe even join the next cohort, see the BESA program description.
About Archistry™
Archistry exists to do just one thing: we help security leaders and their teams build more effective security programs. Since 2006, we’ve helped global organizations build more robust, business-driven security programs on the solid foundations of the SABSA methodology in a variety of industries and countries, including Internet, Banking, Financial Services, Manufacturing, Utilities, Health Care, Agri-business, Education, Software and the Public Sector. During that time, and under the personal training and mentoring of John Sherwood and David Lynas, co-authors of SABSA, our Founder and Chief Executive Officer, Andrew S. Townley, has created a unique, proven and comprehensive approach to delivering security value.
We call this approach the Archistry Execution Framework(AEF)™, and its Cybersecurity Edition (ACS)™ defines a consistent set of security team roles, detailed processes, templates, artifacts and reference models to ensure the mission and purpose of security is consistently delivered, whether the organization employs a traditional SDLC approach or has embraced Agile/DevOps for project delivery.
The Agile Security System harnesses all of the power of ACS which itself is built on SABSA, to provide the fastest, simplest and most effective way to deliver agile, measurable and business-driven security programs that support the organization delivering its strategy as quickly and safely as possible.