Although most security pros agree that having clear blueprints is important, some question whether an enterprise security architecture (ESA) is actually worth the effort. We tackle these questions in a Leadership Brief (free with registration) for KuppingerCole. This post introduces the Leadership Brief, and adds a few additional points in support of ESA.
Why is ESA Important?
An ESA is important for the following reasons:
- Without a clear context, high level direction, and functional or interface specifications for how all the moving parts in IT/security fit together, those components will be less effective.
- Security architecture must exist in parallel with Enterprise Architecture (EA). Security is a weakest-link proposition with different perspectives; it must address risks, threats, and vulnerabilities without impeding the very business it protects.
- An information security architecture (basically, ESA) is required for compliance to NIST, ISO, and other control frameworks.
That being said, ESA should not become an overly lengthy, or blocking process. The time to create and accept specifications must not exceed the windows we have to define and specify solutions before the problems themselves change. Fortunately, ESA can be developed in a reasonably lightweight, practical, and iterative manner that leverages any work busy IT/security groups have already done to document, plan, and procure their systems.
Pathways to ESA
Per the Leadership Brief: “The optimal path towards ESA depends on the starting point in IT/security maturity and the appetite for architecture work.
Customers with no (or rudimentary) EA program in place should consider two options:
- Build up an initial ESA using a security road mapping and control prioritization process, such as described in the NIST Cybersecurity Framework.
- Build a comprehensive ESA leveraging Sherwood Applied Business Security Architecture (SABSA) in parallel with laying some EA program foundations and a formal risk management program.
Customers that already have a functioning EA discipline should consider expressing their ESA in SABSA terms and develop SABSA business attribute profiles, service catalogs, and other concepts. This Leadership Brief provides information on a method proposed by the Open Group for aligning ESA with EA.”
In other words, you don’t have to build a comprehensive ESA in every case, and even if your organization’s goal is to become comprehensive, you don’t have to get there overnight. Nor do you have to redo architectures already-in-place so long as they’re fit for purpose. You can evolve ESA over time.
Call to Action
At Security Architects Partners, we’re all about architecture, but we help customers take a pragmatic approach. Take a look at our service catalog and specifically the Architecture Improvement section to see how we might be able to come in and solve a pressing problem you already have. Contact us, and learn just how to solve your immediate security challenges while being secure in knowing that you’re on the way to ESA.
The post Pathways to an Enterprise Security Architecture (ESA) appeared first on Security Architects Partners.