DATA FLOW DIAGRAM IN

SECURE SOFTWARE
Miss Maryam Malik
DEVELOPMENT
DATA FLOW DIAGRAM
A Data Flow Diagram (DFD) in Secure Software
Development visually represents how data moves through
a system while identifying potential security risks.
It is essential for understanding data handling, access
control, and security vulnerabilities.
DFD LEVELS IN SECURE
SOFTWARE DEVELOPMENT
Level 0 (Context Diagram)
•Shows the entire system as a single process.
•Identifies external entities (users, third-party services).
•Defines high-level data flow and interactions.
LEVEL 1 (HIGH-LEVEL DFD)

•Breaks the system into key processes.

•Shows data storage points and major data interactions.
•Helps in identifying security controls like authentication.
LEVEL 2 (DETAILED DFDS)

•Further decomposes each process.

•Specifies exact data flow, transformations, and security
mechanisms.
LEVEL1
Level 1 DFD (High-Level Process Breakdown)Breaks down the main process into
sub-processes
Shows data flow between these sub-processes Introduces data stores where
information is temporarily stored
Example:In an online banking system, the Level 1 DFD may include:User
Authentication Process (login, password verification)Account Management (view
balance, transaction history)Fund Transfer (input details, validate, execute
transaction)Transaction Logging (store in the database, generate reports)
LEVEL 2
Further breaks down each Level 1 process into more specific tasks, interactions
between processes, data flows, and data stores
For the "User Authentication" process in Level 1, the Level 2 DFD might
show:Receive Login Request (user inputs credentials)Check User Credentials
(validate against the database)Grant or Deny Access (send success or failure
response)Log Authentication Attempts (store failed login attempts)
SECURITY CONSIDERATIONS
IN DFD
Data Classification: Identify sensitive data (e.g., passwords).
Trust Boundaries: Define where data moves between trust levels
(e.g., user to server).
Threat Identification: Use STRIDE (Spoofing, Tampering,
Repudiation, Information Disclosure, Denial of Service, Elevation
of Privilege) to analyze risks.
Encryption & Access Control: Apply security measures at storage
and transmission points.
MODELING SYSTEM SECURITY
USING SECURE-UML
Modeling system security using Secure-UML involves
integrating security policies with system design using
UML (Unified Modeling Language).
Secure-UML extends UML with access control models,
enabling the specification of role-based access control
(RBAC), permissions, and authorization constraints in a
structured way.
STEPS TO MODEL SYSTEM
SECURITY USING SECURE-UML
Define Actors and Roles
•Identify users and their corresponding roles (e.g., Admin, User,
Guest).
•Assign roles specific permissions to access system components.
Model System Components Using UML
•Use class diagrams to represent system entities.
•Use use case diagrams to define system functionality.
Integrate Secure-UML with UML Models

Extend UML use case, class, and activity diagrams with

Secure-UML stereotypes.
Use SecureUML elements like:
Permission: Defines the right to perform an action.
Role: Represents a user role.
Action: Specifies allowed operations (read, write, delete).
Authorization Constraint: Specifies conditions for access control.
MODEL SECURE INTERACTION
USING SECUREUML USE CASE
DIAGRAMS
Attach roles and permissions to use cases.
Define which actors can execute which use cases based on
security policies.
Generate Access Control Policies
Transform SecureUML models into XACML (Extensible
Access Control Markup Language) or other access control
policies.
EXAMPLE
SecureUML Class Diagram
A banking system might have:
User roles: Customer, Teller, Manager
Permissions:
Customer: View balance, transfer funds
Teller: Approve transactions
Manager: Modify accounts
STATE TRANSITION CHART
Data flow diagrams and state transition diagrams are
required to describe a system’s behaviour, when the
behaviour changes over time. A combination of both
diagrams is required
A state diagram is an illustration of all the possible
behavioral states a software system component may
exhibit.
In
STD GUIDELINES
A state transition diagram uses prompts to control (i.e., start and
stop) processes on a data flow diagram. There are three types of
prompts:
Trigger prompt: initiates a discrete process
Enable prompt: makes a continuous process available
Disable prompt: makes a continuous process unavailable
 DFD VS STD
A simple Level 0 DFD for an Online Order System:
Customer ______ Order System
•Receive Order
•Process Payment
•Update Inventory
•Send Order
•Delivery System
Here, the customer places an order, which flows through different
processes, interacting with a data store (inventory) before completing the
transaction.
 A STATE CHART DIAGRAM FOR
AN ATM MACHINE:
•[Idle] --> (Card Inserted) --> [Card Verification]
•[Card Verification] -> (Valid PIN) -> [Transaction Selection]
•[Transaction Selection] -> (Withdraw Money) -> [Processing
Transaction]
•[Processing Transaction] --> (Cash Dispensed) --> [Idle]
•[Card Verification] --> (Invalid PIN) --> [Idle]
Each state represents a phase of the ATM, and the transitions are
triggered by events like inserting a card, entering a PIN, and
withdrawing cash.
Main components

States (rounded rectangles) – Represent different

conditions of an entity.
Transitions (arrows) – Indicate movement from one state
to another due to an event.
Events (labels on transitions) – Trigger state changes.
Actions (descriptions near transitions) – Specify operations
performed during transitions.
 SCENARIO
A university library management system is being developed to
automate book borrowing, returning, and fine calculations. The
system has the following main components:
Users (Students, Faculty, Staff) – Can search books, borrow, and
return them.
Librarian – Manages book inventory and oversees
borrowing/returning.
Database – Stores book details, user records, and transactions.
Fine Calculation System – Calculates overdue fines automatically
FUNCTIONALITIES
User Registration/Login
Book Search (by title, author, or category)
Book Borrowing (check availability, issue book)
Book Returning (calculate fines if overdue)
Fine Payment
Librarian Management (add/remove books)
QUESTION
Design a Library Management System covering:
DFD (Level 0, Level 1) showing how data flows between
components.
State Transition Diagram for book borrowing and returning.
UML Architecture (Class Diagram, Use Case Diagram, and
Sequence Diagram).