Assignment 4: Creating the Logical Architecture

Kaitlin Perkins, Michael Soto, and Nicholas Wicker

Program of Cyber Security Operations & Leadership, University of San Diego

CSOL 520-03-SU22: Secure Systems Architecture

Dr. William Hess

June 6, 2022
 1

Table of Contents

Business Information Model........................................................................................................................2

Security Policy Statements....................................................................................................................3
Access Control.......................................................................................................................................4
Acceptable Use.......................................................................................................................................4
Business Continuity...............................................................................................................................4
Disaster Recovery..................................................................................................................................5
Incident Response..................................................................................................................................5
Physical, Environmental, Logical, and Media Protection..................................................................6
Proposed Security Services..........................................................................................................................6
Entity Schema and Privilege Profile.............................................................................................................7
Security Domain Definitions and Associations.............................................................................................9
Security Processing Cycle...........................................................................................................................11
Access Control.....................................................................................................................................11
User Access Management.................................................................................................................11
User Responsibilities.........................................................................................................................12
Application Access Management......................................................................................................12
Acceptable Use.....................................................................................................................................12
Business Continuity.............................................................................................................................13
Disaster Recovery................................................................................................................................13
Incident Response................................................................................................................................14
Physical, Environmental, Logical, and Media Protection................................................................15
Physical.............................................................................................................................................15
Environmental..................................................................................................................................16
Logical..............................................................................................................................................16
Media................................................................................................................................................16
References................................................................................................................................................18
 2

Business Information Model

The business information model (BIM) represents the process flow of G5HC

organizational requirements and its personnel. The model contains entities such as departments

and stakeholders. From the entities, the relationship between departments or processes is shown

to provide clarity on how G5HC conducts its operations. The BIM allows for expansion as

G5HC activates more facilities and grows internally.

Figure 1

Business Information Model (High Level)

 3

Figure 2

Business Information Model (Logical Architecture)

Security Policy Statements

Policies were identified utilizing both the NIST SP 800-53 Risk Management Framework

and NIST SP 800-100 Information Security Handbook: A Guide for Managers. All policies are to

be reviewed annually and updated as needed to safeguard the network, data, and employees. The

policies consider areas of the risk management process such as: Identifying, Protecting,

Detecting, Responding, and Recovering. All policies will be available to G5HC employees and

part of the user agreement and acknowledgment process. Questions or comments regarding

policies can be submitted to the Chief Information Security Officer (CISO).

 4

Access Control  

This Access Control Plan addresses the purpose, scope, roles, responsibilities,

management commitment, coordination among organizational entities, and compliance. This

plan has been disseminated to the CISO and other security risk management personnel. This

document provides users and administrators with continuity of policy and procedures for account

information and management, while the scope is to provide access control information for the

G5HC network services. 

Acceptable Use 

The general criteria used in deciding acceptable use are whether the application is of

benefit to the organization, whether it complies with government laws and regulations, and

whether it does not adversely affect others. The policy provides rules and guidance that

employees must adhere to. For example, no unofficial business on company devices or network

applications such as personal social media accounts or streaming services. The policy outlines

the consequences which can include suspension or revocation of access if a person has been

found to purposely violate user agreements.  

Employees will understand that applications such as internet use outside of work-related

requirements are a privilege and can be subject to disciplinary actions. All users will understand

the magnitude of cyber threats and the primary concern of attacks on health information systems

that store and transmit sensitive data. Acceptable use is a critical layer of defense-in-depth and

protecting G5HC networks and the data.  

Business Continuity 

Information assets are vital to G5HC’s mission and business processes. Therefore,

services provided by the enterprise shall operate effectively without excessive interruption. This
 5

continuity plan establishes comprehensive procedures to recover network services quickly and

effectively following a service disruption. This policy shall assist with restoration actions found

in the Disaster Recovery Plan. This plan does not address the replacement or purchase of new

equipment, short-term disruptions, or loss of data at the onsite facility or the user workstation. 

Since the network utilizes virtual features on a physical system, this document addresses

information system planning and the processes it takes to recover the virtual system (i.e.:

servers). There are three phases of the concept of operations: Activation and Notification,

Recovery, and Reconstitution. All recovery processes will be categorized based on priority to the

mission. 

Disaster Recovery 

This Disaster Recovery Plan (DRP) has been designed to recover G5HC network services

within 24 hours. This plan does not address the replacement or purchase of new equipment,

short-term disruptions, or loss of data at the onsite facility or the user workstation. The DRP is

used to guide an organization's response to a major loss of enterprise capability or damage to its

facilities. The DRP is the second plan needed by the enterprise risk managers and is used when

the organization must recover (at its original facilities) from a loss of capability for hours or days

(CSRC, n.d.). Since G5HC has a mix of physical and cloud-based infrastructure, this recovery

plan focuses on the time and procedures of both physical and virtual environments. This DRP

will also detail how the cloud broker serves as its alternate processing site. 

Incident Response 

The Scope of this policy is to define the guidelines and procedures for incident handling

and response. The guidance contained herein will cover the high-level procedures related to the

Protect, monitoring, Analyzing, Detect, and Responding phases of the Computer Network
 6

Defense (CND) life cycle. An incident is one determined to impact the organization, prompting a

response. This can entail an occurrence that actually or potentially jeopardizes the

confidentiality, integrity, or availability of an information system or the information the system

processes, stores, or transmits or that constitutes a violation or imminent threat of violation of

security policies, security procedures, or acceptable use policies (CSRC, n.d.). 

Physical, Environmental, Logical, and Media Protection  

The physical security program is that part of security concerned with active and passive

measures designed to prevent unauthorized access. These access areas pertain to personnel,

equipment, installations, and information, and are implemented to safeguard against espionage,

sabotage, terrorism, damage, and criminal activity (physical and logical (cyber threats)). Physical

security is a primary responsibility of all personnel, including visitors. This protection plan will

focus on how security control is managed for each environment at individual levels. Media

protection will include authorization to access the data, protection of data via encryption, and

accessibility via multiple authentication factors. 

Proposed Security Services  

  As G5HC is a healthcare organization that will regularly be handling sensitive electronic

patient healthcare information, there is a strong need to implement strong security services to

protect the confidentiality and integrity of such sensitive data. The proposed security services for

our system include the use of Public Key Infrastructure (PKI). PKI can be used for identity

authentication of users, which can prevent unauthorized users from accessing the G5HC

network. It also uses asymmetric encryption, which requires that each user on the network is

issued a set of digital public and private keys which are used to encrypt and exchange data.
 7

Using PKI will require G5HC to issue smart cards, which contain an embedded chip that stores

the digital private and public keys.

Another feature of using PKI and smart cards is that this will also allow for the Identity,

Credential, and Access Management (ICAM) of users on the G5HC network (GSA, n.d.).

Without a smart card, users will not be able to access the G5HC network or resources as our PKI

system will require two-factor authentication. This means that each time a user attempts to

access the G5HC network and resources, they will be required to insert their smart cards into a

specialized reader and will be challenged with a personal identity number (PIN) which is known

as multi-factor authentication. If the user inputs the correct PIN, their identity is authenticated.

Using PKI will also allow for the encryption of sensitive data and prevent unauthorized users

from creating or modifying data on the G5HC network. As mentioned by Singh (n.d.), the

benefits of PKI include:

 Ensuring that there is an established trust among users on the G5HC Network

 Ensuring that data in transit remains confidential

 Guarantees the authenticity of data when transmitted over the network

 Allows for non-repudiation of transactions, which also ensures authentication and

confidentiality of data

Entity Schema and Privilege Profile

The network utilizes an external database that is hosted in the Cloud. Therefore, Azure

Active Directory (AD), will be used to manage the Entity Schema and Privilege Profile. The

Entity Schema and Privilege profile will be designed based on a Role Based Access Control

(RBAC) Model. RBAC is an access control model where users are assigned permissions based

on their role within an organization (Tunggal, 2022). Using this type of access control method,
 8

we can implement the principle of least privilege, where users will only have access to the

minimum amount of data necessary to complete their work based on their role. The RBAC

model allows us to assign one or many roles to users based on their role in the organization. For

example, all employees can be assigned to a “general employee” role that allows all users in this

group to access the G5HC Holiday Calendar which allows them to view the calendar with “read-

only” privileges, meaning that they can view the calendar but cannot modify it. In the same

scenario, there could be an accountant and a doctor that may need privileged access to different

data due to the nature of their jobs. The accountant would need access to financial information,

with privileges to create, read, and modify financial records. The Doctor would need access to

patient medical records with create, read, and modify privileges. Using RBAC, the doctor will

not have rights to the financial role because they are not required for their job, and vice versa for

the accountant.

As shown in Figure 3, an example of the G5HC RBAC is shown. Each role can also

contain subcategories as shown in Figure 3. Using an RBAC model, we can use these

subcategory roles within each role to identify specific roles which will be assigned specific

privileges/permissions within that role. Each of the subcategories within each role can also have

different permissions. For example, if a new user is added, and this user is a nurse, they would be

added to the Medical Practitioner Role which contains a “Nurse” subcategory. The “Nurse”

subcategory may have a limited scope of privileges compared to that of a doctor since their roles

within a healthcare organization are different. For example, a Nurse may only have “read”

privileges when accessing a patient diagnosis file, whereas a doctor can have “create,” “read,”

“update,” and “delete” privileges.

 9

Figure 3

G5HC RBAC Diagram Example

Security Domain Definitions and Associations

The network is comprised of the G5HC facilities' local area network (LAN) and the IaaS

provider, as seen in Figure 4. Physical hardware will live within the G5HC facilities and connect

with the virtualized infrastructure as shown in Figure 4. Figure 5 below displays a diagram of our

application domain.
 10

Figure 4

Network Domain Diagram

The application consists of three components: the people domain, the application domain,

and the information domain, as seen in Figure 5. The people domain is comprised of the

application's users. The application and information domains live on the cloud. For users that fall

under the people domain to access the application domain, they need to access it via a web

application. Identities of users on the people domain will need to be authenticated before gaining

access to the application domain. The application domain will match the users to their authorized

roles and enable the users to perform specific functions. Those roles and functions are then

referencing data stored in the information domain.

 11

Figure 5

Application Domain Diagram

Security Processing Cycle

Access Control

To ensure compliance with the G5HC security policy on access control, we have

established different processes focusing on three areas: user access management, user

responsibilities, and application access management.

User Access Management

G5HC will identify the core users of the system. We consider internal users to be

comprised of G5HC medical professionals, business office personnel, the finance team, and the

IT department. External users would be the IaaS providers and other vendors. Depending on

what a user’s role is within the enterprise, we will impose RBAC to ensure appropriate
 12

permissions to access data are assigned. We will continuously monitor users’ changing roles to

keep permissions secure, as well as provision and remove users’ permissions based on their in-

processing/out-processing status from the enterprise.

User Responsibilities

The success of security is also the responsibility of the user. G5HC will implement

password complexity and enforce a minimum character length for any password requirement

when PKI is not required. A password age policy will require users to change passwords every

90 days, which will also prevent users from reusing two previous passwords consecutively.

Users with smart cards will need to establish a PIN with a minimum length of 6 digits. The

protection of the smart card and PIN will be the responsibility of the cardholder. If smart cards

are lost or stolen, G5HC will invalidate the associated user’s certificates on the lost or stolen card

and issue a new smart card with different certificates. These smart cards will utilize Rivest-

Shamir-Adleman (RSA) encryption.

Application Access Management

Like the security measures in User Access Management, G5HC will require application

access to be based on user permissions. Once the application verifies that the user has the “need-

to-know,” it will then authenticate the accessing user by requesting their passwords and/or smart

card certificates and PIN. We will also enforce “limits on the number of concurrent sessions,

session lock after a period of inactivity, and session termination after a period of inactivity”

(OWASP, 2022).

Acceptable Use

G5HC will host an annual training that defines what we consider acceptable use. This

training will educate its participants on the danger of malware to computer systems and how
 13

malware can be installed “onto your device when you open or download attachments or files or

visit a fraudulent website” (Federal Trade Commission, 2021). All users must complete this

training to be granted and retain access to the G5HC network.

URLs of specific websites, like social media platforms, streaming services, gaming, and

pornography sites, will be added to a list of restricted sites through the browser settings (Wood,

n.d.). Random audits of users’ browser history will be implemented to determine that only

approved websites are being used and computer usage is being used for work-related business.

Privileges to the internet are subject to change based on the behavior of the user.

Business Continuity

G5HC will take and maintain preemptive measures to reduce interruptions to operations.

This will include continually patching all virtual servers and updating operating systems (OS)

and their security protections, like firewalls. Implementation of intrusion detection systems (IDS)

to provide constant monitoring of traffic in and out of the network.

As part of the Activation and Notification phase, G5HC will provide “notification of

contingency personnel when activation occurs, and assessment of the nature of the outage and

severity of the disruption to the system” (Gantz & Philpott, 2013). During the Recovery phase,

“members of the contingency team [will] perform an outage assessment as quickly as possible to

determine the severity of the outage and prepare for and execute the appropriate recovery

procedures” (Gantz & Philpott, 2013). The Reconstitution phase will involve working with our

IaaS providers in restoring system backups from non-affected servers.

Disaster Recovery

G5HC will establish recovery metrics that align with the DRP. The first metric is

Maximum Tolerable Downtime (MTD). According to NIST SP 800-34 Rev. 1 (2010), “the MTD
 14

represents the total amount of time the system owner/authorizing official is willing to accept for

a mission/business process outage or disruption and includes all impact considerations” (p. 17).

G5HC has established an MTD of 24 hours based on how time-sensitive healthcare data can be.

Recovery procedures will be swift to accommodate the 24-hour MTD.

The second metric is Recovery Time Objective (RTO). RTO is “the maximum amount of

time that a system resource can remain unavailable before there is an unacceptable impact on

other system resources, supported mission/business processes, and the MTD” (NIST, 2010, p.

17). Availability of healthcare data is critical to G5HC being able to perform its daily operations

and functions, and without that data, operations can last an hour before the impact is too great.

G5HC will determine the priority order of component, system, and department recoveries to help

guide an efficient recovery process.

The third metric is Recovery Point Objective (RPO). RPO is “the point in time, before a

disruption or system outage, to which mission/business process data can be recovered (given the

most recent backup copy of the data) after an outage” (NIST, 2010, p. 17). Because backups of

data are being stored on the cloud with redundant servers across the nation, the RPO value is

expected to be around 30 to 45 minutes.

Incident Response

G5HC will establish an incident response team and plan to carry out the response to an

incident effectively and efficiently. The main components of our incident response plan will

include identification, containment, eradication, recovery, and lessons learned. The identification

phase will focus on determining the occurrence of an incident. This will involve the review of

“events from various sources such as log files, error messages, and other resources, such

intrusion detection systems, and firewalls, that may produce evidence as to determine whether an
 15

event is an incident” (Kral, 2011, p. 6). During the containment phase, we will isolate the

incident, either by disconnecting it from the network or restricting accessibility, to reduce the

risk of it spreading to other components or parts of the network. G5HC will work closely with

the IaaS providers to work on patching or updating the systems affected by an incident. As part

of recovery, we will slowly re-introduce the new system to ensure that the issue has been

completely removed (Kral, 2011, p.9). Finally, the incident response team will compile all the

notes and milestones of each response phase into an after-action report (AAR). The team will

then present their findings to G5HC personnel and provide a recommendation on improvements

in preparation for the next incident.

Physical, Environmental, Logical, and Media Protection

Physical

To maintain physical security at the medical facility and the cloud provider server

facilities, the following security protection measures will be implemented. For all G5HC

facilities, personnel will need to be granted access to them and provide IDs to authenticate their

identities. Personnel without clearance to enter the premises will need to fill in a visitor’s log.

Security cameras will be placed on the inside and outside of the facilities. For all cloud provider

facilities, they will be responsible to ensure that they are following local laws and are compliant

with all Health Insurance Portability and Accountability Act (HIPAA) requirements. As we will

be using virtual infrastructure to house servers storing sensitive data, like protected health

information (PHI), the cloud vendor will be responsible for ensuring the servers at their facilities

are housed in a secured area with limited personnel access.

 16

Environmental

Environmental threats can pose a risk to the security of information and information

systems. G5HC facilities and IaaS server locations will need to be built to code to withstand their

location’s common natural disasters (i.e.: earthquakes, flash floods, tornados, fires). Should a

natural disaster occur, the cloud vendor will be responsible for maintaining all virtual

infrastructure and will also be responsible for backing up all data stored in the cloud environment

of G5HC. For on-premises hardware at each G5HC facility, backup generators will be installed

on location to supply power during an emergency for at least 96 hours.

Logical

Logical protection will start with implementing the previously mentioned access controls.

Users accessing the network or data will need to provide multi-factor authentication, whether

that be in the form of a password or PIN. Data at rest such as PHI and other sensitive data stored

on the cloud will be encrypted with AES-256 bit, to protect the confidentiality of that data. The

transferring of PHI via emails, for example, will use Secure/Multipurpose Internet Mail

Extensions (S/MIME) encryption to securely transmit the message (HIPAA Journal, n.d.). IDS

will be used to monitor incoming and outgoing traffic of suspicious activities on the network.

Media

If physical copies of medical records or documents need to be produced, that media needs

to be secured. Depending on what information is presented in these newly created documents,

the appropriate classification markings need to be visible. The classification levels used on these

documents will include public, internal-only, confidential, and restricted. Public data is defined

as data that “is freely accessible to the public (i.e., all employees/company personnel)” (Harvey,

2020). Internal-only data is “strictly accessible to internal company personnel or internal

 17

employees who are granted access” (Harvey, 2020). Confidential data could include personally

identifiable information, like a social security number, that “requires specific authorization

and/or clearance” to access (Harvey, 2020). Restricted data is “data that, if compromised or

accessed without authorization, which could lead to criminal charges and massive legal fines or

cause irreparable damage to the company” (Harvey, 2020). Physical security of the media will be

ensured through locked file cabinets within the secured facility.

 18

References

CSRC. (n.d.). Cybersecurity Incident - Glossary. Retrieved June 1, 2022, from

https://csrc.nist.gov/glossary/term/cybersecurity_incident 

CSRC. (n.d.). Disaster Recovery Plan (DRP) - Glossary. CSRC. Retrieved June 1, 2022, from

https://csrc.nist.gov/glossary/term/disaster_recovery_plan

Gantz, S., & Philpott, D. (2013). Contingency Planning. Retrieved on June 5, 2022, from

https://www.sciencedirect.com/topics/computer-science/notification-procedure

GSA. (n.d.). Identity, Credential, and Access Management. GSA. Retrieved June 6, 2022, from

https://www.gsa.gov/policy-regulations/policy/information-integrity-and-access/identity-

credential-and-access-management

HIPAA Journal. (n.d.). HIPAA Encryption Requirements. Retrieved on June 6, 2022, from

https://www.hipaajournal.com/hipaa-encryption-requirements/

Kral, P. (2011). The Incident Handler’s Handbook. [White Paper]. SANS Institute.

https://sansorg.egnyte.com/dl/6Btqoa63at

NIST (2010). Contingency Planning Guide for Federal Information Systems. Retrieved on June

5, 2022, from https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-

34r1.pdf

NIST. (n.d.). Information Security Handbook: A Guide for Managers - NIST. Retrieved June 2,

2022, from https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-

100.pdf 

NIST. (n.d.). Security and Privacy Controls for Information Systems and Organizations - NIST.

Retrieved June 2, 2022, from

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
 19

OWASP. (2022). Access Control. Retrieved on June 4, 2022, from https://owasp.org/www-

community/Access_Control

Singh, H. (n.d.). PKI explained: Public Key Infrastructure. Cyphere. Retrieved June 6, 2022,

from https://thecyphere.com/blog/pki-explained/

Tunggal, A. T. (2022, February 8). What is role-based access control (RBAC)? examples,

benefits, and more: Upguard. RSS. Retrieved June 6, 2022, from

https://www.upguard.com/blog/rbac

Wood, H. (n.d.). How to Block Websites from Employees. Retrieved on June 5, 2022, from

https://smallbusiness.chron.com/block-websites-employees-12326.html