Bene Gesserit Urgent Care Offices (BGUC) - Physical Architecture

James Reynolds, Quincey Jackson, & Aly Malak

Department of Cyber Security, University of San Diego

CSOL-520: Enterprise Security Architecture

Professor Michelle Moore, Ph.D

November 27, 2023

 Bene Gesserit Urgent Care Offices (BGUC) - Physical Architecture

Bene Gesserit Urgent Care (BGUC) plans to continue utilizing the Sherwood Applied Business
Security Architecture (SABSA) framework, which focuses on connecting each security function to a
business goal, to drive the development of its employee and patient portals. The BGUC logical security
architecture described the key documentation, security controls and processes, and entities and their
attributes that will be used to achieve the security principals created in the conceptual security layer.
This physical architecture outlines how the concepts described in the logical security layer can be turned
into a real life construction (Sherwood et al., 2009).

Business Data Model

Progressing to the physical architectural phase of designing an enterprise architecture, BGUC
must develop a Business Data Model from the previously generated Business Information Model with
updates that include the security-related data structures required at the physical level (Sherwood et al.,
2009). This step is accomplished by translating the entity schema into tables identifying the types of raw
data of which they will consist and annotating the relationships between the various groups (Suszterova,
2023). Figure 1 below depicts the overarching Business Data Model diagram for BGUC as supplemented
by the below description.

Figure 1. BGUC Business Data Model

Relationships
(1) Patient_ → Provider_ : one-to-multiple
(2) Provider_ → Patient_: one-to-multiple
(3) ExperienceEvent_ → Provider_: one-to-multiple
(4) ExperienceEvent_ → Patient_: one-to-one
 (5) Patient_ → MedicalRecord_: one-to-multiple
(6) MedicalRecord_ → Patient_: one-to-one
(7) Payee_ → Patient_: one-to-one
All encrypted in transit communications must have authenticated digital signatures as a
condition gate for allowing the transmission of the message.

Security Rules, Practices, and Procedures

The security policies from the logical security architectural layer need to be turned into security
rules, practice and procedures that can be carried out. Rules are “a specific filter against which
automated decisions are made by security sub-systems,” whereas practices and procedures are general
descriptions of how to accomplish BGUC’s goal and step-by-step instructions on how to perform a
specific task, respectively (Sherwood et al., 2005). Below are the recommended rules, practices and
procedures for BGUC:
(1) Firewall Rules: Determine the inbound and outbound traffic allowed or blocked across BGUC’s
network. Must be programmed to work with the established access control lists (ACLs). Needs to
include access rule (grants inbound/outbound traffic based on pre-set conditions), network
address translation (NAT) rule (protects private network by hiding original IP address),
application level gateways (enables administrators to implement protective policies across the
network), and circle-level gateways (monitors TCP handshakes to determine legitimacy)
(AlgoSec, n.d.).
(2) Database Rules: Rules for how databases will be structured and the record locking mechanisms
at each level of the database(s). Sets the database backup checkpoints and the use of structure
query language (SQL) to implement the security mechanisms discussed below (Sherwood et al.,
2005).
(3) File System Rules: Establishes the manner in which files may be accessed, deleted, copied, or
stored. Must account for the different forms of files, including, but not limited to, audio, video,
pictures, documents, and database files. Requires the implementation of one or many of the
following: strong passwords and multifactor authentication (MFA), ACLs, and file monitoring
(Brook, 2023).
(4) Third Party Access Practices: Outline key questions and considerations when granting third party
access to BGUC’s systems, including who will be accessing, who will be responsible for
overseeing such access, what will be accessed, why it needs to be access, in order to assess the
impact on BGUC’s systems if there is a problem resulting for such access and the risk posed to
data privacy and integrity of any data accessed. Discuss the manner in which to manage third
party access (e.g., through MFA), verify the identity of those accessing the systems, granting
least-privilege access rights, and vet third party’s, including their security systems and
procedures if their system is linking into BGUC’s, prior to granting access (Imprivata, 2023).
(5) Security Audit Procedure: Steps on how to perform a comprehensive security audit and targeted
security audits, such as software updates, penetration testing, vulnerability scanning, and
network security. Specifies the frequency of each audit, what materials need to be gathered
 prior to the audit, the roles and responsibilities of each person during the audit, how the audit
will be conducted at each phase, and the manner in which the post-audit review will be
conducted and response for future action determined (Chipeta, 2023).
(6) Incident Response Procedures: Incident specific steps to follow after a specific type of security
event occurs, such as Denial-of-Service attack, phishing or smishing, malware, or virus. Includes
detailed information on preparation, identification, containment, eradication, and recovery for
each type of incident as well as what each role will do, when security incidents need to be
disclosed under data privacy, data breach, and/or SEC laws, and when and who to communicate
with during and after an incident and the frequency of communication (Cranford, 2023).

Security Mechanisms
Security mechanisms are the physical ways that the previously established logical security
services will be implemented (Sherwood et al., 2005). The following security mechanisms are
recommended given BGUC’s previously proposed security services:
(1) Access Control Lists (ACLs): Specifies who has access to what information and what they can do
with such access. Based upon the role of the person and their job duties. Access will be provided
on a need to know basis in order to fulfill job functions (Brooks, 2023).
(2) Data encryption (rest & in transit): Encryption makes it more difficult for attackers to decipher
information in the event they ever gain access to BGUC’s data. BGUC should encrypt any
protected health information (PHI), electronic PHI, personal and sensitive information, and
payment information (Lord, 2020), and its devices that will have access to such information, such
as laptops and medical software (Sarkar, 2023).
(3) Physical Access Controls to Data Servers: Entry into the room with BGUC’s servers and key
hardware will require the correct access credentials. Credentials will only be granted to those
who have a need to access such assets. Third party access to these systems will require the
presence of an authorized employee (IBM, n.d.).
(4) Hashing: Hash functions, such as SHA-1, 2 or 256 (CISA, 2021), will be used to protect message
integrity, authenticate messages, and protect and maintain the integrity of stored data
(Sherwood et al., 2005).
(5) Digital Signatures: Used to help ensure the authenticity and integrity of data. Will require the use
of hashing and asymmetric encryption in order to encrypt and decrypt messages (CISA, 2021).
(6) Virus & Malware Scanning: BGUC will implement antivirus and antimalware software. These
softwares will help protect against viruses and malware, identify, remove, and/or stop malicious
activity (Panda Security, 2020). Virus and malware scanning will be performed on an ongoing
basis.
(7) Public Key Encryption (aka - asymmetric encryption): Requires the setting up for a public key and
private key. This will be used for most data transfers and sharing as it provides confidentiality,
authenticity, and non-repudiation (Gluttony777, 2023).
 (8) Private Key Encryption: Only requires the set-up of a private key. This will be used only for larger
transfers of data and only with internally pre-approved recipients because it only accounts for
confidentiality (Glunttony777, 2023).
(9) Passwords: Each user will be required to have a password to login into the portal. Passwords
must meet the dictated criteria, which will include, at minimum, a minimum password length,
inability to use common phrases/words, and the inclusion of at least one special character,
capital and lowercase letter (each), and number.
(10)Authentication Protocols: Authentication exchange protocols and authentication server systems
(e.g., multi-factor authentication) will be required to authenticate the entity requesting the
information (Sherwood et al., 2005).
(11)Asset Removal/Disposal/Reuse: Assets will be removed off-site only when they are at end-of-life
and/or no longer function properly. Appropriate purge processes will be following, such as NIST
800-88, will be followed prior to the reuse or disposal of any BGUC equipment or assets (IBM,
n.d.).
(12)Training: Provided to teach employees on how to best identify and disclose potential security
issues to the cyber security team. To be updated and completed no less than once per year.

Users, Applications, and User Interface

According to the SABSA model, when designing the physical security architecture for an
enterprise it is critical to identify the “who” for this level in terms of users, applications, and user
interfaces (Sherwood et al., 2009).
(1) Users
Patients: These users must be able to access Electronic Health Records (EHRs), schedule
appointments, communicate securely with providers, and make payments via the Patient Portal
Providers: These users must be able to access and update patient EHRs, communicate securely
with patients, and schedule work hours via the Provider Portal.
Staff: These users must be able to schedule appointments on behalf of patients, process
payments, and schedule work hours via the Provider Portal.
IT Administrators: These users must be able to view audit logs, manage user lists, and assign
roles to users via the Provider Portal.
(2) Applications
Electronic Health Records: Contains records of all past appointments, diagnoses, allergies, and
medications for a given patient (Office of the National Coordinator for Health Information
Technology, n.d.). Access controls should limit EHR access to the associated patient and only
providers with active events with such patient.
Patient Scheduling: Used for coordinating a physical meeting between one patient and one
provider at a specified date, time, and location. Staff and providers should be able to make
changes in this application through the Provider Portal and patients through the Patient Portal.
 Provider/Staff Scheduling: Used for scheduling in office time for both staff and providers. This
should be linked to the Patient Scheduling application. This application should only be accessible
through the Provider Portal and access controls should limit users to making changes to their
own schedules.
Payment Processing: Consists of three distinct features: (i) patients should be able to access a
feature to provide payment information and make payments for services rendered through the
Patient Portal; (2) staff should be able to access this application through the Provider Portal to
create invoices for patients; and (3) staff and providers should be able to access a separate
function of this application through the Provider Portal for verifying and updating their payroll
information.
(3) User Interfaces
Desktop: BGUC requires the Patient Portal and Provider Portal interfaces for desktop computer
usage. These interfaces should provide for user login via username (PatientID, PayeeID,
ProviderID), a secure password meeting the complexity requirements set forth in organizational
policy, and an additional piece of information for MFA. The versions of the portals must also
feature a timeout feature to log off users who exceed a minimum threshold time without
detectable activity to ensure physical security is maintained and the secure messaging
functionality should resemble email to maximize usability of the feature.
Mobile: BGUC requires that the Patient Portal and Provider Portal can interface for mobile
computer usage. These interfaces should provide for user login via username (PatientID,
PayeeID, ProviderID), a secure password meeting the complexity requirements set forth in
organizational policy, and an additional piece of information for MFA. In the mobile version, the
secure messaging feature should resemble that of other mobile-based messaging systems to
ensure user functionality.

Platform and Network Infrastructure

BGUC will use two main platforms for its platform and network infrastructure. One platform will
have the necessary hardware and controls for patients and the other platform will have the necessary
hardware and controls for stakeholders, physicians and care providers. The platform and network
infrastructure need to be built such that they are resilient, can perform in accordance with the type and
volume of data that is being transmitted, and have adequate platform and hardware security given the
applications, operating system, and physical controls being used and available to BGUC (Sherwood et al.,
2005). The figure below is of the 36- cell SABSA Matrix that includes the physical components (where) of
Platform and Network Infrastructure.
 Figure 2: SABSA 36-Cell Matrix that helps define the physical location of Platform and Network
Infrastructure (Sherwood et. al, 2005).
Some of the main principles of resilient infrastructure design are:
(1) Redundancy of Hard Physical Components: If one component fails, then another can take its
place. Important data and systems will be stored in multiple locations on site in case one is
damaged or goes down (Sherwood et al., 2005).
(2) Avoiding Single Points of Failure: Have alternative mechanisms and systems available on the
BGUC network that can perform the same duties as other mechanisms. If one mechanism fails,
another can take over (Sherwood et al., 2005).
(3) Automated Recovery and Reconfiguration: Computers and servers on the network will be
capable of routinely recovering and reconfiguring themselves without the need for physical
operation. Aids departments that are located in different geographic locations at a given BGUC
facility (Sherwood et. al, 2005).
BGUC will leverage the following approaches based on research conducted by Sherwood et. al, to create
network topology resilience and platform resilience:
(4) Use Multiple Communication Channels: Includes multiple communication cables and channels
with diverse physical routing which ensures that it will not not depend on one primary channel
for communication. In the event that one channel is down, BGUC will be able to communicate
with alternatively routed cables and channels (Sherwood et al., 2005).
(5) Physical and Environmental Security: Implementation of security controls to protect rooms and
areas of BGUC locations that store computer servers, systems and devices (Sherwood et al.,
2005).
 (6) Regular Testing and Monitoring: Regular testing and updating of features that have been
implemented will create resiliency in the system and ensure that they are effective. Physical
monitoring will also be required to ensure systems and hardware at BGUC locations are safe
from unauthorized individuals (Sherwood et al., 2005).
(7) Utilizing Fault-Tolerant Computer Systems: Consists of special operating systems or middleware
that organizes data mirroring and distributed processing. Such systems will have the ability to
continue operating without interruption or when one or more of its components fai (Sherwood
et al., 2005)l.
(8) Multiple Data Processing Facilities: Separate data centers and data processing server rooms will
be strategically placed throughout BGUC’s facilities to ensure that the system is functional even
when one or more is down or fails (Sherwood et al., 2005).
Control Structure Execution (specifying the physical time management in terms of the timing and
sequencing of processes and sessions - sequences, events, lifetimes, and time intervals).
The control structure execution are the mechanisms that BGUC will use to enforce the
security-related time and sequence constraints, which is accomplished through the implementation of
different control points (Sherwood et al., 2005). This will include things like:
(1) Date and Time Fields in Configuration Files: Establishes when a control event should be
executed. Control events like antivirus scanning, antimalware scanning, and updates to key
applications will have individual thresholds of when these are to occur. Configuration files will
contain the upcoming date and time when the control event is to occur (Sherwood et al., 2005).
(2) Log-out Timer: Automated timer that begins when one of the specified actions commences and
continues to run for the preset time, after which the control point is triggered and terminates
the current state. Used for long periods of login and/or inactivity (Sherwood et al., 2005).
(3) Data and Time Fields in Digital Signatures & Certificates: Link for requested signatures shall
remain open for only a set period of time. Completed signatures shall contain a date and time
stamp, which shall be used to verify the legitimacy of the signature.
(4) Date and Time Fields for Physical Access: Creates timing constraints for when certain physical
locations containing key BGUC hardware may be accessed.
(5) Password Update: Automated password update reminder will be sent after ninety (90) days has
passed since the last password update. User will have 10 days to update their password since the
original reminder has been sent. If the user has not updated their password in this period, upon
the expiry of the 10 days, the password will expire and user’s access will be terminated until such
time the user updates their password.
Conclusion
The physical architectural layer describes the manner and elements that are required to turn
BGUC’s concepts, controls and processes, and entities and attributes from the logical architecture layer
into a real life construction. The mechanisms and models in this layer will drive the component security
architecture, which assesses what experts, software, tools, standards, and products will need to be
acquired in order to carry out the physical architecture plans (Sherwood et al., 2009).
 References
AlgoSec. (n.d.) Firewall rules & requirements (inbound vs. outbound).
https://www.algosec.com/resources/what-are-firewall-rules/
Brook, C. (2023, October 3). What is file security? Best practices & tools for security. Digital Guardian.

https://www.digitalguardian.com/blog/what-file-security-best-practices-tools-security

Chipeta, C. (2023, October 13). How to perform a cybersecurity audit: a 3-step guide. UpGuard.

https://www.upguard.com/blog/how-to-perform-a-cybersecurity-audit

Cranford, J. (2023, July 7). Incident response plan: frameworks and steps. Crowdstrike.

https://www.crowdstrike.com/cybersecurity-101/incident-response/incident-response-steps/

Cybersecurity & Infrastructure Security Agency (CISA). (2021, February 1). Understanding digital

signatures.

https://www.cisa.gov/news-events/news/understanding-digital-signatures#:~:text=What%20is%

20a%20digital%20signature,%2C%20or%20a%20digital%20document).

IBM. (n.d.). Physical security architecture.

https://www.ibm.com/cloud/architecture/architectures/physical-security-arch

Imprivata. (2023, November 27). Enhancing cybersecurity: why third-party access management is needed

now more than ever.

https://www.imprivata.com/blog/enhancing-cybersecurity-why-third-party-access-management-

needed-now-more-ever

Lord, N. (2020, September 17). Healthcare cybersecurity: tips for securing private health data. Digital

Guardian.

https://www.digitalguardian.com/blog/healthcare-cybersecurity-tips-securing-private-health-dat

Gluttony777. (2023, May 22). Difference between symmetric and asymmetric key encryption. Geeks for

Geeks.
 https://www.geeksforgeeks.org/difference-between-symmetric-and-asymmetric-key-encryption

Office of the National Coordinator for Health Information Technology. (n.d.). What is an

electronic health record (EHR)? HealthIT.gov.

https://www.healthit.gov/faq/what-electronic-health-record-ehr

Panda Security. (2020, August 9). Difference between antivirus and antimalware + do I need both?

https://www.pandasecurity.com/en/mediacenter/difference-between-antivirus-antimalware/

Sarkar, S. (2023). 8 ways to maintain better healthcare information security. Select Hub.

https://www.selecthub.com/medical-software/ehr/5-ways-maintain-healthcare-information-sec

urity/?amp=1

Sherwood, J., Clark, A., & Lynas, D. (2005). Enterprise Security Architecture. Focal Press.

Sherwood, J., Clark, A., & Lynas, D. (2009). Enterprise Security Architecture [White Paper]. SABSA

Institute.

https://sabsacourses.com/wp-content/uploads/2021/02/TSI-W100-SABSA-White-Paper.pdf

Suszterova, S. (2023, March 7). Physical Data Model vs. Logical Data Model. GoodData.

https://www.gooddata.com/blog/physical-vs-logical-data-model/