Deploying MISP on AWS
It’s relatively easy to deploy a MISP instance to AWS for the purposes of your own testing and experimentation. We’ll cover how to do that here.However, when looking to deploy an AWS-hosted MISP instance for your organization’s SOC team there lots of important considerations to keep in mind. We’ll go over them in this guide.
Can you deploy MISP to AWS?
Yes! You can definitely deploy MISP to AWS. In fact, we use AWS as the underlying architecture for our hosted, maintained MISP product, CloudMISP.
At minimum, MISP runs on Ubuntu Linux. For serious usage it requires a relational database and file storage for file attachments. These can be provisioned on AWS using services like EC2 (Ubuntu Linux instance), MariaDB (relational database) and EFS (file store).
MISP is also available as a Docker image suitable for use with a container orchestration system like Kubernetes (check out our guide on deploying MISP on Kubernetes).
What should I consider when running a production MISP instance on AWS?
Although it’s relatively easy to get a test MISP instance up and running on an EC2 box, there are many more considerations that go into running a production MISP instance on AWS.
Often, MISP instances are used to store sensitive organisational data. Therefore, following best practices when setting up your MISP instance in the cloud is of the utmost importance.
- MISP upgrades
The MISP open source project employs a relatively aggressive release schedule, somewhere from 12-15 releases a year. These include security fixes, bug fixes, functional improvements, and feature additions.
While the MISP project always factors in backward compatibility for the large community using it, each new release potentially affects integration code relying on particular MISP behaviours.
When deploying MISP on AWS, you’ll need to develop a strategy for testing and applying new MISP releases. You may also want to configure a rollback strategy if any unexpected changes stem from the upgrade.
2. Network access control
You’ll likely want to restrict MISP web application server access on AWS to a nominated series of IP addresses or CIDR ranges. This allows for a range of on-premises and other cloud services (e.g. SaaS logging platforms, SIEMs) to gain network connectivity for integration with MISP.
3. Outbound HTTP request access
By necessity, MISP performs HTTP requests to fetch feeds, poll APIs, push to other MISP instances, and perform enrichments.
You will need to configure AWS to allow a set of outbound HTTP rules per your specifications. This may be as open or narrow as you wish, though we recommend being as specific as possible as an effective deny-by-default control.
4. Logging
From the ground up, all MISP and supplementary components provide logging and metrics streams. This provides metrics on performance, alert on application or component issues, and provide historical records of system activity for troubleshooting or incident response.
Logs can be written to AWS CloudWatch for log parsing, aggregation, analysis, and alerting. Please be mindful of the content of these logs and endeavour to make sure only operational information and not sensitive data are sent.
5. Backups and disaster recovery (DR)
MISP uses two main storage mechanisms for the data it holds: a relational database together with a filesystem for MISP file attachments.
You can use AWS RDS MariaDB for the relational database, and an EFS volume for file attachments. You should create backups using AWS Backup.
In the event a system restore is necessary, you will need to restore your MISP instance to the last backup.
Securely deploying MISP on AWS can be a big undertaking.
We can handle deployment, monitoring and maintenance for you with CloudMISP, our managed MISP service.