I haven't tested the feature but... if your SAN offers access via its NFS or CIFS heads than you can:
Within the ESM UI Navigate to the receiver > Click Properties > Click Receiver Configuration > enter the appropriate details.
Good luck and let us know if it works
PS-Please note the ELM search capability won't be available, so your back search will be constrained to your ESM live data.
Actually the ELM is a necessary part of you environment if you want to store the raw logs.
Within the ELM you can specify a number of storage system you want to use.
Afterward within the data sources tab on you receiver you can configure the raw storage per device based on your retention policy.
The best practices show that the ELM has to be closet to the ERC so you can decrease the network traffic.
P.S:: rhinomike what is the feature you are refering to as i'm not aware of such functionality is this a new feature?
@alexander_h : all I know about the feature is listed above. It is available in 9.4.0
From what i see indeed there is an option but i believe this is useful only if you have device that can ensure Raw Logs integrity or you wan't to forward the logs to another system for further analysis.
If you need to ensure Compliance the ELM is the only viable option.
These are the details:
Archiving Receiver raw data
Configure the Receiver to forward a backup of the raw data to your storage device for long-term storage.
The three types of storage that are supported by McAfee ESM are Server Message Block/Common Internet File System (SMB/CIFS), Network File System (NFS), and Syslog Forwarding. SMB/CIFS and NFS store, in the form of data files, a backup of all raw data sent to the Receiver by data sources that use the email, estream, http, SNMP, SQL, syslog, and remote agent protocols. These data files are sent to the archive every five minutes. Syslog Forwarding sends the raw data for syslog protocols as a continuous stream of combined syslogs to the device configured in the Syslog Forwarding section of the Data Archival Settings page. The Receiver can forward to only one type of storage at a time; you can configure all three types, but only one type can be enabled to archive data.
This feature doesn't support Netflow, sflow, and IPFIX data source types.
"Compliance" is a very broad term and while it helps to sell boxes, it is not always as simples as a sales collateral may portray it.
For example: If someone uses UDP syslog to send data from the log generating box to the receivers, there's a strong argument against the non-repudiation of those logs, given that datagrams can be easily faked.
I also point out that while the ELM has hash capabilities in place, it lacks digital signatures or tamper resistant crypto material storage, as such, one skilled fraudster may well find a way of circumventing the integrity check mechanism used by the system.
I raised this issue once with McAfee, who promised me they would send technical details on how the integrity is performed but I never got the details I requested...
I agree with you but this is the official statement of the vendor and more or less that's the framework that should be followed.
Honestly my opinion is that the ELM is really crappy product but there is nothing we can do and even more it doesn't have HA redundancy
Not sure if this helps the pain of no HA but we have been eagerly awaiting the ELM redundancy feature ( was supposed to land in 9.4.0 ( sales verbal ), then ooops our bad it's pushed to 9.4.1 ) Guess, what..... It does not seem to be a feature in 9.4.1 ( downloaded the release notes and guides ) that we can see although we've only loaded the software on a combo box, maybe the buttons are there when not on a combo box?? Our tech lead is trying to get an official response from McAfee about when ELM redundancy is truly coming.