These two tags seem to be quite similar to each other:
The process of gathering evidence and information that allows for the creation of a theory of events explaining a security incident.
Are they about the same thing? And in that case, should one be a synonym of the other?
That depends. Is the incident analysis something that has to be investigated, or is it an incident for testing and training purposes only? Is there anything to investigate, or would there be anything to investigate?
I can cause an incident on my own systems and throw an alarm, but may not know why I threw it in my IDS. At that point I should analyze the incident, but no investigation into scope and breach of attack may be needed.
This could mean that you're investigating something security related but isn't an incident. Maybe I want to investigate another system in our network, but I don't have an incident. I just want to make sure it's a safe system and go poking around. I have something I know is related to security, but I don't know what it is, or if it's safe and I should investigate it's purpose further.
Really these are connotations, but show that one could exist without the other. Granted they are usually heavily inter dependent, but cases like these provided are common as well. IT really feels like these tags are poorly defined and need to be updated to be a little more concise. It would be helpful to know that I can have one without the other, but in most actual incident analysis I would want both.
In my experience, "Incident analysis" is part of a formal event lifecycle. A collection of security events, through automated or manual correlation are collected for formal analysis.
From a procedural standpoint, incident analysis may result in an investigation. The difference being the depth of analysis, the expertise of the investigator, the time they spend and the expectations of the report. If an incident takes more than a few minutes to analyze, it should be raised for an investigation, else it's interfering with daily monitoring tasks.
One problem with the word "incident" is that outside the security practice, it is a much heavier word, associated with successful breaches, denial of service, virus outbreaks etc. It's accurate there too, but when customers ask for reports of your most recent security incidents, they're not asking for the false-positive the printer generated, or the massscan which hit you on Tuesday. They want the big stuff.
Investigations also go way beyond the Incident-analysis meaning, including missing laptops, devices knocked offline, indications of inappropriate access, missing evidence of authorization before granting access to systems, etc.
For now, the meaning of the word depends on who I'm talking to. If I'm talking to SOC analysts, "Incident" means a bunch of correlated events. "Investigation" means what you're doing with those correlated events.
If I'm talking to customers or management "Incident" means a breach or similar security fail, while "Investigation" means a multi-day or multi-week thing which is going to have a root-cause analysis and will result in an ugly MS Word document filed for review by auditors, investors or customers.
The outside world and even the best product documentation confuses the language. E.g., I've been reviewing Splunk's capabilities in regard to incident analysis, even they get fuzzy on the terms... notice how it's the "Incident review" dashboard, but they talk about "Events", "Notable Events" and "investigation"
http://docs.splunk.com/Documentation/ES/latest/User/IncidentReviewdashboard
It's like they changed their mind about calling anything an "Incident".
investigationtag:Looking at the inner workings of security systems, their interactions, and scope of coverageand theincident-analysistag:Analyzing what caused an event to be flagged as an incident