Network Security
Complex platform, content, and network decisions where revenue, rights, and customer experience intersect.
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify and diagnose before investing in an in-line evaluation and benchmark.
-
Qualification
Confirm budget window, decision process, required acceptance criteria, and timeline before investing in an in-line evaluation.
Qualification Questions
Evaluation & performance criteria (short readiness check)
- Which independent detection or efficacy validations will you want the solution to pass?
- What minimum throughput and acceptable added latency must the solution demonstrate with all inspection features (including TLS 1.3 decryption) enabled?
- Please specify the realistic peak throughput and acceptable latency for your busiest site(s) (brief numbers)
Inline evaluation readiness
- Are you willing to run a 2–4 week inline, live-traffic evaluation on production links (with agreed guardrails) as part of acceptance testing?
Policy migration and estate scope
- Roughly how many sites and throughput tiers will the rollout cover?
- Approximately how many firewall policies or rules will need to be migrated across the estate?
- Do you expect to use professional services for policy migration, parallel operation, or acceptance validation?
Commercial fit and timeline
- Is there an allocated budget range for an enterprise license and multi-site rollout?
- Who is the primary decision maker for this purchase and which roles will influence the final decision? (roles only)
- What is your target decision timeframe and target go-live window?
-
Enterprise Discovery
Map stakeholders, current firewall estate, policy complexity, performance constraints, and measurable success signals.
Discovery Questions
A quick snapshot of your estate
- Tell me briefly how many sites and what types make up your network security estate today
- Provide the approximate counts for branch, campus, and data center locations (choose the closest range)
- Walk through your current hardware and virtual form factors for perimeter and east-west inspection
- Select the primary management and logging model your team uses
- Identify who has final procurement authority for firewall platforms in your organization
- Name the single metric that, if unmet during evaluation, would make you walk away immediately
Where traffic is most likely to be missed
- If a failure to inspect traffic produced a breach tomorrow, where would it most likely begin in your estate?
- Describe the most recent incident where expired subscriptions or end-of-life appliances reduced inspection coverage, and the business impact that followed
- How many critical application flows in your environment require TLS decryption for meaningful inspection
- When your team runs throughput tests with every security service enabled, which site tiers consistently miss your latency or throughput targets?
- Calculate the primary business costs you track when inspection is reduced, for example mean time to detect, compliance exposure, or lost application revenue
- Point to who receives the first alerts and what their escalation SLA is when an application breaks after a policy change
- What single infrastructure weakness would force you to accelerate procurement within the next 30 days?
All the humans who sign, run, and stop this project
- Which cross-functional team is most likely to block this project if their concerns are not addressed up front?
- Provide a list of internal stakeholders who must sign the enterprise license and who will authorize the pilot
- Estimate the headcount and roles available to support an inline live-traffic evaluation for two to four weeks
- Who owns APIs, access credentials, and network change approvals for each major site class
- Describe the typical internal approval timeline for pilots and enterprise agreements, from technical sign-off to legal and procurement
- If the pilot proves detection and throughput, what internal obstacle could still prevent you from signing within the quarter?
The rules that trip migrations and break apps
- What part of your rulebase carries the highest risk of breaking critical applications during migration?
- Provide the approximate count of firewall rules, including nested objects and references, in your primary policy set
- Explain your policy cleanup cadence and who is accountable for removing stale rules
- Which rule patterns or application exceptions typically require manual intervention during migration
- How often do policy-related incidents occur after changes, and what is the average operational cost when they do
- What single rule or application group, if mis-migrated, would force you to pause a rollout until fixed?
Will it hold up under real traffic and decryption
- Which performance metric is nonnegotiable for your network team (latency added, sustained throughput, or connection closure rate)?
- Estimate your 95th percentile throughput and typical peak utilization for the top data center links you will test
- List the dominant TLS versions and cipher suites in your traffic mix and approximate percent of total sessions they represent
- How confident are you that TLS decryption at scale can be performed while meeting privacy and compliance requirements
- Walk me through your current benchmarking process, including tools, test duration, and pass/fail thresholds
- Which pass/fail results from independent efficacy reports would you require to accept detection claims
- If a vendor misses latency or detection thresholds during the pilot, which contractual remedy or warranty would you insist on before proceeding
The other options on your table
- Who else are you actively testing or strongly considering right now
- Select the alternatives you are evaluating
- For the incumbent to remain in place, which three conditions would have to be demonstrably true
- Has anyone inside proposed solving inspection and policy migration without an outside vendor, and if so, what resource plan backs that proposal
- How long could you continue with the current approach before a security gap becomes unacceptable
- What would have to change about the incumbent or internal plan for you to cancel this evaluation
What must be true to run an inline pilot
- Which single integration or access constraint would stop an inline live-traffic evaluation before it begins
- List critical third-party systems that must integrate during evaluation, such as directory services, SIEM, orchestration APIs, or logging endpoints
- Do you have maintenance and change windows at target sites and how far in advance are they typically booked
- Who will provide on-site access, network changes, and firewall credentials for each site class
- Provide a short summary of your logging capacity and whether it can absorb trial volumes without throttling or additional costs
- Are there regulatory or compliance approvals required before decryption or log export can occur, and what is their typical lead time
- If APIs, credentials, or maintenance windows cannot be provided, would you accept a mirrored evaluation instead, or is inline mandatory for your acceptance criteria
- Select the technical owner who will be responsible for coordinating the pilot (choose one)
If the pilot checks the boxes, what happens next
- If the pilot proves throughput and detection, what approvals remain to finalize an enterprise license
- Which measurable KPIs must be met, including numeric thresholds for false positives, detection rate, throughput, and added latency
- How long of a parallel operation window do you require per site before decommissioning the incumbent
- What payment and contract terms shorten your procurement timeline (billing cadence, term length, cancellation clauses)
- Who will be the executive sponsor and who will be the procurement owner who signs the final agreement
- What's the earliest realistic date you could start a live-traffic evaluation if approvals and access are ready
- If the pilot meets the KPIs, what single remaining obstacle could still delay a purchase beyond the quarter
- Select your preferred pilot duration
- Which evidence will you accept to approve purchase, select all that apply
-
-
Solution Evaluation
Run an in-line, live-traffic evaluation and acceptance testing (third-party efficacy checks and throughput benchmarks) against the buyer's criteria.
- decision_readiness
- current_state
- desired_state
- success_criteria
- gaps
- stakeholders
- stakeholders
- success_criteria
- current_state
- desired_state
- gaps
- decision_readiness
- gaps
- stakeholders
- decision_readiness
- current_state
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
-
Solution Scope
Define hardware tiers, subscription and threat-intel coverage, policy migration boundaries, professional services, and measurable acceptance criteria.
Scope Configuration
- Provision and Install Physical Firewalls
- Deploy Virtual Firewall Instances in Cloud
- Migrate Firewall Policies from Prior Provider
- Run Parallel Cutover and Application Flow Validation
- Configure TLS 1.3 Decryption and Key Management
- Enable Intrusion Prevention (Signatures + Behavioral)
- Enable Inline File Analysis and Sandboxing
- Integrate Threat Intelligence Feed Updates
- Configure DNS Security and URL Filtering
- Centralized Management and Policy Orchestration Setup
- Deploy Log Aggregation and Traffic Analytics
- Optimize Rules and Automate Policy Cleanup
- Implement Zero Trust Microsegmentation Policies
- Activate Enterprise Licensing and Subscription Bundles
Scope Questions
Provision and Install Physical Firewalls
- Upload the site list (CSV) you will provide for physical installs containing site name, building/rack, available rack units, available power (watts) and cross-connect ID.
- How many appliances do you plan to install at each throughput tier (examples: 1 Gbps, 10 Gbps, 100 Gbps)?
- Specify per-site rack and power constraints including available U and PDU redundancy for each data center or campus.
- Confirm the maintenance window(s) you can allow per site (local time ranges, e.g., Mon 00:00–04:00) for hardware installation and reboots.
- List the single-line network diagram files you will provide for each site and the file formats (PDF, Visio, other).
- State the performance target each physical appliance must sustain with all inspection services and TLS 1.3 decryption enabled (specify Gbps at target utilization, e.g., sustain 20 Gbps at 80 percent) and describe how you will validate it.
Deploy Virtual Firewall Instances in Cloud
- Which cloud regions and VPC/subnet IDs will host virtual firewall instances? Provide a per-region list.
- Estimate baseline and peak inter-VPC throughput (Gbps) per region that virtual instances must handle.
- Describe any cloud instance sizing constraints you require (maximum vCPU, memory, instance family restrictions).
- Are there existing transit gateway or virtual router attachments that cloud instances must integrate with?
- Select the cloud key management approach you will use for private keys and TLS certificates.
- Identify the flow export and logging endpoints for cloud instances including hostname, port, and expected log format (CEF, JSON, other).
Migrate Firewall Policies from Prior Provider
- Attach or provide the rules export or inventory you can share (security policies, NAT policies, object lists) as CSV or API dump.
- Provide numeric totals for the migration: number of policies, total rules, NAT entries, and named objects.
- What migration completeness threshold will define acceptance (for example: at least 99 percent of rules migrated with no application-impact incidents) and what evidence will you accept (rule-by-rule test logs, traffic captures)?
- Indicate policy constructs you want excluded from automated translation such as dynamic objects, inline scripts, or unmanaged zones.
- Name the rule owners for each major application group and the person who will sign off on translated rule test results.
- Specify the duration you require for parallel operation in days before legacy decommissioning.
Run Parallel Cutover and Application Flow Validation
- List critical application flows to validate by source IP/subnet, destination IP/subnet, ports and expected latency or throughput constraints.
- Provide the test scripts or synthetic transaction steps you will run for application validation (file transfer steps, API call sequences, login workflows).
- Choose your preferred live-traffic validation method: full inline, port mirror with sampling percentage, or selective mirroring by VLAN.
- Define rollback triggers that must cause immediate failback to legacy devices and include exact thresholds (packet loss percent, latency ms, application error rate).
- Identify per-site emergency contacts and the owner responsible for application flow acceptance at each location.
- When do you want performance validation checkpoints during the staged rollout (for example after policy migration, after 24 hours, after 7 days)?
Configure TLS 1.3 Decryption and Key Management
- Which certificate authorities and certificate stores will you use for interception certificates (on-premise PKI, enterprise CA, cloud CA)?
- Where will private keys for intercepted sessions be stored and accessed (HSM, KMIP server, software keystore)?
- List domains or subject alternative names (SANs) that must be excluded from decryption for compliance or application compatibility.
- Indicate key rollover frequency and certificate renewal procedures you require (in months).
- Explain how you will distribute the interception CA to endpoints or load balancers when required by your environment.
- Do you require special handling for TLS 1.3 forward secrecy ciphers or session resumption behaviors that affect throughput?
Enable Intrusion Prevention (Signatures + Behavioral)
- What minimum detection metrics from your third-party efficacy report must be met for intrusion prevention acceptance (for example true positive and false positive rates over the PoC) and which report artifacts will you provide as evidence?
- State the signature update cadence you require and any change-window restrictions for signature pushes.
- List custom behavioral baselines or anomaly templates you want created for internal application traffic patterns.
- Who will own IPS alert triage and what SLA do you require for initial investigation response times?
- Indicate the maximum acceptable false positive rate for blocking actions before a rule must be moved to monitor-only mode.
- Which telemetry fields must be present in IPS alerts exported to your SIEM (examples: source user, process hash, application id)?
Enable Inline File Analysis and Sandboxing
- Which file types and maximum file sizes should be sent to inline sandboxing (for example Windows PE up to 10 MB, Office documents up to 5 MB)?
- Select blocking mode for sandbox verdicts: synchronous block, asynchronous quarantine with follow-up, or monitor-only.
- Map sandbox verdict categories to enforcement actions (block, quarantine, alert) and identify who will review high-risk verdicts.
- Provide allowed sample upload destinations for sandbox analysis (SFTP host, object storage) and the preferred authentication method.
- Define the sandbox analysis turnaround SLA you require for blocking decisions in minutes.
- Are there data residency or export-control restrictions for sample uploads that require in-region processing?
Integrate Threat Intelligence Feed Updates
- Select the threat intelligence indicator families you require (IP reputation, URL reputation, file hash indicators, YARA rules).
- Which delivery method do you support for intelligence feeds and which authentication mechanism will the endpoint require (API pull, SFTP push, STIX/TAXII)?
- List the enforcement actions you want mapped to TI categories and the per-category priority for blocking or tagging.
- Who will manage TI subscription entitlements and which internal team will verify feed freshness?
- State the maximum acceptable indicator-to-enforcement latency you require (specify seconds or minutes).
- Indicate any internal allowlists or deny-lists that must be kept separate from external feeds and how you will provide them.
Configure DNS Security and URL Filtering
- Provide the list of internal DNS zones and any split-horizon configurations that affect DNS inspection.
- Which URL categorization rules and category blocks do you require and who will maintain the exception list?
- What DNS query logging retention period and export endpoints do you require for forensics (days)?
- Do you require recursive DNS proxying or forwarding to enterprise resolvers while still inspecting DNS traffic?
- Specify how blocked web responses should be presented to end users (block page, redirect to captive portal, or TCP reset).
- List enterprise URL allowlists that must be preserved during migration and the file format you will provide.
Centralized Management and Policy Orchestration Setup
- How many managed devices and logical device groups will you enroll initially and at steady state?
- Provide the source-of-truth for policy definitions and naming conventions (git repo, CSV, spreadsheet) you require for orchestration.
- Describe role-based access control needs for policy authors, approvers and auditors and any compliance sign-off required.
- Do you require automated policy push schedules or manual approval gating per maintenance window?
- Which API integration endpoints must the management platform connect to (ticketing, CMDB, SIEM) and what authentication method will each use?
- What rollback and audit trail retention requirements must the central management meet (number of days and minimum audit fields)?
-
Mutual Commit
Finalize enterprise license terms, SLAs, services for policy migration and parallel operation, and the commercial schedule.
Agreement Modules
- Master Services Agreement (MSA)
- Statement of Work (SOW) — Policy Migration & Parallel Operation
- Enterprise License Agreement (ELA) / Software Licensing Agreement
- Service Level Agreement (SLA)
- Order Form / Commercial Schedule
- Migration & Acceptance Addendum
-
Deployment
Lock readiness facts and configuration values before execution begins.
-
Pre-Deployment Readiness
Confirm per-site owners, maintenance windows, access requirements, and parallel-operation plans the rollout depends on.
Pre-Deployment Questions
Environment and site access
- Who is the owner of the canonical site roster/CMDB for this rollout (name, role, email)? This contact will provide the per-site list and updates.
- Are per-site maintenance windows finalized for all sites in scope? (so we can schedule cutovers to avoid business impact)
- Do the target sites permit inline, live-traffic evaluation during the maintenance window? (this determines whether we run in-line proof-of-concept traffic)
People and ownership
- For cutover execution, will on-site technical owners be present per site, or will a centralized field team perform cutovers? (tell us which model applies so we can plan travel and shift coverage)
- Provide the single escalation contact for rollout outages (name, role, phone or email) — or enter 'site-specific' if escalation varies by location. This is the 24x7 point the deployment team will escalate to.
- Which approval owners have been assigned and can approve maintenance windows and post-cutover validation? (select all that apply)
Parallel operation and cutover plan
- Will the rollout use parallel operation (new appliance inline alongside legacy) at each site?
- Are rollback triggers and sign-off criteria defined for cutover and rollback (examples: latency thresholds, packet loss, application failure)?
- Who owns policy migration validation and final sign-off? (select the role(s) responsible — we will collect specific contacts in the DeploymentConfig)
Timing and constraints
- What is the target start date for the staged rollout? Provide a date (YYYY-MM-DD) or 'TBD' — this schedules resource planning.
- Are there blackout dates, regulatory freeze windows, or major events that prohibit maintenance during the rollout? If yes, indicate whether they are global or site-specific.
-
Configuration Details
Capture exact deployment values: appliance models per throughput tier, interface and IP plans, TLS key handling approach, logging/analytics endpoints, and integration credentials.
Configuration Details
ENVIRONMENTS & ENDPOINTS
- Enter the deployment environment name (single token used by the build). Default: "production"
- Enter the management console URL (format: https://your-mgmt-host.example.com). Default: "https://mgmt.example.com"
- Enter the primary log collector FQDN the appliances should send logs to (format: logs.example.com). Default: "none" — leave blank if not applicable
APPLIANCE MODELS & THROUGHPUT TIERS
- Select the appliance model to deploy for the 1 Gbps (branch) throughput tier
- Select the appliance model to deploy for the 10 Gbps (campus/regional aggregation) throughput tier
- Select the appliance model to deploy for the 100 Gbps (large data center) throughput tier
- Select the chassis/modular platform for multi‑terabit data-center deployments (if applicable)
NETWORK INTERFACES & IP PLANS
- Enter the interface naming / assignment template the build should apply (format guidance: use token pairs like "mgmt=eth0;data1=eth1;ha=eth2"). Default: "mgmt=eth0;data1=eth1;data2=eth2;ha=eth3"
- Enter the management IP addressing scheme the build should provision for each site (format: CIDR or literal 'use existing'). Default: "use existing"
TLS, LOGGING & INTEGRATIONS
- Select the TLS key handling approach for traffic inspection (Default: customer-managed keys via your secrets manager)
- Select the source of TLS certificates for appliances (the build will request certificate NAME only; certificate secret exchanged via your secrets manager at deployment)
- Select the log transport protocol the appliances should use to send events (Default: Syslog over TLS)
- Enter the non-secret identifier for your SIEM/analytics integration account (format: account-name or service-account-id). The secret/API key itself will be exchanged via your secrets manager at deployment
-
Deployment
Execute staged rollout with policy migration runs, parallel cutovers, performance validation checkpoints, and clear owners for each site.
-
-
Success
Validate detection efficacy and performance against acceptance criteria, capture lessons learned, and maintain a channel for issues and enhancements.
Success Reviews
- Go-live Health Check (weeks 1-4)
- First Measurement Review (weeks 4-10)
- Acceptance Gate and Formal Acceptance (around day 90)
- Monthly Operational Review (first 3 months post-acceptance)
- Quarterly Success Review
Issues & Enhancements
- Close resolved tickets and update the shared incident log with test evidence for closure.
- Publish the formal acceptance record that includes per-criterion pass/fail, signatory name, and any conditional remediation commitments.
- Execute the incumbent decommission plan or retention configuration and provide evidence of archive and contract disposition.
- Open remediation tickets for conditional items with targeted resolution dates and required verification tests.
- Trend review of detection efficacy and performance
- Demonstrate that detection and performance metrics remain within thresholds recorded in Solution Evaluation or agree corrective steps where they do not.
- Reduce open remediation tickets with clear resolution dates and owners.
- Document any recurring incidents and an agreed mitigation plan.
- Re-confirm success criteria and owners
- Schedule targeted throughput retests for any site showing performance degradation and produce a remediation plan if thresholds are missed.
- Apply agreed policy tuning changes and run a validation pass on affected application flows.
- Quarterly outcome summary
- Confirm that long-term metrics such as policy migration validation pass rate and mean time to remediate incidents meet expectations recorded in Solution Evaluation or have an agreed remediation path.
- Document lessons learned and commit them to the shared knowledge base for future deployments.
- Establish a prioritized issues and enhancements backlog with review dates and expected verification methods.
- Publish the quarterly lessons learned document and update runbooks or playbooks affected by the findings.
- Add persistent issues to the enhancement backlog with a proposed verification test and review date.
- If needed, propose an increased review cadence for any site or cluster that continues to miss performance or detection targets.
- Confirm the deployment items in the Solution Evaluation stage are present and assigned to owners.
- Agree remediation actions for any production-impacting issues with completion dates.
- Open issues logged in the shared issue channel with an owner and target date.
- Publish a deployment health report summarizing open incidents, owners, and target resolution dates.
- Enable the agreed escalation contact list and communication channel for production-impact incidents.
- Collect packet captures and performance logs for any incidents flagged as high impact.
- Present first measurement data versus targets
- Validate whether true positive detection rate and throughput with TLS 1.3 decryption meet the numeric targets recorded in Solution Evaluation.
- Document root causes for any deficits and agree concrete corrective actions with dates to reach the acceptance gate.
- Confirm the data sources and signatory who will participate in the acceptance decision.
- Run targeted signature tuning and re-test throughput with TLS 1.3 decryption under the same traffic mix and report results.
- Produce a gap analysis for each failed metric including packet-level evidence and remediation steps.
- Prepare the acceptance packet that aggregates the measurement dashboards, raw logs, and the proposed signatory list for the Acceptance Gate meeting.
- Restate each numeric acceptance criterion from Solution Evaluation
- Produce a documented acceptance decision with the buyer's named signatory and per-criterion pass/fail results.
- List remediation items for any conditional outcomes with owners and firm completion dates.
- Confirm legacy system wind-down status and next steps to avoid dual-operation or shadow usage.
- Open incident and ticket burn-down
- Lessons learned and process improvements
- Present outcome data against each criterion
- Diagnose gaps and root causes
- Deployment and migration validation
- Policy migration residual issues and targeted re-validation
- Document pass/fail per criterion and capture formal acceptance decision
- Persistent issues and enhancement backlog
- Agree corrective actions and timeline to acceptance gate
- Early adoption signals and usage patterns
- Confirm ongoing support and verification cadence
- Blockers and open issues with owners
- Confirm readiness criteria for the Acceptance Gate meeting
- Confirm SLAs and escalation posture
- Remediation plan for any failed or conditional items
- Agree immediate remediation actions and communications
- Retire the incumbent checklist and fallback closure