As preparation for the workshop, you can find baseline recommendations for equipment suitable for the deployment of MISP and Bro below.
1. Common requirements
1.1. Operating System
Both MISP and Bro can be deployed on a wide variety of different operating systems. The platform of choice inside WLCG is obviously Linux. Similarly to the myriad of operating systems supported, both tools can be deployed on a variety of different Linux distributions. Sites are free to choose the operating system and the Linux distribution. Nonetheless, we strongly recommend using CentOS 7 / SL 7 / RHEL 7. That’s the distribution used at CERN and all provided resources (installation packages, configuration management code, documentation, scripts, etc) have been developed and tested on CentOS 7. MISP has dependencies on some package versions newer than what’s available with CentOS 7 out of the box. The EPEL (Extra Packages for Enterprise Linux) repository and Software Collections are needed.
2. MISP
2.1. Core of MISP
- System type: Preferable to have a VM (or a container), dedicating a physical box for it would be an overkill.
- Number of cores: 2 cores. This would allow 1 core to be used for the UI and 1 core for background jobs.
- Memory: 4 GB of RAM. Most of the time memory usage will be very low. Exports have the potential of taking a lot of memory (depending on the number of events being exported and the export format). Also, some of the more advanced features (such as caching of feeds) can also take considerable amounts of memory.
- Disk space: 10 GB. MISP itself requires very little space. Attachments (payload samples, artefacts dropped, etc) are stored on the filesystem, not in the database. Still these should be relatively small in size.
2.2. MISP dependencies
2.2.2. MySQL
MISP is using MySQL as a backend for data storage. The database can be either hosted on the local server or can be hosted remotely, if you have a central MySQL server for example. In case you decide to use a remote MySQL server it’s advisable to create a MISP specific username and database in advance of the workshop. The MISP DB user should have access only to the MISP database. There shouldn’t be any particular requirements around that (database should be less than 1 GB in size, in total). Of course MariaDB can be used as a good substitute for MySQL.
2.2.3. Redis
MISP requires Redis for a number of features (state of background workers, caching of feeds, session data, etc). Again, the Redis server can be either co-hosted on the same system as MISP or a remote Redis server can be used. Depending on the set of features used the memory requirements needed for Redis may be significant (in the order of 1-2 GB of RAM).
2.3. HTTPS certificate
It is highly recommended to use HTTPS (TLS) for your MISP instance. While it’s technically possible to use a self generated certificate we highly advice against doing that. Best would be to have a certificate issued by a certificate authority that’s part of the bundle that comes with most web browsers and operating systems. If you don’t have access to a commercial certificate authority you can use one of the free CAs such as Let’s Encrypt. Using a certificate issues by your grid CA would be another possibility although that may pose problems for other peers connecting to your instance and not having your CA’s root certificate installed.
3. Bro
3.1. System requirements
- System type: Preferable to have a physical box dedicated to it, a VM is unlikely to be able to cope with the amount of traffic. Still, if you don’t have a physical box available (we recommend a dual socket server), Bro can be deployed on a VM for testing.
- Number of cores: The recommendation is to have at least 12 physical cores. Rule of thumb is that one core is able to handle 800 Mbps - 1 Gbps of network traffic.
- Memory: At least 64 GB. Each Bro worker requires on average 6 GB of RAM.
- Disk space: As much as you can afford. The amount of disk space you have will determine the amount of log history you can store on disk. This is less important if you are shipping your logs to Elasticsearch of HDFS. Disk space doesn’t necessarily need to be local, you can also use a network filesystem to write to.
- Storage type: HDD or SSD. While SSD will obviously perform better, Bro is not I/O bound as writes are batched together.
Network Interface Cards:
- One NIC to be used by the operating system. This interface is used for the initial OS Installation and for connecting to the box. No special requirements on this one, can be a standard 1 Gbps NIC.
- One NIC dedicated for network traffic mirroring. The speed of this NIC needs to be equal or larger than the network throughput that you are looking to analyse. Also the interface of the NIC needs to be compatible with the interface that you have on the network device from where you’re doing the mirroring. A standard NIC will do here, no need to customised NIC with hardware based offloading.
- One management (IPMI) interface. This could be shared with the NIC used by the OS.
The above recommendations are assuming 10 Gbps of network traffic being monitored. In case the network throughput being monitored is less, the resources needed are obviously reduced. Resources are highly dependent on the number of connections, more than on the network throughput (many small connections are more expensive to monitor than a smaller number of large transfers).
3.2. Network mirror / taps
You need a way for tapping into the network traffic that you are looking to monitor using Bro. There are a multitude of ways for achieving that. Probably the easiest way of doing that is using a switch port SPAN. Ideally you would want to mirror the traffic at least at the outer edge of your network. In case that’s not feasible, for testing purposes you could mirror traffic going to a significant part of your infrastructure (for example traffic to / from your central hypervisor servers hosting your central service VMs).
