Incident response and monitoring is a topic close to my heart as it is an area in which my clients frequently had gaps and questions. These often were not due to the inexperience of the personnel, but a more reactive and laissez-faire approach to system monitoring and incident management.
You can usually identify this mindset with a simple question: “Do you have a set definition of what you deem a security incident?” If they say no, or describe what would be a breach, then you know they have a reactive mindset, and CEO phishing attempts succeeding, lost laptops, people logging into systems with PII from unsecure devices, open IPs showing confidential data on web-apps, and other incidents are common. Often with an investigation and the proper tools in place, a security incident is quickly shut down before any serious damages and before data is exfiltrated.
So, often CISOs, dreading explaining things to their non-technical C-Suite, ask the security version of George Berkeley’s thought experiment and query, “If an incident occurs in the system and no data is stolen and no servers are impacted, does it really count?” This embarrassed, laissez-faire attitude often means you only find out about these occurrences if you really twist their arm—often to the disgruntled dismay of the rest of the process owners outside the security team.
For a fun anecdote, I was once told that a client claimed they had no incidents or breaches but it was later discovered that they fell for an invoice fraud phishing attack that caused them to wire the equivalent of four or five Mox Sapphire’s to someone pretending to be a trusted supplier. The reason they didn’t deem this an incident? They got all the money back. This is a funny example, but this isn’t too uncommon.
So, what is a good definition of a security incident? In my opinion, I believe the NIST definition from NISTIR 8183A Vol. 3 is an amazing definition for small and medium-sized organizations. It states, “An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.” The “or potentially” does a lot of heavy lifting here, but is still a much better definition than those that allow people to more easily wiggle their way out of filling out a ticket for a potential incident. A common occurrence is cherry-picking more vague definitions that don’t have the built in safeguards and controls around the definition such as the NIST SP 800-53 Rev. 5 for a non-federal system.
Besides the fact that leveraging this definition means that occurrences such as false positives and security investigations properly follow the ticketing process instead of being undocumented events, there are other helpful points to this definition. The terms “Confidentiality, Integrity and Availability” being in the definition ensures that incidents such as DDOS attacks are not reported as simply “outages” or “infrastructure changes.” The phrase “Constitutes a violation or imminent threat of violation of” expands the scope of what should be monitored and have alerts in place as well as points more eyes inward on internal incidents, which is a wonderful steppingstone toward zero trust.
There is always the caveat that NIST is the pace-setter and not the leader of the pack when it comes to best practices. NIST has to ring the alarm bells about the need for quantum encryption and stop you from having two-digit passwords like it’s 1983. You should treat NIST as what you should at least be doing if you have an agnostic system looking for some best practices to leverage.
As always, I hope you found this helpful and as a springboard to a more honest and accurate process of reporting security incidents. If I can recommend anything else, it would be to try Another Crab’s Treasure. It has nothing to do with security—it is just a wonderful game with a fantastic soundtrack.
