Spoofing of Destination Data Store SQL Database Category: Spoofing Description: Database Storage may be spoofed by an attacker and this may lead to data being written to the attacker’s target instead of Database Storage. Consider using a standard authentication mechanism to identify the destination data store. Potential Weak Protections for Audit Data Category: Repudiation Description: Consider what happens when the audit mechanism comes under attack, including attempts to destroy the logs or attack log analysis programs. Ensure access to the log is through a reference monitor, which controls read and write separately. Document what filters, if any, readers can rely on, or writers should expect Insufficient Auditing Category: Repudiation Description: Does the log capture enough data to understand what happened in the past? Do your logs capture enough data to understand...
- Spoofing of Destination Data Store SQL Database
Category: Spoofing
Description: Database Storage may be spoofed by an attacker and this may lead to data being written to the attacker’s target instead of Database Storage. Consider using a standard authentication mechanism to identify the destination data store.
- Potential Weak Protections for Audit Data
Category: Repudiation
Description: Consider what happens when the audit mechanism comes under attack, including attempts to destroy the logs or attack log analysis programs. Ensure access to the log is through a reference monitor, which controls read and write separately. Document what filters, if any, readers can rely on, or writers should expect
Category: Repudiation
Description: Does the log capture enough data to understand what happened in the past? Do your logs capture enough data to understand an incident after the fact? Is such capture lightweight enough to be left on all the time? Do you have enough data to deal with repudiation claims? Make sure you log sufficient and appropriate data to handle a repudiation claims. You might want to talk to an audit expert as well as a privacy expert about your choice of data.
- Data Logs from an Unknown Source
Category: Repudiation
Description: Do you accept logs from unknown or weakly authenticated users or systems? Identify and authenticate the source of the logs before accepting them.
- Lower Trusted Subject Updates Logs
Category: Repudiation
Description: If you have trust levels, is anyone another outside of the highest trust level allowed to log? Letting everyone write to your logs can lead to repudiation problems. Only allow trusted code to log.
Category: Information Disclosure
Description: Credentials held at the server are often disclosed or tampered with and credentials stored on the client are often stolen. For server side, consider storing a salted hash of the credentials instead of storing the credentials themselves. If this is not possible due to business requirements, be sure to encrypt the credentials before storage, using an SDL-approved mechanism. For the client side, if storing credentials is required, encrypt them and protect the data store in which they’re stored
- Potential Excessive Resource Consumption for Native Application or SQL Database
Category: Denial Of Service
Description: Does Backend System or Database Storage take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don’t deadlock, and that they do timeout.
