Need to find a better format to report Evidences and Alerts since the IDEA0 format does not have all the options

[eldraco]

Describe the bug The IDEA0 format does not have all the options we need to report an alert correctly. In particular IDEA0 still wants each alert to have a Source and a Destination of the attack, when sometimes this is not possible.

For example, if a command and control is detected, Slips creates two evidences. One for the source because it is an infected machine that needs to be contained, and another for the destination, that is the C&C server that needs to be blocked and shared as an IoC.

However, IDEA0 forces us to have a Source and Destination on each alert. In this case what we need is a better way to put the 'reasons' for the evidence. The problem is that the source and destination of the C&C channel are the same, but one evidence is for the source, and one for the destination.

This situation is not clear when you look at the IDEA0 evidences.

Example:

{
  "Format": "IDEA0",
  "ID": "576f848c-2026-4856-b3aa-8be4c92fe734",
  "DetectTime": "2024-07-01T13:00:27.087793+00:00",
  "EventTime": "2024-07-01T13:00:27.087810+00:00",
  "Category": [
    "Intrusion.Botnet"
  ],
  "Confidence": 0.03,
  "Source": [
    {
      "IP4": [
        "209.205.188.238"
      ],
      "Type": [
        "CC"
      ]
    },
    {
      "IP4": [
        "209.205.188.238"
      ],
      "Type": [
        "CC"
      ],
      "Port": [
        449
      ],
      "Proto": [
        "TCP"
      ]
    }
  ],
  "Target": [
    {
      "IP4": [
        "192.168.1.113"
      ]
    }
  ],
  "Attach": [
    {
      "Content": "C&C channel, client IP: 192.168.1.113 server IP: 209.205.188.238 port:  449/tcp score: 0.9910.  AS: NTSC-ASN2, US AS4314 threat level: high.",
      "ContentType": "text/plain"
    }
  ],
  "ConnCount": 1,
  "uids": [
    "C24JPO2CqlIQeGX5B3"
  ],
  "accumulated_threat_level": 0,
  "timewindow": 1
}

Expected behavior To be able to say that each evidence is assigned to an 'IP'. And that IP can be destination or source. The key part is to say that the evidence was generated for a connection going to that IP, or coming from that IP.

Branch Master, 1.0.15

[eldraco]

Sometimes we put the target of the evidence as 'source' even though it was not the source in the traffic. This is a little better.

{
  "Format": "IDEA0",
  "ID": "d32f2a78-a44a-46e9-bb15-d8c1d42e7867",
  "DetectTime": "2024-03-11T14:29:20.299544+00:00",
  "EventTime": "2024-03-11T14:29:20.299562+00:00",
  "Category": [
    "Anomaly.Traffic"
  ],
  "Confidence": 1,
  "Source": [
    {
      "IP4": [
        "73.252.252.62"
      ],
      "Type": [
        "BlacklistedIP"
      ]
    }
  ],
  "Attach": [
    {
      "Content": "connection to blacklisted IP: 73.252.252.62 from 192.168.1.113. AS: COMCAST-7922, US AS7922rDNS: c-73-252-252-62.hsd1.ca.comcast.net Description: IP address should not -according to the ISP controlling it- be delivering unauthenticated SMTP email to any Internet mail server. Source: PBL ISP Maintained, spamhaus. threat level: medium.",
      "ContentType": "text/plain"
    }
  ],
  "ConnCount": 1,
  "uids": [
    "CAThdI1wn2jWrdou31"
  ],
  "accumulated_threat_level": 0,
  "timewindow": 1
}

[AlyaGomaa]

• See if we can use IDMEFv2 instead of IDEA0
• Do we need to also use the MISP objects as individual data to be exported?

[AlyaGomaa]

Here's the plan for IDMEFv2 (https://www.ietf.org/id/draft-lehmann-idmefv2-03.html)

TLDR;

There's a place for all evidence details that Slips supports except for:

• the timewindow
• accumulated threat level
• uid of the flow causing this alert but they can go in the "Notes" field.

It also supports:

• correlating evidence to alerts
• correlating evidence to other evidence (like when we have 2 evidence for C&C detection)
• and distinguishing between alerts and evidence.

---

• It has events and incidents

  • events=evidence, incidents=alerts
  • https://idmefv2.github.io/index.php/glossary/

  An event is something that triggered a notice. Any incident starts off as an event or a combination of events, but not all events result in an incident. An event need not be an indication of wrongdoing. E.g. someone successfully logging in or entering a building is an event. An incident is an event that compromises or has a significant probability of compromising at least one of the organization’s security criteria such as Confidentiality, Integrity or Availability. An incident may affect a production tool, personnel, etc. It may be logical, physical or organizational in nature. Last but not least, an incident may be caused on purpose or by accident.

• Timewindow -> no place, can be put in the "Notes" field

• Uid -> no place, can be put in the "Notes" field

• accumulated threat level -> no place, can be put in the "Notes" field

• Threat level -> will be in the “Priority” field. Uses the same text values as our threat level

• Confidence- > there’s a "Confidence" field, values from 0 to 1 , same as slips

• Notes -> there’s a "Note" field, should be string, they say it should be human readable, but hey humans can read dictionaries!

• Category -> Will be using Enisa:RIST Categories same as IDEA0’s

  • https://www.ietf.org/id/draft-lehmann-idmefv2-03.html#section-5.2-6.8.1

• A Place to say whether it’s an evidence or an Alert -> can go in the “Status” field

  • https://www.ietf.org/id/draft-lehmann-idmefv2-03.html#section-5.2-6.16.1
  • 0 means Event; The event is still considered as an harmless event and should not be treated.
  • 1 means Incident; The event is considered as an incident and should be taken care of.

• To tie evidence to alerts ->we can put the evidence IDs in the “CorrelID”

  • “CorrelID” are Identifiers for the messages which were used as information sources to create this message, in case the message has been created based on correlation/analysis/deduction from other messages.

• When setting two evidence for the same detection like in CC detections, we can use “RelID” field

  • Optional. A list containing the identifiers of other messages related to this message

[eldraco]

This is good. I like it. We can use several notes maybe? or only one note?

[AlyaGomaa]

Only one note because the alerts are dictionaries, but we can use a dictionary in the Note field, and have as many keys in that dict as we want

[AlyaGomaa]

Also we can have a Note field for the source, the target, the attachment etc.

[AlyaGomaa]

• [x] When analyzing not from the interface, we can use as IP: 0.0.0.0 as analyzer IP. When we are analyzing from the interface, use the local IP.
• [x] Remove extra info from the description of all alerts
  • [x] Use the source port and target port field
  • [x] Use TI field in the Source, and add TI info in the Note field of the Target
  • [x] put the AS in the note field of source and target
  • [ ] Threat level should be removed from the description field and added to the Note field
  • [x] put the SNI in the note field of source and target
  • [x] put the rDNS in the note field of source and target
• [x] The Analyzer "Model" should be the current Slips version e.g "1.1"
• [x] Add “AI” or "Heuristic" to the Method field for each evidence.
• [x] Change the Analyzer “Data” field to be flow and network.
• [x] Log the Analyzer in every evidence.
• [x] ad src and dst ports to each evidence