1

Module 7 - Final Project

Jessica Romio
University of San Diego
CSOL 510
 2

Table of Contents
Executive Summary....................................................................................................................................... 3
Physical Security............................................................................................................................................ 3
Cryptographic Techniques ............................................................................................................................ 4
Confidentiality ........................................................................................................................................... 4
Data Integrity ............................................................................................................................................ 5
Public Key Cryptography ........................................................................................................................... 6
User Authentication .................................................................................................................................. 7
Public Key Infrastructure........................................................................................................................... 7
Conclusion ..................................................................................................................................................... 8
References .................................................................................................................................................. 10
Appendix ..................................................................................................................................................... 13
 3

Executive Summary
Being that we are a health insurance company with a large, distributed network, there are many
regulations we must comply with to keep the information of our customers and employees safe. Besides
the typical laws we must follow to keep our data safe, we must follow more stringent laws that pertain
specifically to personally identifiable information (PII) as well as health information. While the network
architecture is designed with security in mind, firewalls and virtual private networks (VPNs), there are
many additional physical controls and cryptographic techniques that I have suggested to improve the
security posture of the network and to ensure that it complies with the necessary laws and regulations.
Some of the techniques I have suggested are using a hashing algorithm for data integrity, using public
key cryptography for confidentiality, Kerberos for user authentication, and using public key
infrastructure (PKI). The company runs the risk of not complying with acts such as the Health Insurance
Portability and Accountability Act (HIPAA) and The Health Information Technology for Economic and
Clinical Health (HITECH) Act if they do not implement the suggested techniques and could even run the
risk of allowing adversaries to access the personal information of our customers and employees. The
rest of this report will explain the suggested security techniques to implement on the network and the
regulations that recommend them. Throughout the paper I will reference numbers in the network
architecture to help depict where these methods should be implemented. Please see the appendix for
the network diagram and where these numbers are located in the network architecture.

Physical Security
While the cryptographic controls are very important for security, there are additional security
controls that are necessary as well to truly provide security. Some cryptographic controls would be
rendered useless if an adversary had physical access to destroy the system. The following will address
some of the non-cryptographic controls that are essential or recommended for the security of the
network.

Physical controls are important because they protect the systems from being tampered with, or
destroyed, by someone malicious. The web servers and data servers are the most susceptible and
should be physically protected. The wireless access point should also not be accessible to prevent
someone from tampering with or entering the internal network. Areas #4, #6, #9, #11, #12, and the
firewalls, should all be in separate areas that are locked away to prevent someone from having access. It
would also be ideal to have the areas monitored with CCTV to be able to see if someone gained access
to them. Those devices should also be in areas with a proper HVAC system to protect from overheating,
a fire suppression system in the case of a fire, and they should be connected to UPS in case there is a
lack of power. Because these devices host important and private information to the company, these
areas should be protected the most. If someone gained access, they could inject malware into the
system, they could physically destroy the systems rendering all data lost, or they could physically steal
the information. With enough time and resources, any cryptographic control could be broken. While the
physical controls could be expensive depending on how secure the company wants to be, physical
guards or CCTV for example, proper controls could be put in place without adding too much of a cost
overhead to the company. These controls are most vital to the system and the lack of them could even
make the cryptographic controls ineffective.
 4

There are additional technical controls should be implemented in combination with the
cryptographic ones as well. The NIST SP 800-97, Establishing Wireless Networks, recommends
implementing the IEE 802.1X standard and EAP for authentication. The wireless access point, #11,
should be equipped with EAP-TLS as it is very secure and well supported, to provide authentication for
the network and keep unwanted users out. Along with proper authentication, the access point antennae
should be pointed so they do not allow for connections outside of the facility. The access point should
also be protected from physical access and tampering. The last control suggestion I would make would
be some sort of antivirus on all the systems. Malware can be downloaded onto the systems maliciously,
but it can also be done accidentally. The systems should be protected from accidental misuse by the
employees. While the systems owned by the users and providers may not be owned by the health
company, if they are, they should be equipped with antivirus software. The employee user stations
should be protected also. Even though the firewalls should be protecting the corporate LAN from
malicious software, it is possible that some could get through and defense in depth is necessary. Areas
#1, #2, #3 and #10 should all have malware protection. According to the NIST SP 800-83, it should be
centrally managed. Although this isn’t the most important control since other network defenses are
protecting from it as well, it should also be included.

Cryptographic Techniques
Confidentiality
In our system architecture, we are looking to enforce a confidentiality policy. This policy explains
how we expect our employees to treat the confidential information about our health insurance clients.
It also explains how the information will be protected, in accordance with acts such as Health Insurance
Portability and Accountability Act of 1996 (HIPAA) and Health Information Technology for Economic and
Clinical Health (HITECH). The following security measures that were chosen, were put in place to enforce
this confidentiality policy and protect customer information.

Insider and outsider threat must both be considered when enforcing a confidentiality policy. The
customer information must be protected from adversaries trying to gain personal information for
possible financial reasons, as well as insiders who could either be malicious or simply unknowingly
compromise customer data. The risk of the information being leaked is very high. It would not only open
the company to many lawsuits for not following the privacy laws, but it would also greatly hurt the
reputation of our company. Customer health information being leaked could be detrimental to the
company. Therefore, these security measures must be taken seriously in the design of the network.

The following suggestions have been made based off the HIPAA and HITECH requirements. The
acts require end-to-end encryption as well as full disk encryption for data at rest. Assumptions have
been made that proper media sanitization and destruction is taking place and proper employee
background checks are being done when employees are hired; these recommendations will only cover
encryption for data in motion and data at rest. A dual firewall set up is also in place around the web
servers, this creates a DMZ and protects the internal network from compromise.

The three areas in the health insurance company network architecture that require data-at-rest
encryption are #4 Off-Site Backup, #9 User and Provider Data, and #12 Corporate Data. The HIPAA states
that a mechanism should encrypt and decrypt electronic health information and that a retrievable exact
copy of the health information should be created if needed. Since we have created an off-site backup of
 5

our data, this will need to be encrypted as well. The HIPAA does not require encryption and allows there
to be no use of encryption if appropriate. In our implementation we will use encryption as an
appropriate safeguard. The corresponding National Institute of Standards and Technology (NIST)
controls state that any National Security Agency (NSA) or Federal Information Processing Standards
(FIPS) approved method should be used. The NSA Information Assurance Capabilities document
references the FIPS PUB 197 and states that AES-256 should be used to protect data at rest. It is a
symmetric block cipher with a 256-bit key that should be used to encrypt and decrypt data at areas #4,
#9 and #12. The NIST 800-38E, Recommendation for Block Cipher Modes of Operation: the XTS-AES
Mode for Confidentiality on Storage Devices, recommends XTS mode for AES that is being used for
storage devices.

For the areas in transit, we are assuming that the VPNs are an SSL/TLS VPN with TLS 1.3. This is
because it is the newest protocol version of the VPN and there is a TLS 1.3 adoption deadline of 2024, so
we shall incorporate this version of TLS from the start. We chose the SSL/TLS VPN as it provides for more
security granularity than an IPSec VPN. The NIST document states that the TLS must meet requirements
for NIST approved cryptography. TLS 1.3 and should be configured to only use the cipher suites that are
NIST approved. GCM and CCM modes are the preferred options with AES and a bit size of 128 or 256.
TLS should be used within the internal network connections such as #19, #20, #21, #22, #23.

Data Integrity
A hash function is designed to detect deliberate alterations to data. It takes a long string of data
and produces a fixed result, it can then be checked with the final message to see if the message was
tampered with. A message authentication code (MAC) is similar to a hash, however it is based on a
secret key. The key can be included with the message that is processed by the hash and this result is
known as an HMAC. Both functions work to detect if a message was tampered with in transit. While
both provide integrity, a MAC provides authentication as well.

A hash should be used anytime one wants to prove message integrity. In the network
architecture we have, this is necessary in areas #1, #2, #3, and #10. This is because each of these areas is
going to be sending and receiving information and they need to be able to verify that the information
has not been altered. The FIPS 180-4, Secure Hash Standard (SHS), lists seven approved algorithms: SHA
-1, -224, -256, -384, -512, -512/224, and -512/256. While the NIST also provides guidance for SHA-3
derived functions, I believe that using a SHA-2 algorithm would be best in this application since the SHA-
3 algorithms are still new and still being tested. A hash function determines its security by a few main
areas: collision resistance strength, preimage resistance strength or second preimage strength. Because
the NIST 800-57, Recommendation for Key Management, says that “it is always acceptable to use a hash
function with a higher estimated maximum-security strength than required for the application” (), we
will err on the side of caution and lean towards more secure, than the other way around. The areas I
mentioned that require message integrity, #1, #2, #3 and # 10, will likely also require authentication.
The customers, providers and workers all want to communicate knowing that their message still has
integrity and they want authentication to prove that who is sending and who is receiving the message
are authorized. Because we want both integrity and authentication in all these instances, I will be
recommending a hashing function along with a MAC, an HMAC. While there are several approved
algorithms, I choose HMAC-SHA-256 for my recommendation, an HMAC with SHA-256 as the hash
function. While it is not the fastest option, I don’t believe that speed is the defining factor in a health
 6

insurance network architecture, security is. The algorithm falls within the FIPS and NIST approved
algorithms and provides a high security strength without too much overhead. The HMAC SHA-256
function provides for a security strength of >= 256, well over the minimum Federal government
acceptable value of 112 bit of security strength. The algorithm should be used for all four areas of the
architecture to provide both authentication and integrity to all three types of communicators in the
network.

Not using hashes or MACs in the network architecture could be detrimental. Not assuring if the
message received was the one sent would have serious consequences. Receivers would be forced to
assume that the information they received can be trusted and was as intended. If someone tampered
with the data, this could result in people receiving health information or money that they weren’t
supposed to and could even put the clients in danger. This would result in serious consequences to the
company for not verifying that they were acting in a way they were supposed to and could even open up
the company to lawsuit. The use of hashes and MACs should be taken seriously and should be applied to
the network architecture of the company.

Public Key Cryptography

Public-key cryptography works slightly different than symmetric key cryptography. Rather than
having a secret key that both parties must share prior to encryption, public-key uses two keys. One key
is public and known and the other key is private. Public key cryptography allows for a more secure way
of distributing keys since the sender does not also require a secure channel for sending the key, as they
do with symmetric cryptography. It also does not require as many keys since symmetric requires new
keys to be generated for every sender and receiver. Although public-key can be more convenient, it is
more mathematically intensive and can take much longer than symmetric encryption, especially for long
messages. For this reason, I will suggest using public-key cryptography for the key management, or key
exchange, and symmetric cryptography to protect the data. Since we already addressed the symmetric
algorithms in a previous assignment, I will continue this essay with the assumption that AES-256 is being
used as the symmetric algorithm that the public-key algorithms will be working with.

Both the FIPS 186-4 Federal Information Processing Standards Publication Digital Signature
Standard (DSS) and the NIST Special Publication 800-56B Revision 2 Recommendation for Pair-Wise Key
Establishment Using Integer Factorization Cryptography, recommend the RSA algorithm for digital
signatures as well as key management. The minimum recommended modulus bit length for a security
strength of 112 in the text is 2048 bits and for that reason I will suggest using RSA-2048 with the AES-
256 algorithm. It is widely considered the optimal size as it provides a decent level of security and does
not overload the system. This is with the assumption that an approved random bit generator (RBG) is
being used to produce the key pair as well. The RSA algorithm should be used in areas #1, #2, #3/#15
and #10. These are the areas with clients so that they may have their own private key. This is so that the
users connecting to the network trying to communicate, as well as those in the internal corporate
network, may use the public key infrastructure. RSA works with TLS and should provide the keys for
communication over the VPN and the internal LAN. If every participant (the clients, providers, and
employees) has a private RSA key, they may communicate smoothly with encryption and authentication
using public-key cryptography.
 7

User Authentication
Kerberos is an authentication service, it allows users and services to authenticate themselves
with each other. Rather than using a password repeatedly for each service, Kerberos uses a ticket
granting service (TGT) for service access to grant access to services without repeatedly requesting a
password. The password works as a shared secret in which establishing identity doesn’t require the user
to reveal the secret and therefore protects the password which is used as an encryption key. Kerberos is
a great way to provide authentication and I believe it should be applied to the network.

I believe that we should set up a Kerberos server within the internal network. It should be
protected by the dual firewalls and be located similarly to the other internal servers #9 and #12, either
of these locations would work. The Kerberos server will be its own physical machine which will hold the
ticket granting service (TGS), as well as the authentication server (AS). This machine will be referred to
as the key distribution server (KDC). The KDC will provide authentication to everyone trying to access the
network including: customers (#1), providers (#2), remote workers (#3), and internal workers for the
corporate LAN (#10). For the initial implementation of this new addition to the network, I will only
suggest on KDC. This should not be problem if the network is small, however it can become a bottleneck
with the authentication process should the number of requests grow. For this initial implementation I’ll
be working under the assumption that the number of requests will be small. Should the KDC become a
bottleneck for the network, I will suggest implementing a KDC for each area of access to the network,
one for the customers, one for the providers, one for the remote workers, and one for the internal
workers. They will work together with cross-realm authentication.

Kerberos uses symmetric-key cryptography for its authentication and it is a suggested

automated key management system within the NIST 800-57 parts 2 and 3. It works with a user logging
into a client and entering their password, from this, a symmetric key is generated. The client then
requests a TGT from the AS. The AS generates this ticket for a certain amount of time and sends it back
to the client who then provides the TGT to the TGS, along with its own authentication information (a
client identifier and time stamp). The TGS validated this information and then generates a ticket and
sends it to the client to use to access the server it’s trying to access. The NIST SP 800-57 part 3 offers
some guidance with implementing Kerberos. As I suggested earlier, it recommends that HMAC SHA256-
128 is used for data integrity with encryption. It also states that approved symmetric key encryption
algorithms, such as AES, are used and AES-256 was already suggested as well. The publication states that
DES is not used and specifically mentions AES so we shall continue using this algorithm. It also suggests
that TLS is used, and TLS 1.3 is being used in the network.

Public Key Infrastructure

Public Key Infrastructure (PKI) is a set of policies and procedures, as well as hardware and
software, that are used to create, manage, distribute, store and revoke digital certificates and public
keys. It allows for the use of digital signatures and encryption in a network. It binds public keys to their
entity and manages this through a certificate authority (CA). In PKI each entity must be uniquely
identifiable and verified. PKI is very important as it allows for confidentiality, identification and
nonrepudiation within communication between two parties. If both parties trust the CA, they can trust
that each other are who they say they are. It allows one to encrypt a message so that only the other can
see it as well. PKI can also be used with a VPN to allow trusted employees to access the corporate
 8

network from outside of the physical building. PKI should be implemented in our network in several
areas to allow for users to securely communicate in the network.

In the case of the health insurance company network, the company, likely the IT department,
should act as the CA. They will decide who has access and what level of access they have. This
information should be protected in an internal server like the ones in locations #9 and #12. These keys
should have an expiration date and should be continuously managed. Because this location is managing
the status of the certificates, it needs to be heavily protected along with the other user information. The
information should be encrypted and physically protected. The registration authority (RA) will also be
located here to verify the identities and storing their certificates at the CA. Locations #1, #2, #3, and #10
should all use PKI for internal/external communications and it should also be used for the VPN #15 and
#7. Once users at locations #1, #2, #3, and #10 are verified by the CA at location #9, they can
communicate using digital signatures to provide authentication and non-repudiation and they can
encrypt their emails with their public/private key pairs and communicate more securely. PKI will also be
used in the VPN so that remote users can access the corporate network. PKI allows the VPN to recognize
who has access and what their level of access should be. Once again, the company acts as the CA and
certificates should be managed by location #9.

To avoid another point of attack, the system should not use an access control list. This is a
database which shows who has access to what. A more secure method would be to tie the permissions
to the key and keep the certificate from linking keys to names. In this design, the system that is being
requested access will simply look at the provided certificate to see if the user has the appropriate
permission and then decide where to or not to allow access. The company will still have to decide who
has access to what and provides an easier way to distribute. The company should also use location #9 to
log who gains access to what systems at what times. This allows security to ensure that nothing fishy is
going on and provides data in the case of an event. Another important part of PKI is revocation this
allows certificates to be checked to see if they have been revoked or not and if they are still valid. I
believe that the best way of implementing revocation, and PKI, in this instance would be fast expiration.
As I stated earlier, there should be an expiration date on the certificates. In fast expiration, certificates
are issued for a period of anywhere from 10 minutes to 24 hours. I will recommend 24 hours so that
new certificates are not constantly needing replacement. Each time the user wants to use their
certificate, they should get a new one from the CA and it is valid for that set amount of time. The CA is
informed of access rules and reissues certificates. Because the network isn’t too large, I don’t believe
that this implementation should cause too much of a bottleneck. Everyone should always be online, and
it is a simple implementation that reduces complexity in the system and therefore helps improve the
security posture of the network.

Conclusion
While the amount of controls and techniques that are suggested in this essay can seem like a
lot, they are necessary to protect the confidentiality and integrity of the customer data. The information
managed by our company, being a health insurance company, includes both health and PII and must be
protected. The recommendations mentioned are the minimum set of methods that should be
implemented in the network architecture and focus on cryptographic techniques. The architecture
should include hashing algorithms for data integrity, public key cryptography for confidentiality,
Kerberos for user authentication, and PKI. Although they are not cryptographic controls, the physical
 9

security controls such as HVAC, locks, UPS, and CCTV should be implemented as well. These are not
simply recommended methods, but the cryptographic techniques are required by regulation and are
necessary to protect customer information. There are many other physical, technical, and administrative
controls that can be put in place that were not covered in the scope of this report. For further
recommendations, please reach out to me as the CISO.
 10

References
Barker, E. (2016, January). NIST Special Publication 800-57 Part 1 Revision 4 Recommendation for Key

Management Part 1: General. Retrieved March 22, 2019, from

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

Barker, E., & Barker, W. C. (2018, November). DRAFT (2nd 1 ) NIST Special Publication 800-57 Part 2 2

Revision 1 3 Recommendation for 4 Key Management 5 Part 2: Best Practices for 6 Key Management

Organizations. Retrieved April 7, 2019, from https://csrc.nist.gov/CSRC/media/Publications/sp/800-

57-part-2/rev-1/draft/documents/sp800-57pt2-r1-draft2.pdf

Barker, E., & Dang, Q. (2015, January). NIST Special Publication 800-57 Part 3 Revision 1

Recommendation for Key Management Part 3: Application-Specific Key Management Guidance.

Retrieved April 7, 2019, from https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-

57Pt3r1.pdf

Cooper, D., & McKay, K. (2018, October). Guidelines for the Selection, 3 Configuration, and Use of

Transport 4 Layer Security (TLS) Implementations. Retrieved March 17, 2019, from

https://csrc.nist.gov/CSRC/media/Publications/sp/800-52/rev-2/draft/documents/sp800-52r2-

draft2.pdf

Common Controls and the Risk Management Framework (RMF). (2017, May 16). Retrieved March 23,

2019, from https://cfocussoftware.com/risk-management-framework/common-control-

conundrum/

Compliancy Group. (2018, November 29). HIPAA Encryption Requirements | HIPAA Compliant

Encryption. Retrieved March 17, 2019, from https://compliancy-group.com/hipaa-encryption/

Cryptographic Hash Functions, Message Authentication Codes, and Digital Signatures. (n.d.). Retrieved

March 22, 2019, from

https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.compone

nt.80.doc/security-component/jsse2Docs/cryptographichashetc.html
 11

Dang, Q. (2012, August). NIST Special Publication 800-107 Revision 1 Recommendation for Applications

Using Approved Hash Algorithms. Retrieved March 22, 2019, from

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf

DATA AT REST CAPABILITY PACKAGE. (2018, January). Retrieved March 17, 2019, from

https://www.nsa.gov/Portals/70/documents/resources/everyone/csfc/capability-packages/dar-
cp.pdf

Dworkin, M. (2010, January). Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode

for Confidentiality on Storage Devices. Retrieved March 17, 2019, from

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38e.pdf

Ferguson, N., Kohno, T., & Schneier, B. (2010). Cryptography engineering: Design principles and practical

applications. Indianapolis, IN: Wiley Pub.

FIPS PUB 180-4 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION Secure Hash Standard

(SHS). (2015, August). Retrieved March 22, 2019, from

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

FIPS PUB 186-4 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION Digital Signature

Standard (DSS). (2013, July). Retrieved April 1, 2019, from

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

FIPS PUB 198-1 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION The Keyed-Hash

Message Authentication Code (HMAC). (2008, July). Retrieved March 22, 2019, from

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf

Frankel, S., Kent, K., Lewkowski, R., Orebaugh, A. D., Ritchey, R., & Sharma, S. (2005, December 01).

Guide to IPsec VPNs. Retrieved March 17, 2019, from

https://csrc.nist.gov/publications/detail/sp/800-77/final

HHS Office of the Secretary,Office for Civil Rights, & Ocr. (2013, July 26). Breach Notification Guidance.

Retrieved March 17, 2019, from https://www.hhs.gov/hipaa/for-professionals/breach-

 12

notification/guidance/index.html

Northcutt, S. (n.d.). Hash Functions. Retrieved from https://www.sans.edu/cyber-research/security-

laboratory/article/hash-functions

Scarfone, K., Souppaya, M., & Sexton, M. (2007, November). Guide to Storage Encryption Technologies

for End User Devices. Retrieved March 17, 2019, from

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-111.pdf

Scholl, M., Stine, K., Hash, J., Bowen, P., Johnson, A., Smith, C. D., & Steinberg, D. I. (2008, October). An

Introductory Resource Guide for Implementing the Health Insurance Portability and

Accountability Act (HIPAA) Security Rule. Retrieved March 17, 2019, from

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-66r1.pdf

Souppaya, M., & Scarfone, K. (2013, July). NIST Special Publication 800-83 Revision 1 Guide to Malware

Incident Prevention and Handling for Desktops and Laptops. Retrieved March 23, 2019, from

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-83r1.pdf

Symmetric vs. Asymmetric Encryption – What are differences? (2019, February 07). Retrieved April 1,

2019, from https://www.ssl2buy.com/wiki/symmetric-vs-asymmetric-encryption-what-are-

differences

Tung, B. (2007, January 2). The Moron's Guide to Kerberos, Version 2.0. Retrieved April 7, 2019, from

https://wpollock.com/AUnixSec/MoronsGuideToKerberos.htm

What is PKI? (n.d.). Retrieved April 15, 2019, from https://www.entrustdatacard.com/pages/what-is-pki

What is Public Key Infrastructure (PKI)? | Management and Authentication of Public Key Infrastructure |

Thales eSecurity. (n.d.). Retrieved April 15, 2019, from https://www.thalesesecurity.com/faq/public-

key-infrastructure-pki/what-public-key-infrastructure-pki
 13

Appendix

Components

#1 Customers:
HMAC SHA256-128: Data integrity hashing algorithm

RSA-2048 with AES-256: Public key cryptography

Kerberos with AES-256: User authentication

 14

PKI

#2 Providers:
HMAC SHA256-128: Data integrity hashing algorithm

RSA-2048 with AES-256: Public key cryptography

Kerberos with AES-256: User authentication

PKI

#3 Remote Workers:
HMAC SHA256-128: Data integrity hashing algorithm

RSA-2048 with AES-256: Public key cryptography

Kerberos with AES-256: User authentication

PKI

#4 Off-Site Backup:
AES-256, symmetric block cipher with a 256-bit key, in XTS mode

Physical security – locked, inaccessible, HVAC, CCTV, UPS

#5 Outer Firewall:
Physical security – locked, inaccessible

#6 Web Servers:
Physical security – locked, inaccessible, HVAC, CCTV, UPS

#7 VPN:
TLS 1.3, AES-256, GCM mode

PKI
 15

#8 Inner Firewall:
Physical security – locked, inaccessible

#9 User and Provider Data:

AES-256, symmetric block cipher with a 256-bit key, in XTS mode

PKI – CA/RA. Should manage certs here or in another internal server

Physical security – locked, inaccessible, HVAC, CCTV, UPS

#10 Corporate LAN:

HMAC SHA256-128: Data integrity hashing algorithm

RSA-2048 with AES-256: Public key cryptography

Kerberos with AES-256: User authentication

Physical KDC server should be placed somewhere here within the internal network, similar to the servers #9 and #12

PKI

#11 Wireless Access Pont:

HMAC SHA256-128: Data integrity hashing algorithm

RSA-2048 with AES-256: Public key cryptography

Kerberos with AES-256: User authentication

Physical security – locked, inaccessible

#12 Corporate Data:

AES-256, symmetric block cipher with a 256-bit key, in XTS mode

Physical security – locked, inaccessible, HVAC, CCTV, UPS

Interfaces
 16

#13 Customers to Outer Firewall:

#14 Providers to Outer Firewall:

#15 Remote Workers to VPN:

TLS 1.3, AES-256, GCM mode

PKI

#16 Outer Firewall to Web Servers:

#17 Web Servers to Inner Firewall:

#18 VPN to Inner Firewall:

TLS 1.3, AES-256, GCM mode

#19 Inner Firewall to Corporate LAN:

TLS 1.3

#20 Inner Firewall to User and Provider Data:

TLS 1.3

#21 Corporate LAN to User and Provider Data:

TLS 1.3

#22 Wireless Access Point to Corporate LAN:

TLS 1.3
 17

#23 Corporate LAN to Corporate Data:

TLS 1.3