MVC Proof of Concept: Initial Integration with Wazuh (Container Behavior Analytics)
Problem to solve
Malicious users will try to escalate their privileges as part of an attacking an application and its infrastructure. Generally, this is so that they can then serve malicious content, run compute processes, or takeover a system for their own purposes.
Users can follow best practices to secure apps and infrastructure as much as possible before deploying to production, but in the event that an attacker is able to gain access to a system and start exploiting it, without an IDS/IPS solution in place, it is extremely difficult to detect the attack in time to prevent the attack from succeeding.
Users need to be able to easily install an IDS/IPS system into their environment so they can detect and block these attacks early in the attack lifecycle.
Although Wazuh has initially been chosen as our host-based IDS provider, any one or more technologies that meet the following requirements will be considered:
- File integrity monitoring
- Application allow listing
- Active response / blocking
- Acceptable performance overhead
Nice to Have
- Malware scanning
- Vulnerability scanning
- Configuration vulnerability detection
- No need to give GitLab credentials to production Kubernetes or container environments
Sample Use Cases
- Ability to detect A
rootshell is created
- Sensitive files (e.g.
/bin/ls, etc) are being read or written to that aren't normal for the application
- Shell is run in a container
- Unexpected outbound network connection
- Unexpected network traffic (UDP on uncommon ports)
- Non-authorized container namespace change
- Non-device files written in
- Database program unexpectedly spawning a process
- Launch privileged container / sensitive mount container / disallowed container
- Unexpected updates to users, passwords or permissions
Do an initial prototype showing what an integration of Wazuh into GitLab would look like.
- Resolve unknowns and verify that we can allow users to connect to a Wazuh server with one of the following options:
- By entering connection information for a Wazuh server that has been pre-installed
- By having GitLab install a Wuzuh server into a Kubernetes cluster of their choosing (with ability to easy authenticate to Wazuh server using SSO from GitLab)
- Resolve unknowns and verify that we can allow users to download a Wazuh installation package that containers the Wazuh agent pre-configured to talk to their Wazuh server. The user will then be responsible for manually installing the agent into any containers that they want to have monitored.
Future steps (not in scope of this issue)
- Create a way to view Wazuh alerts
- Create a way to view Wazuh logs
- Create a way to use Wuzah without installing an agent (agentless)
Permissions and Security
Users must be a Maintainer or Owner on the project to be able to have a Wuzah agent auto-installed through the CI/CD pipeline or to deploy a Wuzah server into a Kubernetes cluster.
As this is a proof of concept, no documentation changes are needed.
- Test that a user can use Wuzah with all other Defend capabilities also installed (e.g. WAF &
- Verify that doing malicious behaviors inside a container are indeed detected by Wazuh
- Measure the additional CPU/Memory load placed on a typical container by the Wuzah agent and ensure that the additional load is reasonable (<5% CPU utilization and <100MB RAM consumed)
What does success look like, and how can we measure that?
A successful proof of concept will resolve any major technical risks or unknowns and will inform a final go-no-go decision on Wazuh.
What is the type of buyer?
GitLab Ultimate license is required to use this functionality.
Links / references
- Zeek Network Security Monitor (formerly Bro)
Notes are available in a Google Doc
A recording of the discussion is available on YouTube
Next steps are for Engineering to put together an architecture proposal.