Assignment

 
File or key names
§  File size or registry data
§  Last updated time and date
§  Data checksum (MD5 and/or SHA1 hash)
Architecturally, the tool is split into two parts: a host component and an administrative console. As shown in Figure E.4, one client can communicate with multiple servers, rather than running the tool locally on each computer.

Figure E.4 The networked host/admin console nature of the iNTegrity tool
In another operational environment, it might be known that a machine  has been compromised and can no longer be trusted, and the server and  client software can be run off, say, a bootable CD or USB drive. In this  case, the integrity-checking code is running under a trusted, read-only  Windows environment, and the host and admin components both read data  from the compromised machine, but not using the potentially compromised  OS. The host process does not run as a Windows service in this mode, but  as a standalone console application.
The Host Component
This small host component is written in C++ and runs as a service on a  Windows server. Its role is to take requests from the admin console and  respond to those requests. Valid requests include getting information  about host component version, and recursive and non-recursive file  properties. Note that the host software performs no analysis; it sends  raw integrity data (filenames, sizes, hashes, ACLs, and so on) to the  admin console, which performs the core analysis.
The Admin Console
The admin console code stores and analyzes resource (file, registry)  version information that comes from one or more host processes. A user  can instruct the admin console to connect to a host running the  iNTegrity host software, get resource information, and then compare that  data with a local, trusted data store of past resource information to  see if anything has changed.
The iNTegrity Data Flow Diagrams
The iNTegrity data flow diagrams are shown in Figures E.5 and E.6.
Note
The iNTegrity example comes from a time when the standard advice was to create a context diagram,  which can be helpful when an external threat modeling consultant is  being used, acting as a forcing function to consider the scope and  boundaries of the threat model.

Figure E.5 Context diagram

Figure E.6 Main DFD
Exercises
The following exercises were designed to walk students through the  activities they’ll need to perform to find threats. They can be used by  readers of this example without modification:
1.  Identify all the DFD elements. (People often miss the data flows.)
2.  Identify all threat types to each element.
3.  Identify three or more threats: one for a data flow, one for a data store, and one for a process.
4.  Identify first-order mitigations for each threat.
Extra credit: The level 1 diagram is not perfect. What would you change, add, or remove?