Working with Security Teams
Overview
This guide helps you effectively communicate with customer security teams when deploying applications in restricted environments.
Understanding Security Teams
Their Concerns
Security teams are responsible for:
- Risk Management: Minimizing security exposure
- Compliance: Meeting regulatory requirements
- Audit: Maintaining audit trails
- Incident Response: Detecting and responding to threats
Their Constraints
Security teams often:
- Have limited technical knowledge of your application
- Must follow strict policies and procedures
- Need documentation and justification
- Work with multiple teams and priorities
- Are measured on risk reduction, not feature delivery
Communication Principles
1. Speak Their Language
Avoid:
- "We need to open port 443 to the internet"
- "Just allow all outbound traffic"
- "It's just for testing"
Use:
- "We require HTTPS egress to quay.io on port 443 for container image pulls"
- "We've documented all required endpoints with purpose and risk assessment"
- "This is for production deployment with monitoring and audit logging"
2. Provide Context
Explain:
- What: What endpoint/port/protocol
- Why: Business/technical reason
- How: How it will be secured
- When: When it's needed
- Who: Who will monitor it
3. Show You've Done Your Homework
Demonstrate:
- You've identified minimal required endpoints
- You've considered alternatives
- You've implemented security controls
- You've documented everything
The Request Process
Step 1: Document Requirements
Create a comprehensive document (see Egress Requirements Guide):
# Firewall Rule Request: [Application Name]
## Summary
[One paragraph explaining what you need]
## Required Endpoints
### Endpoint 1: Container Registry
- **Purpose**: Pull container images
- **Protocol**: TCP
- **Ports**: 443
- **Destination**: quay.io (IPs: [list])
- **Frequency**: On pod startup
- **Security Controls**:
- HTTPS only (encrypted)
- Through proxy server
- All access logged
- **Alternatives Considered**: Private registry (not feasible due to [reason])Step 2: Risk Assessment
For each endpoint, assess:
Risk Level: Low/Medium/High
Factors:
- Data sensitivity
- Attack surface
- Authentication required
- Encryption in transit
- Monitoring/logging
Mitigation:
- How risks are addressed
- Security controls in place
- Monitoring and alerting
Step 3: Submit Request
Submit through their process:
- Security ticket system
- Change management
- Architecture review board
- Email to security team
Include:
- Complete documentation
- Risk assessment
- Timeline (if urgent)
- Contact information
Step 4: Follow Up
- Check status regularly
- Respond to questions promptly
- Provide additional information if needed
- Be patient (security reviews take time)
Common Security Team Questions
"Why do you need this?"
Good Answer: "Our application requires access to quay.io to pull container images. We've considered using a private registry, but that would require additional infrastructure and delay deployment. All traffic is encrypted (HTTPS) and goes through our proxy server, which logs all access."
Bad Answer: "We just need it to work."
"Can you use a proxy?"
Good Answer: "Yes, we're already using a Squid proxy server. All external traffic routes through the proxy, which provides centralized logging and control. The firewall rule allows egress to the proxy, and the proxy handles external access."
Bad Answer: "No, that won't work."
"What's the security risk?"
Good Answer: "The risk is low because:
- All traffic is encrypted (HTTPS)
- Traffic goes through a controlled proxy
- All access is logged and monitored
- We only access trusted registries
- No sensitive data is transmitted"
Bad Answer: "I don't know, you're the security expert."
"Can you reduce the scope?"
Good Answer: "Yes, we can:
- Use IP allowlists instead of full CIDR blocks
- Restrict to specific ports
- Use a private registry mirror
- Implement caching to reduce requests"
Bad Answer: "No, we need everything."
Building Relationships
Be Proactive
- Engage security early in the process
- Share architecture diagrams
- Explain security controls you've implemented
- Ask for their input
Be Transparent
- Don't hide requirements
- Explain technical details clearly
- Share monitoring and logs
- Report issues promptly
Be Collaborative
- Work together to find solutions
- Compromise when possible
- Respect their expertise
- Learn from their feedback
Handling Rejections
If Your Request is Denied
- Understand Why: Ask for specific reasons
- Find Alternatives: Can you work around it?
- Appeal: If you have strong justification
- Escalate: If business-critical (through proper channels)
Common Reasons for Denial
- Too Broad: Request covers too much
- Insufficient Justification: Not clear why it's needed
- Security Risk: Risk too high for the benefit
- Policy Violation: Against company policy
- Alternative Available: There's a better way
Best Practices
Do's
✅ Document everything thoroughly ✅ Provide risk assessments ✅ Show you've considered alternatives ✅ Implement security controls ✅ Monitor and log access ✅ Engage security early ✅ Be patient and respectful ✅ Follow their processes
Don'ts
❌ Request "everything" ❌ Bypass security processes ❌ Make urgent requests without justification ❌ Ignore security concerns ❌ Skip documentation ❌ Assume they understand your application ❌ Get defensive when questioned
Templates
Firewall Rule Request Email
Subject: Firewall Rule Request: [Application Name] - Egress to [Endpoint]
Hi [Security Team],
I'm requesting a firewall rule for [application name] deployment.
**Summary:**
[One paragraph]
**Required Rule:**
- Direction: Egress
- Protocol: TCP
- Ports: 443
- Destination: [IP/CIDR]
- Source: [Subnet/CIDR]
**Justification:**
[Why it's needed]
**Security Controls:**
[What's in place]
**Documentation:**
[Link to full documentation]
**Timeline:**
[When needed]
Please let me know if you need any additional information.
Thanks,
[Your name]Risk Assessment Template
## Risk Assessment: [Endpoint Name]
### Risk Level: [Low/Medium/High]
### Risk Factors:
- [Factor 1]
- [Factor 2]
### Mitigation:
- [Control 1]
- [Control 2]
### Monitoring:
- [How it's monitored]
### Review Date:
[When to review]