Security Architecture
Security artifacts are valuable tools for maintaining consistency and traceability in security design. Traceability ensures that quality is maintained, helps with mitigating security risks, and manages how changes impact other parts of the system. In making design decisions, organizations need to ensure that each decision supports their planned security goals, and that quality is assured. Potential vulnerabilities could eventually become risks. Organizations need to comprehend the relationships between components so that they could proactively identify and correct potential vulnerabilities. If vulnerabilities are identified or security requirements evolve, traceability helps to manage the impact of change. Before changes are implemented, they must go through a Change Management Control Board where they are either approved or rejected before being documented. Organizations also utilize traceability to help them meet compliance laws. It provides an audit trail showing whether the applicable security measures were followed.
Consistency ensures that across the complete system, protocols, configurations, etc., continue to be uniform. It guarantees predictability and reduced complexity such that expected outcomes are likely, and that security management is simplified due to a consistent approach. With reliable security artifacts, coherency and alignment between the security architecture and the organization goals are ensured. In addition, efficiency increases with a consistent approach to security and leads to a decrease in the likelihood of breaches and a reduction in alerts (Cumbow, 2022). Security artifacts and valuable tools help to ensure that the organizations’ business requirements are met, and integrated security considerations are traceable through the security design lifecycle.
Security Architects must comprehend the business objectives, ensuring that selected security controls are relevant and justifiable for stakeholders. They must adhere to ethical standards such as ensuring that data is accurate and trustworthy, protecting sensitive information, ensuring that needed resources are available, and have respect for individuals’ privacy rights. Lastly, security architects must be cognizant that their role is critical in safeguarding the organization. The safety of data and systems is greatly impacted by the decisions they make.
References:
Cumbow, D. (2022, June 22). The Importance of a Consistent Security Policy. Retrieved from Paloaltonetworks.com: https://www.paloaltonetworks.com/blog/2022/06/the-importance-of-a-consistent-security-policy/
The SABSA Model
The SABSA (Sherwood Applied Business Security Architecture) Model is an enterprise-wide security architecture that takes a holistic approach when addressing complex security needs. It is business-driven and ensures that security decisions are tied to business goals. SABA is comprised of six layers namely, Contextual, Conceptual, Logical, Physical, Component, and Operational (or service management). It ensures a chain of traceability throughout the entire architecture by answering the questions: what would be done, when would it be done, how would it be done, who is going to do it and where would it be done. These questions are asked at each of the layers and provide linkages between the layers.
The Conceptual Security Architecture
For this course, I collaborated with a team, to develop a system for a growing restaurant chain that offered franchising opportunities and utilized services such as a point-of-sale (POS) system, QR codes and mobile apps for self-service ordering. While the franchise chain expressed its desire for service expansion, it was critical for them that invoice flow and just-in-time deliveries were maintained. First, we created a proposal for the software development and provided a brief description for all the entities in the scenario.
With this information, we were able to document:
Enterprise goals and objectives
Organizational success factors
High-level technology and security goals
Technology and security Success factors
Additionally, in the context of business, technology, and cyber security goals, we defined the policies, standards, guidelines, risk appetite and compliance requirements. Using this gathered information, we were able to develop a conceptual model detailing the Enterprise and Application architectures in the context of their existing capabilities, risk management and strategic planning. To complete this paper, we answered six questions. What is it that we want to protect? In terms of the control objectives, why is this protection important? How do we plan to achieve this protection? Who is involved in security management? Where we want to achieve this protection and when is the protection relevant?
Below is a copy of the report for the Conceptual Security Architecture.
The Logical Security Architecture
The Logical Security Architecture takes the output of the Conceptual layer and develops a logical structure which focuses on the functional view of security. It calls attention to the major architectural security elements and specifies a complete set of functional requirements.
Before putting together the report, we reviewed artifacts such as the existing security architecture, components, policies, controls, etc., identified architectural tools to be used, available resources and existing elements which could be reused, and proposed the “raw materials” and documentation needed for security planning, Our report presented the following deliverables:
The Business Information Model showing all functions of the Information System
Security Policy Statements
Proposed Security Services
Entity schema and privilege profile
Security domain definitions and associations
Security processing cycle
Below is a copy of the report for the Logical Security Architecture.
The Physical Security Architecture
This architecture, also known as the builder’s view, takes the blueprint and logical descriptions from the Logical Security Architecture, and converts them into the technology model that will be used to build the system. Here, the inter-relationship between the technical and procedural solutions to support long-term business needs are described. In compiling our report, we delivered:
The Business Data Model and the security-related Data Structures
Security rules, practices, and procedures
Security mechanisms such as cryptography, access control, digital signatures, etc.
Users, applications, user interface (screen formats and user interactions, access control systems)
Platform and network infrastructure
Control structure execution (timing and sequencing of processes and execution)
Below is a copy of the report for the Physical Security Architecture.
The Component Security Architecture
Based on the output from the previous layer, teams with integration skills, skills on products from specialist vendors, and various skills sets are assembled to collaborate, interacting with specialist products and system components. Such components include hardware and software items, interface specifications and standards. For this report, we delivered:
Detailed Data Structures including data repositories and processors.
Security Standards including risk-management related tools and products.
Security Products and tools.
Identities, job descriptions, roles, functions, actions, and access control lists.
Processes, nodes, addresses and protocols.
Security step timing and sequencing
Below is a copy of the report for the Component Security Architecture.
Operations
The Operational Security Architecture or the Facilities Manager’s View is responsible for the security-related operations of the system. With its focus on securing business systems, it details the procedures, processes, actions, and methods that are used for business systems to operate in a secure manner. This view interacts with each of the five other layers in a detailed way. It ensures operational continuity, provides operational support for security related needs, manages operational risks, performs specialized security related operations, maintains system integrity and security and schedules security related operations.
For this report, we delivered:
Assurance of Operational Continuity
Operational Risk Management
Security Service Management and Support
Application and User Management Support
Security of Sites and Platforms
Security Operations Schedule
Below is a copy of the report for the Management Security Architecture.
Reflection
When I started this course, I did not know what to expect. Never before have I used a security Framework or worked on any Enterprise Security Architecture. This forced me to do extra reading to fully understand what was expected. As we went through the layers, I started to grasp the concepts which assisted my team and me to develop the add-on for the proposed franchise chain. While I have done software development requirements and implemented traceability matrices, implementing this Framework was different. This SABA Framework teaches one to take a comprehensive approach towards the development of an enterprise security architecture. I would compare it to an “etch a sketch” where, at the top layer the outline of the picture is drawn and as the layers are traversed, the picture slowly develops in the outline. It forces one to think about consistency and efficiency when considering the integration of different solutions. Each layer of the SABSA Framework accommodates varying views of security while maintaining traceability. This model emphasizes alignment with business goals, allowing a security professional to create justified security solutions.
I chose the selected artifacts because they reflect what needs to be done at each layer when contemplating a security solution. Additionally, the artifacts depict how the solution must align with the business goals. As I traversed through the Framework, decomposing the layers, I learned how important it is to take a strategic approach when developing security solutions. The SABSA model not only ensures completeness, but also provides justification for the components in the security solution, and this is illustrated in the selected artifacts.
While I do not envisage using this Framework or my newly acquired skills soon, this course has taught me to think differently when modifying or adjusting security solutions.