The Sherwood Applied Business Security Architecture (SABSA) is a renowned framework and methodology for developing risk-driven, enterprise information security, and assurance architectures. While it offers a holistic, multi-layered approach that emphasizes a tight link between business goals and IT security, the adoption of SABSA is often fraught with a number of challenges, mostly due to its complexity and the sheer volume of needed artifacts.
Challenges and Complexity
The challenges of adopting SABSA stem from a variety of factors. First and foremost, the complexity of SABSA is often perceived as a significant barrier. It is a layered framework, ranging from the contextual layer at the top (the business view), through the conceptual and logical layers (the architect’s views), to the physical and component layers (the engineer’s and solution provider’s views), and finally to the service management layer at the bottom (the operational view).
Each of these layers requires specific sets of artifacts, i.e., documentation and models that capture the details, relationships, and dependencies among the various elements of the architecture. The effort to develop and maintain these artifacts can be significant, requiring a high level of expertise and a substantial investment of time and resources.
Another common challenge is the lack of specific implementation guidance. While SABSA provides a robust conceptual model and a detailed set of security architecture matrices, it doesn’t prescribe a specific set of tools, technologies, or processes to implement the architecture. This places a heavy burden on organizations to define their own path toward implementation, which can be a daunting task, especially for those without prior experience or deep security architecture expertise.
Proposing Solutions
Despite these challenges, there are ways to simplify the SABSA adoption process without detracting from the ultimate goal of establishing business-driven policies and policy-driven architectures.
One solution could be to implement SABSA incrementally. Rather than attempting to build out the full set of SABSA artifacts all at once, organizations can start small, focusing on a specific layer or aspect of the architecture that aligns with their most pressing business or security needs. This might involve developing a high-level business context model or a set of policy-driven architectural principles, for example. Once this foundation is in place, further artifacts can be added gradually over time, as needed.
Another strategy is to leverage existing resources and industry best practices. There are many resources available to help organizations understand and implement SABSA, including books, online courses, professional training programs, and a growing community of practice.
Furthermore, tools and methodologies from other areas of enterprise architecture and IT governance (such as TOGAF or ITIL) can often be adapted to support SABSA implementation. This can help to fill in the gaps where SABSA lacks specific implementation guidance, and it can also reduce the burden of developing new artifacts from scratch.
Lastly, organizations might consider seeking external support. This could involve hiring consultants with SABSA expertise or partnering with vendors that offer SABSA-oriented products or services. Such external support can provide valuable guidance and accelerate the adoption process, but it’s important for organizations to maintain ownership and control over their security architecture to ensure it remains aligned with their unique business needs and strategic objectives.
Conclusion
In sum, while adopting SABSA is undoubtedly a complex undertaking, it is not an insurmountable task. With a pragmatic, incremental approach; the judicious use of resources and best practices; and possibly some external support, organizations can successfully navigate the SABSA adoption process and reap the benefits of a business-aligned, policy-driven security architecture.