...
Central log collection and storage
Reporting and data searching
Snare Reflector
Snare Agent Manager & Configuration (SAM or SAMC)
Agent Management Console (AMC) - being deprecated as the agent management policy functions have moved to the SAMC.
Storage needs
The storage needs are largely driven from the EPS rates of the systems, log types and the data retention needs. The more of each the more storage thats needed. In most cases Snare Central will get 90% + reduction in raw log storage. eg 1.13 TB of raw log data may only consume 87 GB of actual disk. This is due to the high compression rates Snare Central has with its log storage.
Other factors can depend on the following
The amount of reflector cache needed reflecting logs to other SIEM or logging systems and how long a network or system outage that needs to be factored in. So some customers have configured anything from a few GB to 2 TB of cache. The caveat here is to also ensure that there is enough system and network capacity to catch up these cached logs and the destination can cope with catchup eps rates and normal eps rates at the same time.
110 GB pre day of raw logs may reduce to around 4.5 GB
The amount of reporting and local dashboard usage. Both of these may require additional index space. Snare Central uses an opportunistic index method so only indexes what it needs and has regular queries on. This conserves normal index space but having enough disk for this extra disk allows the system to cache up indexes based on the need and usage patterns. This may mean another 1-2 TB or more of disk is allocated for index caching. As a rule 1-5% of actual SnareArchive space usage may be required for indexes. If an index has not been used and new indexes are needed then the older data will be rolled off the system, so the index space is self managed.
Some baseline suggested sizes that customers can use, system sizing’s are a guide only as actual system performance can vary:
...
Besides some smaller systems larger systems like the D4 and D8 servers can be used for example
D4s_v3 4 CPU and 16 Gb of memory for small systems doing around 2,000-4,000 EPS
D8s_v3 8 CPU and 32 GB of memory with 2 times the IOPS as D4 larger systems doing 8,000-10,000 EPS
D8as_v4 with 8 CPU and 32 GB of memory and up to 16 disks for larger workloads.
Other variations and larger sizes can also be used.
Oracle Cloud
The VM.Standard 2.1 .E4.Flex systems offer a good range and very select-able on sizing.
2 CPU and 15 16 GB of memory for very small logging needs or for SAM/AMC only installs
VM.Standard 2.2 4 CPU and 30 24 GB of memory for larger environments that does 2,000-4,000 EPS with bursting to higher loads of 5,000-6,000 range.
VM.Standard 2.4 8 CPU and 60 48 GB of memory for larger environments that does 9,000-10,000 EPS range.
VM.Standard 2.8 16 CPU and 120 128 GB of memory for larger environments doing 20,000 EPS rangesOther variations and larger sizes can also be used.
32 CPU and 256 GB of memory for up to 65,000 EPS systems
Besides the standard system shapes Oracle also offers some very flexible E3.Flex options that allows customers to configure their systems on a CPU by CPU and per GB of memory basis.
Other variations and larger sizes can also be used depending the SAM usage, reporting, event searching and dashboard needs as they may require increases sizing over the above. More memory often has performance improvement as data is cached into memory.
Windows Snare Agent Manager
...