Constructing a boundary diagram, also known as an “authorization boundary” or “accreditation boundary” diagram, is a useful way to determine what components of a system are its owner’s responsibility and which are untrusted or managed by others. Components that are managed by the system owner are called “internal”; components that are not trusted or are managed by someone else are “external”. A boundary diagram is not just a network topology map. Its specific purpose is to describe the responsibility boundaries for securing a system. A system boundary diagram is usually included in the organization’s System Security Plan.
Here is a step-by-step guide to constructing a clear and accurate Data Flow Diagram.
Begin by listing all of the components that could be part of the system. These are all of the components that process, store, or transmit the information are associated with the system’s purpose. The list might include:
Next, determine if a component is internal or external to the system. According to NIST SP 800-18 Rev. 1: Guide for Developing Security Plans for Federal Information Systems, Section 3.1, a system is defined by the set of information resources under the same direct management control. Further, NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, Section 2.5, the “[system] authorization boundary” includes
“identifying system elements that:
Review all of the components on the list to determine who they belong to by answering two questions:
If the answer to both question is “yes”, then the component is inside the boundary.
If the answer to both questions is “no”, then the component is outside the boundary.
If the answer to one question is “yes” and the other is “no”, then further analysis is needed to resolve the discrepancy. (Note that a single AO may sign multiple, different SSPs. One resolution would be that the component is on different SSPs signed by the same AO, in which case the component that is associated with different SSP would be external to the other components.)
Next, for those components not identified as “internal” in the initial scope defintion, determine how data from internal components enters or leaves the system to reach external components. (Note although not a Federal standard, this is explicitly required for compliance with Payment Card Industry Data Security Standard, version 4.0.1, requirement 1.2.3, “An accurate network diagram(s) is maintained that shows all connections between the CDE [cardholder data environment] and other networks, including any wireless networks.”)
In particular, identify:
Finally, render the list of components into a diagram. The diagram must explicitly label the boundary between internal and external components. Note that NIST SP 800-53 rev. 5, Security and Privacy Controls for Information Systems and Organizations, CA-3 (Information Exchange) requires that not only must the components be labeled, but interface characteristics, security requirements, and the nature of the information being exchanged should also be denoted. (This additional information may make the diagram too cluttered and illegible. Using references from the diagram to a table where this information is provided is best practice.)
Step 1: To make for the simplest diagram, represent all of the internal components together on the diagram in close proximity to each other and place all of the external components separately. Also, as a best practice, visually group internal components into subnets (for example, DMZ, application tier, data tier) to show system segmentation.
Step 2: Draw a distinct box or line (usually a red dashed line) that encloses all of the internal components. Label this box/line as “internal”. Label the region outside the box/line as “external”.
Step 3: Draw lines indicating data flow between components. Differentiate between incoming and outgoing data flows. A best practice is also to use different line styles, such as different colors, to represent encrypted versus unencrypted data flow. (Although unencrypted data flows should be avoided, if possible.)
Step 4: For every data flow line crossing the internal/external boundary, label the data flow with the protocol and port being used. (In addition to showing how data crosses the internal/external boundary, these labels also support the principal of least functionality.)
Step 5: Add security controls to indicate how the boundary separation is defended. Mark the data flow ingress and egress points by showing firewalls, web applications firewalls (WAF), or API gateways at the point where the connection crosses the boundary line.
Step 6: Be sure to add a legend and supporting tables to the diagram to indicate the meaning of all icons, line types, and information that could not be legibly shown on the diagram itself.
Use this quick reference to check if expected components of the boundary diagram are present:
| Component | Requirement | Reference |
|---|---|---|
| Internal/External Boundary Line | Is the authorization boundary clearly drawn? | NIST SP 800-18 |
| External Data Connections | Are all external connections (APIs, SaaS) shown? | NIST SP 800-53 (CA-3) |
| Ports/Protocols | Are ports labeled (e.g., 443, 8080) on all flows? | NIST SP 800-37 |
| Ingress/Egress | Are data flow directions clearly marked? | PCI DSS 1.2.3 |
| Encryption | Is it clear where TLS/SSL termination occurs? | NIST SP 800-52 |
