Define what elements must be logged: account for the numerous
code-level settings and infrastructure configuration as you define what
information needs to be logged, at what interval, and how long it must be
retained. Ideally, these guidelines are defined as part of the secure code
and configuration practices discussed earlier. Realistically, all activity must
be logged since attackers may be stealthy in their reconnaissance and
attack attempts. You will need to capture full API request and response
traffic, and it’s not just a matter of alerting on excessive authentication
failures.
2.
Incorporate non-security logging requirements: to avoid overburdening
teams, ensure that your logging requirements also incorporate the needs of
API operations or infrastructure teams who are likely more concerned about
troubleshooting ability and tracking uptime. There will be some overlap
between the needs for non-security and security. Indeed, some indicators
of a performance problem, such as error rates, can also be an indicator of
compromise in the event that an attacker is probing your APIs. Common
logging details and metrics latency, request sizes, response sizes, error
rates, and API caller location.
3.
Embrace automation for logging configuration: a multitude of “as-code”
approaches exist for configuration, infrastructure, and policy you should
consider using in your organization to help automate the necessary logging
and auditing settings. The “as-code” approaches are also fundamental to
most cloud infrastructure and cloud-native designs. Never presume that an
acquired software package, cloud-service, or infrastructure component has
logging enabled or at a level of detail that is sufficient enough since these
features are often left disabled to keep a product more performant.
4.
