1. Ensure that all relevant security events and logs are collected for analysis.
Having the right data is essential for real-time alerting of potential and actual compromises, and for analysis following a breach. Ensure that the integrity of these events and logs would be maintained in event of a breach.
2. Design simple communication flows between your components.
A well thought-out design, with clearly defined and tightly constrained communication between components, can simplify security analysis and make it possible to automatically alert your operations team to events that are strong indicators of compromise.
Ensure you understand the expected or ‘normal’ operational parameters for your service so you can monitor for when it is operating outside of those norms.
3. Detect and prevent malware command and control.
Watch for attempts by compromised components to contact their command and control infrastructure. This can be achieved with a whitelist of external addresses that components in your system can access.
4. Separate your event analysis systems from the core components of the service.
Doing this ensures that, if the core components of the service are compromised, they would provide the attacker limited opportunity to know whether any monitoring tools have detected the compromise.
5. Make it difficult for attackers to attempt to detect your security rules through external testing.
Ensure you give away minimal information to an adversary trying to understand the security rules and logic of your service. Also consider using heuristics or fuzzy matching to detect attacks, as this is likely to make it more difficult for an attacker to map out your defences.
6. Use transaction monitoring to provide additional security for high-risk transactions in digital services.
Your users may not always be in control of their devices and their interaction with your service. Transaction monitoring can help detect when malware on a device is controlling a user’s session.
7. Make it difficult for attackers to probe security-monitoring rules by not stopping transactions immediately on suspicious activity.
Transactions that are suspicious should be identified and marked. Consider alerting security teams but allowing transactions to continue until the last possible moment to gather as much evidence as possible.
Depending on the scenario, you may wish to seek manual intervention, re-authentication or other counter-fraud mechanisms to be completed before allowing the transaction to proceed.
Source: NCSC
