Any of these network and security investigations starts out with a signal. The fundamental question with that signal? Is the signal truthful, or is it fiction? Am I chasing an actual event, or am I chasing something else? Am I chasing, well, nothing?
One of the major network vendors was reporting fictional switch port states, which meant checking the link directly for its duplex settings, and too often manually configuring duplex. They got auto-negotiation wrong. Tooling can be wrong. Too many folks around here have accepted what anti-malware told them without consideration, and—in a recent false-positive case around here—macOS was blocking the anti-malware from deleting part of and corrupting macOS, while the users of that anti-malware were persisting in trying to delete part of macOS due to that false positive. Gremlins are varied. Every so often I meet a screaming NIC / broadcast storm. There are numerous other examples of tooling errors. And other sorts of gremlins.
Here? SonicWall already has a published history of false signals for this exact case.
Your job here is not to protect the honor of any particular tool, it’s to monitor your network, and which also inherently means monitoring your own tools. Trust, but verify. Mirror the switch port for the SonicWall box, and see if SonicWall is actually seeing what it claims.
Finding spoofed stuff tends to mean mirroring ports throughout the network, too; segment-level instrumentation to locate the source segment(s) for the spoofing.
You may well be getting a real FIN flood here, or some instability from some other component within your network, or some other glitch being reported as a FIN flood, but I’d expect a bit more chatter around the ’net if this were a generic FIN flood issue with any particular vendor’s gear. Mirror the port.