After upgrading I noticed that some unidentified content previously dropped on the log decoder is now making it through.
Without surprise, this was not documented anywhere. Let's not start a debate on how awesome RSA's documentation is, I would rather see some evidence instead.
--Previously only logs complying with RFC 5424 protocol could make it through.
--Currently, some are dropped and some are not. Haven't established a pattern yet.
Problems this is creating:
-An attacker can send can send anything they want to the SIEM if they know the IP of the collector.
Potentially causing good data to be overwritten
Potentially slowing down the system
Reducing retention(some customers may not even realize and spend more to RSA for unnecessary storage, good for you and bad for customers)
-Devices forwarding logs in the wrong way than the RSA recommended method and could still make it through. For example an Oracle DB does not read the documentation and starts forward syslog his own way, this may not have a proper header but could still make it thorough. Then create confusion when we see some traffic from that device before it was integrated as part of a project.
-Packet strings from our vulnerability scans now make it to the SIEM contaminating our logs and reducing the retention. Very useful right?
Yes we know we can spend hours and create rules to drop these but why can't you design something properly? Or at least document both good and bad designs!
Obviously when there is no documentation of the change, there is no acknowledgement of the change and therefore there cannot be a workaround. I'm sure our external auditors would be thrilled to hear of this new feature of a product advertised for security.
