Security architectures are not defined designs as much as a blueprint for securing data interactions that influence design. The example in this appendix is not a typical network diagram simply showing security architecture but rather a diagram of the intended network design with a security architecture applied to the distinct data interaction. The security architectures developed by the enterprise are applications of the trust models to the implemented network design. Security architecture should encompass standards in application, examples being required encryption and authentication mechanisms.
This example is of applying trust models to develop a security architecture that can be applied to an externally accessible file transfer solution.
The numbers in the diagram will be explained as we progress through the scenario.
We will start by first referencing our data-centric architecture diagram from Chapter 2, Security Architectures.
With the designed solution we must consider each layer of the above diagram and determine what security mechanisms must be employed to secure the data interaction. In order to determine this, it must first be understood what data will be interacted with, what process the solution is supporting, applications that may be used, and users who will be using the solution.
Let's start with identifying each component of the trust model by building blocks for this file transfer solution.
|
Data types |
Process(s) |
Application(s) |
Users |
Roles |
Policies and standards |
|---|---|---|---|---|---|
|
PII |
Prescription order fulfillment |
Prescription order fulfillment system |
External Internal |
User Administrator Data owner |
Data classification Data handling Encryption standard Third party authentication standard |
Now that we have defined all the building blocks of our trust model, risk can be assessed and security mechanisms can be chosen.
If there are regulatory requirements for the data in the solution, these will have a significant influence on what security must be implemented. If policies and standards have been developed that need to be applied more direction, then they can be derived from the content of these documents.
Tip
It may become apparent that there are missing policies and standards to properly enforce the requirement for security controls. If this is the case and not too significant a risk, then note the present shortcomings, obtain approval from those who can assume risk, and begin the process to correct the identified gaps. It is common for new solutions, projects, and market shifts to drive new security policies and standards.
We now have what is needed to develop our trust models that will drive the security architecture applied to the solution design. Because the trust in this case is based on the user and the data being transferred, we'll focus on these trust models.
|
User type | |
|
Trust level |
2 – median trusted |
|
Allowed access |
Least privilege |
|
Required security mechanisms |
FW, IPS, file integrity monitoring, and data loss prevention |
With the building blocks defined and trust models developed, a data-centric security architecture can be applied to the file transfer design to maximize security and minimize risk. We will now see how the applied security architecture is implemented in the reference architecture for encrypted file transfer accessible to external parties.
|
Label |
Description |
Purpose |
|---|---|---|
|
1 |
Internal user authentication |
Role enforcement and least privilege implementation |
|
2 |
Encryption key management |
Necessary to provide encryption meeting policy and standard requirements |
|
3 |
Secure network communication |
Data protection, data handling per data classification policy, and encryption standards enforcement |
|
4 |
Automation (file delivery) |
Process used to enforce least privilege and provide necessary external and internal separation |
|
5 |
External user authentication |
Role enforcement and least privilege implementation |
|
6 |
Secure file transfer system |
Data protection, data handling per data classification policy, and encryption standards enforcement |
|
7 |
Encrypted file transmission |
Data protection, data handling per data classification policy, and encryption standards enforcement |
I have inserted the diagram again for ease of understanding the preceding table.
This example is an exercise that should eventually become second nature when developing new solutions or data interactions. Much of what the trust models provide should become standards and a requirements checklist for projects. The key is to provide an agile approach to securing solutions and data interaction that are not confined by the network design. As we have covered in Chapter 2, Security Architectures, there is little control over the network design as BYOD and cloud initiatives infiltrate the once trusted internal sanctuary of the enterprise network.