-
Notifications
You must be signed in to change notification settings - Fork 0
Deployment Scenarios
This page covers some theoretical deployment scenarios for the Soft Data Diode Tools (although I've only used it for the first one. PRs to this wiki are welcome!). Alot of this is really pie-in-the-sky, but I think all the listed scenarios are potentially valid.
For basic setup, see the main README.
This is the original use case that prompted development of these tools. A corporate network needs to share internal resources (dashboards, cameras, files) with external parties or cloud services without exposing the internal network to attack. We used these tools to eliminate a DMZ, which is always a risky thing to have hanging out on the internet and a common point of initial entry for adversaries.
- Sender: Internal corporate network
- Receiver: Cheap-and-cheerful cloud VPS
- Firewall: Corporate edge firewall with NAT
- Corporate firewall provides NAT, making return traffic difficult
- Internal network protected by multiple layers of security
- Cloud server is untrusted and potentially exposed
- This scenario benefits most from the NAT protection described in Security Model and Hardening
- The corporate firewall's SNAT capabilities can be leveraged for additional protection
- Consider using the eBPF packet forwarder for additional protection and lower CPU load
- Configure firewall SNAT to blackhole address
- Implement iptables rules on sender side
- Set up switch ACLs if the feature exists and you've got a good choke point
- eBPF packet mangling
Devices in an OT network need to send data to IT systems without exposing the OT network to potential compromise.
- Sender: OT network (control systems, HMIs)
- Receiver: IT network (historians, monitoring, analytics, dashboards)
- Firewall: Firewall between IT and OT, hopefully employing Purdue zones with an iDMZ
- OT networks often have strict security requirements. Maybe regulations
- May involve actual air-gaps or data diodes
- High consequence if compromised
- Often contain insecure devices and protocols that need all the protection they can get
- This scenario may benefit from combining with hardware data diodes
- Extremely conservative approach recommended
- All mitigations should be implemented
- Hardware firewall with SNAT rules
- Switch ACLs at network boundary
- OS-level iptables with strict rules
- eBPF packet forwarder
- Comprehensive monitoring and alerting
Resources in one cloud provider need to be shared with another cloud provider. Probably only useful if you need to send from a high-security cloud environment to a lower security one.
- Sender: Cloud provider A (source environment)
- Receiver: Cloud provider B (target environment)
- Firewall: Cloud provider security groups
- There may or may not be NAT between cloud providers
- If they're the same provider they might egress directly to each other
- Without NAT, you must rely more heavily on other mitigations
- Cloud security groups can be configured to block return traffic
- Consider using the eBPF packet forwarder for additional protection and lower CPU load
- Both sender and receiver should be hardened equally
- Cloud security group rules blocking return UDP
- OS-level iptables rules
- eBPF packet mangling
- Comprehensive monitoring on both sides
A service provider needs to share monitoring/video/status/file data with clients without giving clients any access back into the provider network.
- Sender: Service provider network
- Receiver: Client network or client-accessible server (eg VPS)
- Firewall: Provider edge firewall
- Provider network contains multiple customer data
- Client network may be untrusted
- Compliance requirements may be strict (and there's just a big business risk in being embarrassed by privacy or data breaches)
- Consider separate receiver instances per client
- Encryption keys should be unique per client
- Implement strict network segmentation
- Maintain audit logs for peace of mind/auditing/compliance/etc
- Per-client encryption keys, service accounts, authentication and network segmentation
- All standard mitigations
- Regular security assessments
Branch offices/Headquarters need to send monitoring data to each other without exposing their networks. Could be for things like acquisitions where you can't fully integrate before doing an audit.
- Sender: Office network 1
- Receiver: Office network 2
- Firewall: Office edge device
- Branch offices may have limited security expertise
- With multiple offices to manage configs could get unwieldy
- Varying network quality and reliability
- Standardize configurations across branches. VM templates, etc
- Implement central monitoring and management
- Consider bandwidth limitations at branch offices
- Use lower frame rates and resolutions to conserve bandwidth
- Standardized OS-level firewall rules
- Automated deployment, configuration and patching
- Centralized logging and monitoring
- Regular security updates and assessments
Development environments may need to share build status, test results, or monitoring data without exposing the dev network.
- Sender: Development network
- Receiver: Testing team or management network
- Firewall: Standard corporate firewall
- Lower risk tolerance than production
- Rapid changes to configurations
- Need for flexibility
- Easier to implement and test mitigations
- Good scenario for learning the tools
- Can use less aggressive hardening
- Valuable for testing configurations before production deployment
- Basic OS-level firewall rules
- Monitoring for educational purposes
- Document lessons learned for production use
MSP needs to monitor customer environments without creating potential attack vectors into customer networks.
- Sender: Customer network
- Receiver: MSP monitoring infrastructure
- Firewall: Customer edge firewall
- Have to maintain customer security and trust
- Multiple customer networks to manage
- Need for strong separation between customers
- Unique encryption keys per customer
- Separate receiver instances or ports per customer
- Customer-controlled firewall rules
- Transparent operation preferred
- Comprehensive audit logging
- Clear documentation for customers
Move data from production into a DR or cleanroom environment without exposing it to attack
- Sender: Corporate backups or fileservers
- Receiver: DR environment
- Firewall: Corporate firewall
- Moving between zones that need to mutually maintain their integrity means an airgap is a must
- May need more protections, like a time-based "airlock" configuration
- Data corruption or cryptolocker'd files will get passed through, but attackers will be unable pass through to eg delete or encrypt backups
- Firewalls can be compromised, so actual airgaps are critical here
- Other mitigations are great, but a true airgap should make them optional
- Airgap
- Maybe a double airgap (airlock)?
- Still need virus and threat scanning
- Regular security reviews for things like unintentional cross-connects
-
More mitigations are probably better than less, but think about the consequences of implementing and maintaining them
-
Test incrementally and verify each mitigation individually before combining
-
Document everything like configuration, testing results, and internal how-tos
-
Have things like watchdog timers and test everything for autostart on reboot
-
Periodically review and test configurations
-
Return to the main README for basic usage