Michael & Flo,
Thanks for putting this together. I wanted to follow up a bit on the logging
section. SECOPS can't act on what it can't see.
Protocol designers and implementers are the only parties who know what error or
abnormal conditions can happen. So, I suggest that we add guidance to
explicitly define detectable error conditions and logging requirements so that
security operations can monitor and respond effectively.
Having said that, error responses themselves (ICMP, control replies, resets,
etc.) can become attack vectors (reflection/amplification or DoS) so this has
to be carefully designed.
For example, here are some unexpected or error conditions:
- Protocol syntax errors
- Unexpected state transitions
- Invalid parameter values
- Authentication or authorization failures
- Resource exhaustion
- Replay or duplicate message detection
- Message ordering violations
- Rate-limit triggers
- Unexpected transport conditions (connection resets, unreachable endpoints)
For each condition, the specification should define:
- Detection criteria
- Recommended logging fields
- Recommended severity level
- Recommended response behavior
Example:
Condition Detection
Log Fields
Invalid message format...............parsing
failure.........................source address, protocol state, fieldInvalid
authentication token........auth verification failure............peer identity,
token type Protocol state violation................unexpected
message.............current state, message type
Thoughts?
Chief Technology OfficerOutside the Stacks, Inc.https://www.outsidethestacks.com
PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.org
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
