Bene Gesserit Urgent Care Offices (BGUC) - Conceptual Security 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 14, 2023

Bene Gesserit Urgent Care Offices (BGUC) - Conceptual Security Architecture

Bene Gesserit Urgent Care (BGUC) has been using the Sherwood Applied Business Security

Architecture (SABSA) framework to drive the development of its employee and patient portals. The

SABSA is founded on the concept that each security function should be directly connected to a business

goal and consists of five layers that are overlapped with a sixth layer. Now that BGUC has completed its

contextual security architecture, where the focus was on what business requirements need to be met, it

can move onto developing its conceptual security architecture, where the focus is on creating the vision

for the project and describing the security principals that will be used (Sherwood et al., n.d.). BGUC has

broken down its contextual security architecture into the enterprise architecture and the application

architecture and outlined the key considerations in this architectural layer (the scope, the strategic plan,

the requirements/specifications, the system boundaries, the system constraints, security, and, in the

case of the application architecture only, the development and release process) while taking into account

its existing capabilities, risk management, and strategic planning.

Enterprise Architecture (Network & System Architecture)

Scope

The scope of the enterprise security architecture consists of the administrative, procedural, and

technical decisions and controls used to secure that specific aspect of the enterprise (Moyle & Kelley,

2020). BGUC’s EISA has two key components: the employee portal and the patient portal. The employee

portal needs to facilitate the flow of patient information between the various departments of BGUC and

the completion of administrative tasks such as scheduling and taking payment whereas the patient

portal needs to update and make available a limited amount of real-time data from BGUC and provide

information and communication services. The portals will be developed concurrently; however, the

specific timing of the portals will be formatted such that the employee portal is developed and

implemented prior to the implementation of the patient portal.

Formal Strategic Plan

The development of the employee portal and patient portal will focus first on the creation of the

critical services, followed by the non-critical services, and finally the value-added services. Upon the

completion of critical services, the employee portal will be made available to employees for use. The

non-critical services and the value-added services will be developed concurrently; however, the

non-critical services will be allocated more resources to ensure that it is completed within one year of

the final completion of the critical services.

Critical services are those that are necessary to the daily operations of the BGUC. These services

include the storage of patient information, transfer of patient information between the different BGUC

departments, the ability to place orders for subscriptions with pharmacies, and the ability to take

payment from patients. These services also pose the highest degree of risk to BGUC due to the sensitive

nature of the data and the transfer of such data to external sources, so the the ISO 31000 standard will

be used to identify, analyze, evaluate, treat, monitor, and review potential risks; however, full compliance

with such standard will not be a requirement for the completion of this project (ABCA, n.d.). The existing

BGUC employee portal access credentials and data security policies and procedures will be utilized in the

development of these services. The non-critical services include the integration of the existing BGUC

equipment and software with the employee portal, the scheduling platform, and the automation of

administrative tasks. The patient portal is a value-added service focused on providing customers an easy

way to schedule their appointments and find general information about doctors, the types of services

BGUC provides, and what to expect at your appointment.

Requirements Specifications

Within the above outlined scope, the EISA must accomplish certain specific control objectives in

order to functionally fulfill BGUC’s business objectives (Sherwood, 2005) of maximizing the trust granted
 4

by patients and industry partners and maintaining compliance with legal and regulatory requirements

under US law (Office For Civil Rights [OCR], 2021). To these ends, BGUC’s EISA must be access controlled,

confidential, reliable, and provide for the positive attribution of actions and messages within the system.

The new EISA can utilize the existing human resources management and information technology joint

framework for tightly controlling the roles and permissions granted to employees as they change

employment status with BUGC. Due to the high volume of clients’ privileged health information, the EISA

will be required to handle, ensuring controls to protect data confidentiality is one of the most critical

business attributes. To achieve this end, the system should incorporate cryptography to protect data

both at rest and in transit within the confines of the system. Moreover, the system must further use

cryptography in digital signature applications to ensure proper attribution.

System Boundaries

The BGUC enterprise architecture will need to include Electronic Health Records (EHRs),

diagnostics from medical devices, human resources, appointment scheduling software, invoicing, and

secure intra-network and inter-network communications. EHRs will need to be accessible from both the

patient and provider portals, allowing patients to view only their own information while allowing

providers to view the information of all of their patients. Medical equipment in BGUC facilities will need

to be separately and distinctly accessible by various types of system users. Medical technicians will

require connection to those devices to operate them for patient care, medical providers must be able to

connect to both real-time and log data from these devices for analysis, and IT professionals will require

limited access to verify device configurations and installation of updates. Additional system boundaries

will exist within the human resources components of the enterprise architecture, but the new

architecture will be able to leverage the existing human resources software which already exist and allow
 5

employees to schedule shifts and serve as the connection point for the company’s network to the

third-party payroll management vendor.

Another major boundary for the EISA will be with the invoicing system. This portion of the

enterprise architecture will require secure connection to health insurance providers, patients, local

pharmacies, and will also need to be capable of handling secure electronic payments in accordance with

PCI DSS standards.

System Constraints

While BGUC desires a new EISA that will allow the company to better achieve its business goals,

the new system must not exceed the bounds of BGUC’s need or cause harm to the business goal in the

interim. BGUC provides critical medical care to hundreds of patients in the local region and cannot afford

to have disruption of any existing services while the new system is under development. Additionally,

BGUC has a maximum budget of $150,000 to devote to the development of the new system and has a

desired delivery timeline of 12-months. Furthermore, the final product for BGUC’s EISA must be able to

meet and prove compliance with the legal and industry standards of HIPAA, HITECH, PCI DSS, and HL7.

The final major constraint for this project is that the EISA must be compatible with all of the legacy

medical devices currently owned by BGUC.

Security

The security of the Enterprise Architecture network and system will be a cloud-based version of

the zero-trust security model. This model assumes that, by default, all users and devices are not

trustworthy and will be given the least-privileged access that is necessary, thereby reducing the risk of

unauthorized lateral movement through a system (Palo Alto Networks, n.d.). To further ensure that

access to and across the network is appropriately restricted, the system shall require initial user account
 6

set-up to be verified with multiple factors that can be independently verified and attributed to an

individual, such as SSN or driver’s license number. After initial account creation, the system shall enforce

minimum password complexity requirements and multifactor authentication (MFA).

The EISA will also take into account the physical security of the various components that are not

housed by third-party cloud service providers and establish thorough scanning and patching regimens for

these devices. BGUC currently owns and operates numerous IOT devices including various medical

testing and caregiving devices that require bluetooth, wireless, or hardwired connections to the network

for patient data collection and medical diagnosis. The enterprise architecture must provide physical

security for these devices to prevent unwanted interference or inadvertent disclosure of privileged

health information in unprotected channels.

Application Architecture

Scope

The application architecture scope focuses on the architecture of the application. It needs to

account for the varying levels of exposure it may have and the numerous environments that it may run

on. This scope addresses the development and release process, components and services, team and

organizational boundaries, and technological considerations (Moyle & Kelley, 2020).

BGUC will utilize the Agile software development life cycle model, which divides the project into

short iterations while still allowing for flexibility throughout the development process. This model will be

beneficial for BGUC because it will enable BGUC to allow for a fast release of the critical services and

then later add on the non-critical and value-added services (Existek, 2017). For the patient portal, BGUC

will utilize the representational state transfer (REST) architectural style as its employees are already

familiar with many of its key components such as secure sockets layer encryption (Doyle, 2021). The

architecture of the system will require the involvement of medical employees and its administrative staff
 7

in the development and operation of the application. The two portals will be based on a cloud server in a

format similar to what is outlined below:

Figure 1. Application Architecture (Marcu et al., 2017).

Formal Strategic Plan

The application architecture plan requires the creation of four different roles/teams: the solution

architect, the cloud architect, the developers, and the operations team. The solution architect will design

the overarching application structure in alignment with the scope outlined above and ensure alignment

with BGUC's business objectives which will then be implemented by the developers through the writing

of code. The cloud architect will identify the cloud platform and oversee the integration of the cloud

services while the operations team will handle the deployment, monitoring, and maintenance of the

application with the selected cloud platform. A microservices architecture pattern will be utilized to

allow for scalability and flexibility throughout the design and deployment stages and to allow for parallel
 8

development of the employee and patient portals. A relational database will be created to allow for

interconnection between BGUC's multiple informational systems. Authentication and authorization

mechanisms, real-time synchronization mechanisms, data backups, data partitioning, and cloud

monitoring and management tools will also be developed (Oracle, 2023).

Requirements Specifications

The application architecture, deriving from the EISA, requires all of the functional requirements

of the overarching system listed above to include the use of role-based access controls to maintain the

barrier between patient and provider access, the use of cryptography for encryption, and PKI for digital

signatures. The application architecture must also support the ability for secure messaging meeting the

HL7 standard. HL7 is a digital standard for securely transferring health data and messages between

healthcare providers and will be critical for BGUC to communicate between providers, local pharmacies,

and to out-of-network referrals (Orion Health, 2023).

System Boundaries

System boundaries are essential for application architecture and are used to separate software

components from the environment around it. Boundaries define what information goes in and out of a

software component. In simpler terms, a boundary stops one section of the system from having access

to another section of the system. This separation is essential to facilitate system development,

deployment and maintenance. Since access controls in the BGUC system will be role-based, the system

boundaries for the patient and provider portals will need unique boundaries implemented to keep the

EHRs in both portals safe, to maintain both systems’ security, and for several other software component

functions. The application architecture will need to permit patients and providers to access additional
 9

communications methods to allow for video and audio telehealth practice without compromising

security.

System Constraints

With the BGUC portals needing to be developed in under 12 months, time will be a constraint for

the system deployment process. The cost of the system must also be taken into consideration as the

budget may not exceed $150,000. This is important to point out because the system must accommodate

all compliance requirements and industry standards while still meeting the budget constraints. Electronic

Health Records and other compliance standards are constraints that must also be taken into

consideration. With time and financial constraints, the application architecture will also need to take into

account the system requirements and devices that will run the application. Patients and care providers

will both need to be accommodated on devices such as tablets, computers and other IoT devices.

Security

Similar to the EISA, the zero-trust security model will drive the development and approach to

security in the application architecture. BGUC will utilize the NIST 800-207 standards as a foundation for

its authentication requirements (Horowitz, 2023). The network will be broken into multiple classes of

devices and all communications, both internal and external, will be secured. Access will be granted on a

per-session basis and authentication and authorization on one resource will not necessarily grant access

to a different resource. A continuous diagnostics and mitigation (CDM) or one similar to such will be

implemented to monitor all devices, applications, and software (Rose, 2020).

The security of the application shall take into account the different logical components outlined

in Figure 2 below, with a strong focus on the development of a CDM, industry compliance (HIPAA,

HITECH, and PCI DSS), threat intelligence, and data access. BGUC will utilize the enhanced identity
 10

approach, which grants access privileges based on the requestor's identity and assigned attributes as

well as takes into consideration the device used and environmental factors. This will ensure that network

access to enterprise resources is restricted to solely those persons who require access (Rose, 2020).

Finally, application security shall include an audit and software update/upgrade schedule, vulnerability

scanning, backup non-cloud based data storage, network traffic filters, and network segmentation taking

into account the recommended ATT&CK techniques and mitigations set forth in the CIS Community

Defense Model (Center for Internet Security, 2022).

Figure 2. Zero Trust Logical Components (Rose et al., 2020).

Development and Release Process

BGUC will utilize the concept of a release management process for the development of its

application architecture. Establishing the process framework of a release management process will allow

BGUC to seamlessly blend the use of the Agile SDLC for the technical development of the application

while also integrating the business needs of the company to reduce the overall risk (Eby, 2018). One of

the key benefits of this process is it centers on the concept of code management. Code will be managed

in segments and all changes to code will be well documented to ensure as additional features are added

to the application, the experience for users is not diminished (Eby, 2018).
 11

Conclusion

The above conceptual security model for the enterprise and application architecture outlines the

scope, the strategic plan, the requirements/specifications, the system boundaries, the system

constraints, security, and, in the case of the application architecture only, the development and release

process in light of BGUC’s current capabilities, risk management approach, and strategic planning. The

vision of BGUC’s project and the key security principals created in this security layer create the

foundation for the next layer wherein a logical structure that actually can be built will be developed in

the next architecture layer, the logical security architecture (Sherwood et al., n.d.).
 12

References

Anti-bribery Anti-Corruption Center of Excellence (ABAC). (n.d.). Mitigating risks in healthcare: why ISO

31000 certification is vital for effective risk management.

https://abacgroup.com/iso-31000-certification-in-healthcare/

Center for Internet Security. (2022). CIS Community Defense Model: Version 2. CIS Controls.

https://www.cisecurity.org/insights/white-papers/cis-community-defense-model-2-0

Doyle, K., Ferguson, K., & McKenzie, C. (2021, January). REST (REpresentational State Transfer. TechTarget

Network.

https://www.techtarget.com/searchapparchitecture/definition/REST-REpresentational-State-Tra

nsfer

Eby, K. (2018, June 13). Everything you need to know to master release management. Smartsheet.

https://www.smartsheet.com/release-management-process

Existek. (2017, August 4). SDLC Models: Agile, Waterfall, V-shaped, Iterative, Spiral.

https://existek.com/blog/sdlc-models/

Horowitz, B. (2023, February 20). Zero Trust offers a foundation for authentication and access in

healthcare. Health Tech.

https://healthtechmagazine.net/article/2023/02/zero-trust-in-healthcare-perfcon

Marcu, R., Danila, I., Popescu, D., & Chenaru, O. (2017, March). Message queuing model for a healthcare

hybrid cloud computing platform. Studies in Informatics and Control. 26(1): 95-104.

http://dx.doi.org/10.24846/v26i1y201711
 13

Moyle, E., & Kelley, D. (2020). Practical cybersecurity architecture. Packt Publishing.

https://online.vitalsource.com/books/9781838982195

Office For Civil Rights [OCR]. (2021, August 16). HIPAA for Professionals. HHS.gov.

https://www.hhs.gov/hipaa/for-professionals/index.html

Oracle. (2023, September 12). Oracle Cloud Infrastructure Documentation - Application architecture.

https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/ea-application-architect

ure.html

Orion Health. (2023, May 3). What is HL7 and why does healthcare need it?

https://orionhealth.com/us/blog/what-is-hl7-and-why-does-healthcare-need-it/

Palo Alto Networks. (n.d.). What is zero trust for the cloud?

https://www.paloaltonetworks.com/cyberpedia/what-is-a-zero-trust-for-the-cloud

Rose, S. , Borchert, O., Mitchell, S., & Connelly, S. (August, 2020). NIST Special Publication 800-207: Zero

Trust Architecture. U.S. Department of Commerce: National Institute of Standards and

Technology (NIST). https://doi.org/10.6028/NIST.SP.800-207

Sherwood, N. (2005). Enterprise Security Architecture. Taylor & Francis.

https://online.vitalsource.com/books/9781498759908

Sherwood, J., Clark, A. & Lynas, D. (n.d.) Enterprise Security Architecture. SABSA.

file:///C:/Users/aly/Downloads/TSI-W100-SABSA-White-Paper.pdf