Threat Modeling Again, Threat Modeling PlaySound
Finally it's time to think about threat modeling the PlaySound API.
Let's go back to the DFD that I included in my earlier post, since everything flows from the DFD.
This dataflow diagram contains a number of elements, they are:
- Application: External Interactor
- PlaySound: Process
- WAV file: Data Store
- HKCU Sound Aliases: Data Store
- Audio Playback APIs: External Interactor
- PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary)
- WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary)
- WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary)
- WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary)
- WAV file Data (PlaySound -> Audio Playback APIs): DataFlow
Now that we've enumerated the elements, we apply the STRIDE/Element methodology, which allows us to enumerate the threats that this component faces:
- Application: External Interactor - Spoofing
- Application: External Interactor - Repudiation
- PlaySound: Process - Spoofing
- PlaySound: Process - Tampering
- PlaySound: Process - Repudiation
- PlaySound: Process - Information Disclosure
- PlaySound: Process - Denial of Service
- PlaySound: Process - Elevation of Privilege
- WAV file: Data Store - Tampering
- WAV file: Data Store - Information Disclosure
- WAV file: Data Store - Repudiation
- WAV file: Data Store - Denial of Service
- HKCU Sound Aliases: Data Store - Tampering
- HKCU Sound Aliases: Data Store - Information Disclosure
- HKCU Sound Aliases: Data Store - Repudiation
- HKCU Sound Aliases: Data Store - Denial of service
- Audio Playback APIs: External Interactor - Spoofing
- Audio Playback APIs: External Interactor - Repudiation
- PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary) - Tampering
- PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary) - Information Disclosure
- PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary) - Denial of Service
- WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
- WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
- WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
- WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
- WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
- WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
- WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
- WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
- WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
- WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Tampering
- WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Information Disclosure
- WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Denial of Service
Phew. You mean that the PlaySound API can be attacked in 33 different ways? That's unbelievable.
It's true. There ARE 33 ways that you can attack the PlaySound API, however many of them are identical, and some of which are irrelevant. That's the challenge of the next part of the process, which is the analysis phase.
As I mentioned in the first STRIDE-per-element post, STRIDE-per-element is a framework for analysis. That's where common sense and your understanding of the system comes into focus.
And that's the next part in the series: Analyzing the threats enumerated by STRIDE-per-element. This is the point at which all the previous articles come together.