Businesses should translate the pre-determined critical processes into visualizations to better understand the structure of their assets. Implementing a quality information security program requires a deep understanding of how data flows between systems. Understanding these data flows will help determine their impact and the level of security they should be provided with. Understanding data flows also helps weed out single points of failure that could compromise the confidentiality, integrity, or availability of the larger business network.

A Data Flow Diagram (DFD) is a graphical tool used to represent how data moves through a system. It allows businesses to trace the movement of data from initial input to processing to storage. Businesses should create a data flow diagram for each critical business process.

There are two subcategories of DFDs:

  1. Logical Data Flow Diagram: Highlights the flow of information within a system without delving deep into the physical aspects of the system, like hardware and physical connections.
  2. Physical Data Flow Diagram: Shows how systems and their corresponding data flows are actually implemented within the environment. Includes specific labels for hardware components, file structures, specific software, etc.

Ideally, each business process should have both a logical and physical DFD created. However, as a basic first step, businesses can create a hybrid DFD containing labels for both. In addition to subcategories, there are several different levels of DFDs, each one varying in detail.

  • Level 0 DFD: Displays a whole system as one single process, showing relationships with external entities and inputs/outputs.
  • Level 1 DFD: Breaks down the Level 0 DFD into subprocesses. In addition to external entities, internal entity relationships and data stores are also provided.
  • Level 2+ DFDs: Break down subprocesses into smaller functions that work together. These diagrams are useful for complex systems that require many isolated processes to work in tandem.

It is up to the businesses themselves to decide how detailed they want their data flow diagrams to be. Smaller businesses with basic systems and processes can settle with Later 0 DFDs. However, businesses that utilize complex information systems spanning multiple boundaries and physical systems will likely want to make Layer 1 and 2 DFDs to better understand the micro-processes that are essential for overall functionality.

Example: A basic e-commerce website for a small vendor. The customer views the products on the public-facing website. They then add their selected items to the cart. Within the cart, they enter their payment details. The order is securely sent to the small business, which validates the order against the product inventory stored in an on-premises database. Once confirmed, an automated email is sent to the customer, and the payment is processed through a secure payment gateway.

Data Flows

  • Customer → System:
    • Product requests, cart data, payment details
  • System → Inventory DB:
    • Stock validation request
  • Inventory DB → System:
    • Stock availability confirmation
  • System → Payment Gateway:
    • Payment information
  • Payment Gateway → System:
    • Payment confirmation
  • System → Email Service:
    • Order confirmation request
  • Email Service → Customer:
    • Confirmation email

Level 0 DFD

Level 1 DFD

With the Level 1 DFD we can a much deeper look at the specific subprocesses that make up the e-commerce website. The processes are numbered (1.0, 2.0, 3.0, 4.0) as is the data store (D1). The identified data flows from this level 1 DFD are:

  • Customer → 1.0: Browse requests
  • 1.0 → Customer: Product listings
  • Customer → 2.0: Cart actions
  • 2.0 → 3.0: Cart contents
  • 3.0 ↔ Inventory DB: Stock validation
  • 3.0 → Payment Gateway: Payment details
  • Payment Gateway → 3.0: Payment confirmation
  • 3.0 → 4.0: Order details
  • 4.0 → Email Service: Email request
  • Email Service → Customer: Confirmation

With the Level 1 DFD, we can start to see where cybersecurity controls may need to be applied. For example, the 3.0 Order Processing system should have encryption for the data in transit, such as TLS, as well as input validation to defend against injection attacks. D1 Inventory Database should have strong access controls and a hardened OS/MySQL installation. 4.0 Notification Service should have spam protection and anti-spoofing mechanisms. You can start to see how handy data flow diagrams are in designing an information security program.