This makes a shitton more sense than the PDW post.
They wanted the routers to find out where the netflow and syslogs were being sent so they could grab the SIEM, which would have had records of the through-the-box dataflows and admin access logs.
Since they got the Splunk (SIEM) data, then IDGAF about the routers.
Mutual TLS is only going to protect the syslog data in flight, not at rest in the Splunk DB.
I contend that going after the netflow is the way- if the syslog were tampered with, the netflow would prove or refute those admin connections noted by syslog. Flows coming from the machines can be uniquely fingerprinted, router or not, to prove their origin.
If the netflow were tampered with, there would either be obvious gaps, or anomalies pointed out by what they already know from the machines.
This makes a shitton more sense than the PDW post.
They wanted the routers to find out where the netflow and syslogs were being sent so they could grab the SIEM, which would have had records of the through-the-box dataflows and admin access logs.
Since they got the Splunk (SIEM) data, then IDGAF about the routers.
Now this here makes tons of sense provided they haven’t fucked with the configs.
Splunks log are not enough for one very simple reason: authenticity. Anyone can say that a very compromised Splunk log is fake.
If the white hats are really in control and know what they are doing, they were using syslog with mutual tls.
This way, with routers in hand, you can prove that that log actually came from that router.
Mutual TLS is only going to protect the syslog data in flight, not at rest in the Splunk DB.
I contend that going after the netflow is the way- if the syslog were tampered with, the netflow would prove or refute those admin connections noted by syslog. Flows coming from the machines can be uniquely fingerprinted, router or not, to prove their origin.
If the netflow were tampered with, there would either be obvious gaps, or anomalies pointed out by what they already know from the machines.