Photo: Golden Gate Bridge from Golden Gate Park, San Fransisco, California, August 2018.
The Seven Layers of SABSA Architecture:
Logical Security Architecture:
How the Architectural Layer Relates to the Business & Security Needs:
Identify & Define the Deliverables:
Appropriate Deliverables:
Security Rules:
Practices & Procedures:
The Physical Security Mechanisms:
Applications & User Communities:
Physical Layout of the Platforms & Networks:
Description of the Resilience Model:
Description of the Resilience Model:
Conclusion:
The Seven Layers of SABSA Architecture:
INTRODUCTION
To achieve a holistic approach to creating a secure architectural system one must view the problem set from multiple points of view. The SABSA model layered architecture views allows the creator to approach the problem set from the business view, the architect’s view, the designer’s view, the builder’s view, the tradesman’s view, and the facilities manager’s view. In each view the one must ask the – who, what, where, when, why, and how – this specific view benefits the business, the users, employees, and administrators. By following this model one may be able to take a holistic approach to the creation of a secure architectural system.
THE BUSINESS VIEW
In the business view the owner has a set of business requirements that must be met by the architecture. It is essential that the business requirements for the systems architecture are established, and understanding the requirements is a prerequisite to designing the systems architecture that will meet those requirements. (Sherwood, 2005)
What type of information system is it and for what will it be used? Why will it be used? How will it be used? Who will use it? Where will it be used? When will it be used? (Sherwood, 2005)
THE ARCHITECT’S VIEW
The architect’s view is the overall concept by which the business requirements of the enterprise may be met. This layer defines principles and fundamental concepts that guide the selection and organization of the logical and physical elements at the lower layers of abstraction. (Sherwood, 2005)
What you want to protect in terms of the business profile? Why the protection is important, in terms of control objectives? How you want to achieve the protection, in terms of high-level technical and management security strategies? Who is involved in security management, in terms of entity relationship models, and the trust framework within entities interact with one another? Where you want to achieve the protection conceptualized in terms of security domains? When is the protection relevant, in terms of both points in time and periods of time? (Sherwood, 2005)
THE DESIGNER’S VIEW
The designer has to interpret the architect’s conceptual vision and turn it into a logical structure that can be engineered to create the systems architecture. This view models the business as a system, with system components that are themselves sub-systems. It shows the major architectural security elements in terms of logical security services, and describes the logical flow of control and the relationships between these logical elements. (Sherwood, 2005)
What? Business information is a logical representation of the real business. It is this business information that needs to be secured. Why? Specifying the security policy requirements (high-level security policy, registration authority policy, certification authority policy, physical domain policy, logical domain policies, etc.) for securing business information. How? Specifying the logical security services (entity authentication, confidentiality protection, integrity protection, non-repudiation, system assurance, etc.) and how they fit together as a common re-usable building blocks into a complex security system that meets the overall business requirements. Who? Specifying the entities (users, security administrators, auditors, etc.) and their inter-relationships, attributes, authorized roles and privilege profiles in the form of a schema. Where? Specifying the security domains and inter-domain relationships (logical security domains, physical security domains, security associations). When? Specifying the security processing cycle (registration, certification, login, session management, etc.). (Sherwood, 2005)
THE BUILDER’S VIEW
The designer produces a set of logical abstractions that describe the system to be built. These need to be turned into a physical security architecture model that describes the actual technology model and specifies the functional requirements of the various system components. (Sherwood, 2005)
What? Specifying the business data model and the security-related data structures (tables, messages, pointers, certificates, signatures, etc.). Why? Specifying rules that drive logical decision-making within the system (conditions, practices, procedures and actions). How? Specifying security mechanisms (encryption, access control, digital signatures, virus scanning, etc.) and the physical machines upon which these mechanisms will be hosted. Who? Specifying the people dependency in the form of the users, the applications that they use and the security user interface (screen formats and user interactions). Where? Specifying security technology infrastructure (physical layout of the hardware, software and communications lines). When? Specifying the time dependency in the form of execution control structures (sequences, events, lifetimes and time intervals). (Sherwood, 2005)
THE TRADESMAN’S VIEW
The tradesman works with specialist products and system components that are the equivalent of building materials and components. Some of these trades are hardware-related, some are software-related, and some are service oriented. (Sherwood, 2005)
What? Data field specifications, address specifications and other detailed data structure specifications. Why? Security Standards. How? Products and tools (both hardware and software). Who? User identities, privileges, functions, actions and access control lists (ACLs). Where? Computer processes, node addresses, and inter-process protocols. When? Security step timings and sequencing. (Sherwood, 2005)
THE FACILITIES MANAGER’S VIEW
The job of the facilities manager is to deal with the operation of the building of the system and its various services, maintaining it in good working order, and monitoring how well it is performing in meeting the requirements. (Sherwood, 2005)
What? Ensuring the operational continuity of the business systems and information processing, and maintaining the security of operational business data and information (confidentiality, integrity, availability, auditability, and accountability). Why? To manage operational risks and hence to minimize operational failures and disruptions. How? Performing specialized security-related operations (user security administration, system security administration, data back-ups, security monitoring, emergency response procedures, etc.). Who? Providing operational support for the security-related needs of all users and their applications (business users, operators, administrators, etc.). Where? Maintaining the system integrity and security of all operational platforms and networks (by applying operational security standards and auditing the configuration against these standards). When? Scheduling and executing a timetable of security-related operations. (Sherwood, 2005)
DISCUSSION
The purpose of the SABSA Model Layered Architecture Views is to aid in the creation of a secured architectural system that uses a holistic approach. By using the SABSA model one is able to approach the creation of a secured architectural system from multiple points of view. By conducting a holistic approach one is able to understand the business requirements to accomplish both the short term as well as the long term goals of the company. One can then begin to conceptualize the frame work knowing the requirements of the business. Once the concepts are laid out, one can proceed to the logical security, then to the physical security, component security, and finally operational security. By addressing the security of the architecture through each of these lenses one can claim to have taken a holistic approach. (Sherwood, 2005)
The SABSA model layered architectural views enable the one to take a holistic approach to creating a secure architectural system. It allows the creator to approach the problem set in a contextual security, conceptual security, logical security, physical security, component security, and operational security mindset to create a robust and cost effective solution to a secure architectural system.
To achieve a holistic approach to creating a secure architectural system one must view the problem set from multiple points of view. The SABSA model layered architecture views allows the creator to approach the problem set from the business view, the architect’s view, the designer’s view, the builder’s view, the tradesman’s view, and the facilities manager’s view. In each view the one must ask the – who, what, where, when, why, and how – this specific view benefits the business, the users, employees, and administrators. By following this model one may be able to take a holistic approach to the creation of a secure architectural system.
THE BUSINESS VIEW
In the business view the owner has a set of business requirements that must be met by the architecture. It is essential that the business requirements for the systems architecture are established, and understanding the requirements is a prerequisite to designing the systems architecture that will meet those requirements. (Sherwood, 2005)
What type of information system is it and for what will it be used? Why will it be used? How will it be used? Who will use it? Where will it be used? When will it be used? (Sherwood, 2005)
THE ARCHITECT’S VIEW
The architect’s view is the overall concept by which the business requirements of the enterprise may be met. This layer defines principles and fundamental concepts that guide the selection and organization of the logical and physical elements at the lower layers of abstraction. (Sherwood, 2005)
What you want to protect in terms of the business profile? Why the protection is important, in terms of control objectives? How you want to achieve the protection, in terms of high-level technical and management security strategies? Who is involved in security management, in terms of entity relationship models, and the trust framework within entities interact with one another? Where you want to achieve the protection conceptualized in terms of security domains? When is the protection relevant, in terms of both points in time and periods of time? (Sherwood, 2005)
THE DESIGNER’S VIEW
The designer has to interpret the architect’s conceptual vision and turn it into a logical structure that can be engineered to create the systems architecture. This view models the business as a system, with system components that are themselves sub-systems. It shows the major architectural security elements in terms of logical security services, and describes the logical flow of control and the relationships between these logical elements. (Sherwood, 2005)
What? Business information is a logical representation of the real business. It is this business information that needs to be secured. Why? Specifying the security policy requirements (high-level security policy, registration authority policy, certification authority policy, physical domain policy, logical domain policies, etc.) for securing business information. How? Specifying the logical security services (entity authentication, confidentiality protection, integrity protection, non-repudiation, system assurance, etc.) and how they fit together as a common re-usable building blocks into a complex security system that meets the overall business requirements. Who? Specifying the entities (users, security administrators, auditors, etc.) and their inter-relationships, attributes, authorized roles and privilege profiles in the form of a schema. Where? Specifying the security domains and inter-domain relationships (logical security domains, physical security domains, security associations). When? Specifying the security processing cycle (registration, certification, login, session management, etc.). (Sherwood, 2005)
THE BUILDER’S VIEW
The designer produces a set of logical abstractions that describe the system to be built. These need to be turned into a physical security architecture model that describes the actual technology model and specifies the functional requirements of the various system components. (Sherwood, 2005)
What? Specifying the business data model and the security-related data structures (tables, messages, pointers, certificates, signatures, etc.). Why? Specifying rules that drive logical decision-making within the system (conditions, practices, procedures and actions). How? Specifying security mechanisms (encryption, access control, digital signatures, virus scanning, etc.) and the physical machines upon which these mechanisms will be hosted. Who? Specifying the people dependency in the form of the users, the applications that they use and the security user interface (screen formats and user interactions). Where? Specifying security technology infrastructure (physical layout of the hardware, software and communications lines). When? Specifying the time dependency in the form of execution control structures (sequences, events, lifetimes and time intervals). (Sherwood, 2005)
THE TRADESMAN’S VIEW
The tradesman works with specialist products and system components that are the equivalent of building materials and components. Some of these trades are hardware-related, some are software-related, and some are service oriented. (Sherwood, 2005)
What? Data field specifications, address specifications and other detailed data structure specifications. Why? Security Standards. How? Products and tools (both hardware and software). Who? User identities, privileges, functions, actions and access control lists (ACLs). Where? Computer processes, node addresses, and inter-process protocols. When? Security step timings and sequencing. (Sherwood, 2005)
THE FACILITIES MANAGER’S VIEW
The job of the facilities manager is to deal with the operation of the building of the system and its various services, maintaining it in good working order, and monitoring how well it is performing in meeting the requirements. (Sherwood, 2005)
What? Ensuring the operational continuity of the business systems and information processing, and maintaining the security of operational business data and information (confidentiality, integrity, availability, auditability, and accountability). Why? To manage operational risks and hence to minimize operational failures and disruptions. How? Performing specialized security-related operations (user security administration, system security administration, data back-ups, security monitoring, emergency response procedures, etc.). Who? Providing operational support for the security-related needs of all users and their applications (business users, operators, administrators, etc.). Where? Maintaining the system integrity and security of all operational platforms and networks (by applying operational security standards and auditing the configuration against these standards). When? Scheduling and executing a timetable of security-related operations. (Sherwood, 2005)
DISCUSSION
The purpose of the SABSA Model Layered Architecture Views is to aid in the creation of a secured architectural system that uses a holistic approach. By using the SABSA model one is able to approach the creation of a secured architectural system from multiple points of view. By conducting a holistic approach one is able to understand the business requirements to accomplish both the short term as well as the long term goals of the company. One can then begin to conceptualize the frame work knowing the requirements of the business. Once the concepts are laid out, one can proceed to the logical security, then to the physical security, component security, and finally operational security. By addressing the security of the architecture through each of these lenses one can claim to have taken a holistic approach. (Sherwood, 2005)
The SABSA model layered architectural views enable the one to take a holistic approach to creating a secure architectural system. It allows the creator to approach the problem set in a contextual security, conceptual security, logical security, physical security, component security, and operational security mindset to create a robust and cost effective solution to a secure architectural system.
Logical Security Architecture:
The external network is comprised of four parts: the remote workers, the providers, the customers, and the off-site backup. The remote workers will access the network through the Virtual Private Network (VPN) via the internet. The VPN will then route the remote workers through the Inner Firewall before being allowed access to the Corporate LAN.
The Providers and the Customers will be required to take a different route to gain access. Via the internet they will first be sent through the Outer Firewall. Once through this first barrier in the DMZ they will be sent through the Web Servers, and finally to the Inner Firewall before being able to gain access to the Corporate LAN.
The Off-site Backup is a segregated site that can only be accessed offline. This ensures the integrity of the information preventing it front being corrupted in the event of an attack on the network.
Once the Remote workers, Providers, and Customers have gained access to the corporate LAN they will be able to gain access to the different departments in the User LAN and the Back-end based upon their user privileges. All users will be able to access certain areas within the departments of Human Resources (HR), Claims Processing, Tech Support, and Corporate. For example, a remote worker may need to access HR in order to file a complaint. All users will have this privilege, however users will not have access to view all complaints filed with the exception of HR and perhaps senior corporate management.
Providers and customers will both have access to claims processing, but they will not have the same privileges. Providers to need to keep track of all claims, and how far along in the processing cycle they are. Customers will have access to their own claims that are being processed, but not of other customers.
Tech support will be able to have access to the Web Servers along with the Inner and Outer Firewalls in order to plug holes and mitigate vulnerabilities.
The last part of the Corporate LAN that I will be addressing is the back-end of the Corporate LAN: the corporate data and the user and provider data. Corporate will be able to access all data on the back-end in order to ensure that the data at rest maintains its integrity. Claims Processing will be required to access only User and provider data to accomplish their tasks. HR will not have access to the user and provider data as it is not within their purview. HR will have access to corporate data in order to keep track of personnel within the company.
The highest priority of this network must be the customer and whether or not they can file a claim efficiently, and the workers can process the customers claim quickly. Since this network is from a Medical Center it is necessary that the patient (the customer) is given the highest priority. Furthermore, corporate must ensure the data integrity of the users, the provider, and the customers. The customers PII and PHI must always be handled following current Hipaa laws.
The Providers and the Customers will be required to take a different route to gain access. Via the internet they will first be sent through the Outer Firewall. Once through this first barrier in the DMZ they will be sent through the Web Servers, and finally to the Inner Firewall before being able to gain access to the Corporate LAN.
The Off-site Backup is a segregated site that can only be accessed offline. This ensures the integrity of the information preventing it front being corrupted in the event of an attack on the network.
Once the Remote workers, Providers, and Customers have gained access to the corporate LAN they will be able to gain access to the different departments in the User LAN and the Back-end based upon their user privileges. All users will be able to access certain areas within the departments of Human Resources (HR), Claims Processing, Tech Support, and Corporate. For example, a remote worker may need to access HR in order to file a complaint. All users will have this privilege, however users will not have access to view all complaints filed with the exception of HR and perhaps senior corporate management.
Providers and customers will both have access to claims processing, but they will not have the same privileges. Providers to need to keep track of all claims, and how far along in the processing cycle they are. Customers will have access to their own claims that are being processed, but not of other customers.
Tech support will be able to have access to the Web Servers along with the Inner and Outer Firewalls in order to plug holes and mitigate vulnerabilities.
The last part of the Corporate LAN that I will be addressing is the back-end of the Corporate LAN: the corporate data and the user and provider data. Corporate will be able to access all data on the back-end in order to ensure that the data at rest maintains its integrity. Claims Processing will be required to access only User and provider data to accomplish their tasks. HR will not have access to the user and provider data as it is not within their purview. HR will have access to corporate data in order to keep track of personnel within the company.
The highest priority of this network must be the customer and whether or not they can file a claim efficiently, and the workers can process the customers claim quickly. Since this network is from a Medical Center it is necessary that the patient (the customer) is given the highest priority. Furthermore, corporate must ensure the data integrity of the users, the provider, and the customers. The customers PII and PHI must always be handled following current Hipaa laws.
How the Architectural Layer Relates to the Business & Security Needs:
The business needs of the Department of Defense (DoD) can be summed up by asking the question: How can the government better protect its military assets? To answer this question one must address the Physical Security Equipment (PSE) Research, Development, Test and Evaluation (RDT&E) within the DoD. In developing a joint PSE architecture embraced by all of the armed services, the primary goal envisions security systems with shortened and less costly acquisition and development phases, minimized duplication, increased service interoperability and interchangeability and easier maintenance. The joint architecture will ensure DoD security systems, for all four military services, integrate with existing systems and with each other and minimize the need for physical redesign. This translates to increased protection against international and domestic threats at a lower cost and in reduced timeframes. (Freiter, 2007)
The security needs presented in the case study include, but are not limited to, Common Infrastructure, Communication, Command, Control, and Display Equipment (CCDE), Access Control, Detection, Surveillance, Delay Denial Response and Power. Adherence to standards will promote interoperability and commonality at every level of force protection. To combat possible future attacks, the DoD is increasing security measures and developing innovative anti-terrorism/force protection (AT/FP) equipment. (Freiter, 2007)
The DoD has developed two specific Interface Control Documents (ICDs). The first ICD describes the communication between a centrally located system known as the CCDE that is used to monitor security alarms and the security situation in a base defense system and the devices originating the alarms or other information. This ICD consists of a series of sub-ICDs that standardize the eXtensible Markup Language (XML) schemas between the CCDE and AT/FP sensor equipment components. The ICD focuses on the communication interface between the CCDE and the detection, surveillance/assessment, access control, delay/denial, mass notification, and response devices including remotely operated weapons. (Freiter, 2007)
The second ICD developed is the CCDE-to-CCDE ICD. This ICD provides various XML schemas for standardizing CCDE to CCDE communications. Compliance with the ICD will ensure multiple CCDEs can effectively share AT/FP information. Standardizing these interfaces increases the interoperability of equipment provided by various vendors and enables a comprehensive integration maximizing benefits in safety, operational and situational awareness, alarm response and costs. (Freiter, 2007)
The security needs presented in the case study include, but are not limited to, Common Infrastructure, Communication, Command, Control, and Display Equipment (CCDE), Access Control, Detection, Surveillance, Delay Denial Response and Power. Adherence to standards will promote interoperability and commonality at every level of force protection. To combat possible future attacks, the DoD is increasing security measures and developing innovative anti-terrorism/force protection (AT/FP) equipment. (Freiter, 2007)
The DoD has developed two specific Interface Control Documents (ICDs). The first ICD describes the communication between a centrally located system known as the CCDE that is used to monitor security alarms and the security situation in a base defense system and the devices originating the alarms or other information. This ICD consists of a series of sub-ICDs that standardize the eXtensible Markup Language (XML) schemas between the CCDE and AT/FP sensor equipment components. The ICD focuses on the communication interface between the CCDE and the detection, surveillance/assessment, access control, delay/denial, mass notification, and response devices including remotely operated weapons. (Freiter, 2007)
The second ICD developed is the CCDE-to-CCDE ICD. This ICD provides various XML schemas for standardizing CCDE to CCDE communications. Compliance with the ICD will ensure multiple CCDEs can effectively share AT/FP information. Standardizing these interfaces increases the interoperability of equipment provided by various vendors and enables a comprehensive integration maximizing benefits in safety, operational and situational awareness, alarm response and costs. (Freiter, 2007)
Identify & Define the Deliverables:
- An updated business data model, describing any new data types required by the security architecture (such as passwords, usernames, certificates, etc.)
- A statement of the security rules, practices and procedures that will be required. At this stage the details of the procedures and practices will not be written. The statement will describe only certain procedures and practices that will be needed to implement the policies defined at the logical layer. Templates for creating these procedures and practices may also be defined here.
- A list of the security mechanisms that will be needed to implement the logical security services from the layer above. Different mechanisms will be used in different contexts for the same services, and an indication of where each selected mechanisms should be used can be defined at this stage. However, the number of security mechanism types should be minimized to avoid complexity and to provide generic, re-usable, modular approaches to the construction of new infrastructure and applications
- A list of applications and user communities, with a security user interface design for each type. In the future, as more applications are added, this may need to be updated. As with the security mechanisms, the number of user interface types should be minimized to avoid complexity and to provide generic, re-usable, modular approaches to the construction of new applications. A user interface module with a defined API would be a good architectural approach.
- The physical layout of the platforms and networks, probably in diagrammatic form. This is a physical representation, defining the number of physical computer boxes, physical communications lines and physical networking equipment items – how many, what type and where.
- A description of the resilience model provided by redundancy of boxes and connections. The resilience model is integral to the physical layout model, providing redundant capacity in resilient configurations
- The control structure execution model needed to execute the logical security processing cycle from the layer above
Appropriate Deliverables:
- Business data model, describing new data types required by the security architecture:
- A statement of the security rules, practices and procedures that will be required:
Security Rules:
- Firewall rules – determine what types of traffic are allowed or disallowed
- Database rules – determine what types of access and what types of actions are allowed or disallowed
- File system rules- make decisions about access to data
Practices & Procedures:
- All security practices and procedures must be within NIST standards
- Applicable to equipment and systems relevant to AT/FP
- Viable relative to industry trends and technology evolutionary directions
- Mature and used by at least three vendors in their product offerings
- Provide one or more required components relative to the needs defined in Operational Views and Systems Views
- Compatible with the overall set of technology being selected (integrates well with other technology standards being selected)
- Support the directions of the DoD: Net-Centric, Service Oriented, Components based, and use of the Global Information Grid
- Not Proprietary
The Physical Security Mechanisms:
Security Services |
Physical Security Mechanisms |
Entity unique naming |
|
Entity Registration |
|
Entity Public Key Certification |
|
Session Authentication |
|
Message Origin Authentication |
|
Message Integrity Protection |
|
Logical Access Control |
|
Audit Trails |
|
Stored Data Confidentiality |
|
Security Provisioning |
|
Security Monitoring |
|
Security Measurements and Metrics |
|
Physical Security |
|
Environmental Security |
|
Software Integrity Protection |
|
Security Monitoring |
|
Intrusion Detection |
|
Security Alarm Management |
|
Audit Trails |
|
Security Operations Management |
|
Security Monitoring |
|
Security Measurements and Metrics |
|
Incident Response |
|
Data Replication and Backup |
|
Software Replication and Backup |
|
Disaster Recovery |
|
Crisis Management |
|
Audit Trails |
|
Security Monitoring |
|
Security Measurements and Metrics |
|
(Sherwood, 2005)
Applications & User Communities:
Logical Security Services |
Physical Security Mechanisms |
Entity Unique Naming |
|
Entity Registration |
|
Physical Security |
|
Environmental Security |
|
Security Alarm Management |
|
Audit Trails |
|
Incident Response |
|
(Sherwood, 2005)
Physical Layout of the Platforms & Networks:
(Heckman, 2017)
Description of the Resilience Model:
- Multiple communications cables and channels with diverse physical routing
- Separation of cable routes from buildings to avoid all the multiple cables suffering the same physical failures
- Alternative telephone exchanges for routing of third-party telco lines from any given site
- Dynamic automated re-routing and re-configuration to create a self-healing network based on a multi-path network of switches and connections
- ISDN or dial-up fallback for leased line connections
- Regular testing and monitoring of these various resiliency features to ensure they are operating correctly
- Duplicate frames and frame-rooms in buildings where external telecommunications lines are terminated and connected into the infrastructure of the building
- Physical and environmental security communications rooms and computer rooms
- Dual processing facilities in separate data centers which are geographically separated by several hundred miles
- Fault-tolerant computer systems with special operating systems or middleware that automatically organizes data monitoring or distributed processing
- RAID configuration for data storage
Description of the Resilience Model:
- Date and time fields embedded in renewable data structures such as certificates. The certificate cannot be used once its expiration date has passed.
- Date and time fields in configuration file that tell you when a control event needs to be executed, with a regular lookup function to compare the current date and time with the event threshold.
- Automated timers that are set running at the opening of a period that has a maximum lifetime. The login session lifetime could be several hours, or an inactivity timeout of several minutes, or a protocol timeout of several seconds.
Conclusion:
The SABSA model layered architectural views enable the one to take a holistic approach to creating a secure architectural system. It allows the creator to approach the problem set in a contextual security, conceptual security, logical security, physical security, component security, and operational security mindset to create a robust and cost effective solution to a secure architectural system.
The physical security architecture is the builder’s view. The builder is the person who takes the logical descriptions and turns them into a technology model that can be used to construct the physical architecture model and the specific functional requirements of the various system components.
The physical security architecture development process is split up into a sub-process called deliverables. The deliverables for the physical layer is meant to implement the logical layer into a physical architectural model. The physical architectural model expresses the logical layer in terms of the physical security mechanisms and machines that will be used to deliver the services. The builder must not allow themselves to become overburdened with the details of each of the mechanisms and machines. The following layer, the component security layer, will assemble teams of Subject Matter Experts to see to the details of the mechanisms and machines the builder has implemented. The deliverables for the physical layer help to ensure that the component security layer has the adequate information to accomplish their tasks.
The physical security architecture is the builder’s view. The builder is the person who takes the logical descriptions and turns them into a technology model that can be used to construct the physical architecture model and the specific functional requirements of the various system components.
The physical security architecture development process is split up into a sub-process called deliverables. The deliverables for the physical layer is meant to implement the logical layer into a physical architectural model. The physical architectural model expresses the logical layer in terms of the physical security mechanisms and machines that will be used to deliver the services. The builder must not allow themselves to become overburdened with the details of each of the mechanisms and machines. The following layer, the component security layer, will assemble teams of Subject Matter Experts to see to the details of the mechanisms and machines the builder has implemented. The deliverables for the physical layer help to ensure that the component security layer has the adequate information to accomplish their tasks.