Forward Deployed Engineer 101: Defense and Intelligence (All‑Source Analysis, SIGINT, GEOINT, Mission Planning)

Defense and Intelligence (All‑Source Analysis, SIGINT, GEOINT, Mission Planning)

Forward Deployed Engineer (FDE) Study Guide: Defense & Intelligence (All-Source, SIGINT, GEOINT, Mission Planning)

What This Is

All-source analysis, SIGINT (signals intelligence), GEOINT (geospatial intelligence), and mission planning are the backbone of defense and intelligence operations. As an FDE, you’ll build, deploy, and troubleshoot systems that process classified data, support real-time decision-making, and operate in constrained environments (air-gapped networks, tactical edge devices, or secure cloud enclaves).
Example: You’re deployed to a forward operating base (FOB) where analysts need a real-time SIGINT dashboard to track adversary communications. The system must run on a classified network with no internet access, strict IAM controls, and a 24-hour ATO (Authority to Operate) deadline. Your job isn’t just to write code—it’s to deliver mission-critical capability under pressure, often with incomplete data, shifting requirements, and zero tolerance for failure.

Key Terms & Concepts

• All-Source Analysis: Combining intelligence from SIGINT, GEOINT, HUMINT (human intelligence), and OSINT (open-source intelligence) to produce actionable insights. Tools: Palantir Gotham, Analyst’s Notebook, custom Python/PostgreSQL pipelines.
• SIGINT (Signals Intelligence): Intercepting and analyzing electronic communications (radio, radar, digital signals). Field reality: Often involves raw PCAP files, proprietary protocols, and low-level parsing (e.g., scapy, Wireshark, GNU Radio).
• GEOINT (Geospatial Intelligence): Analyzing imagery, terrain, and geospatial data to support operations. Tools: ArcGIS, QGIS, GDAL, rasterio, geopandas. Field trap: Coordinate systems (WGS84 vs. UTM) can break pipelines if not standardized.
• Mission Planning: Translating intelligence into executable operations (e.g., route planning, target selection, risk assessment). Tools: FalconView, Google Earth Enterprise, custom Python/R for optimization.
• Air-Gapped Deployment: Deploying software in a network with no internet access. Requirements: Offline dependency management (pip download, apt-offline), physical media (USB drives with checksums), and manual approval chains for every change.
• ATO (Authority to Operate): The formal approval process for deploying software in a DoD/IC environment. Key steps: STIG compliance, vulnerability scans, documentation (SSP, SAR), and sign-off from an AO (Authorizing Official).
• STIG (Security Technical Implementation Guide): DoD-mandated security configurations for software/hardware. Example: Disabling SSH password auth, enforcing TLS 1.2+, and setting file permissions to 640. Tool: stigviewer, oscap.
• Bastion Host: A hardened jump server used to access classified networks. Field reality: You’ll SSH into this first, then pivot to other machines. Command: ssh -J bastion-user@bastion-ip target-user@target-ip.
• Tactical Edge: Deploying systems in austere environments (e.g., FOBs, ships, drones) with limited compute, bandwidth, and power. Constraints: No Kubernetes, limited storage, and intermittent connectivity. Solution: Lightweight containers (podman), SQLite, and delta syncs.
• IAM (Identity and Access Management): Managing user permissions in classified environments. Tools: Red Hat SSO, Microsoft Active Directory, or custom LDAP. Field trap: Misconfigured IAM can lock you out of a system for hours (always test with a non-admin account first).
• Ask vs. Infer: In discovery, the customer’s "ask" (e.g., "We need a dashboard") often masks the real problem (e.g., "Analysts can’t correlate SIGINT and GEOINT fast enough"). Field tactic: Ask "Why?" 5 times to uncover the root need.
• Data Provenance: Tracking the origin, chain of custody, and transformations of intelligence data. Why it matters: In court or during a mission, you must prove data wasn’t tampered with. Tools: Apache NiFi, custom hashing (SHA-256), and blockchain-like ledgers.

Step-by-Step / Field Process

Deploying a SIGINT Processing Pipeline in an Air-Gapped Environment

Scenario: You’re at a SIGINT site where analysts need to process raw PCAP files into structured JSON for a dashboard. The network is air-gapped, and you have a 48-hour window to deploy.

1. Pre-Deployment Prep (Your Lab)
2. Build the pipeline locally (scapy for PCAP parsing, pandas for enrichment, FastAPI for the dashboard).
3. Freeze dependencies:
   bash
pip download -d ./deps -r requirements.txt
tar -czvf deps.tar.gz ./deps
4. Create a checksum file:
   bash
sha256sum deps.tar.gz > deps.sha256
5. Package the app (e.g., Docker image or standalone Python):
   bash
docker save my-sigint-app:latest > sigint-app.tar
sha256sum sigint-app.tar > sigint-app.sha256

6. Field tip: Use a Raspberry Pi to test air-gapped deployments before going on-site.

7. On-Site: Transfer and Validate

8. Physically transfer files via approved media (e.g., a STIG-compliant USB drive).
9. Verify checksums:
   bash
sha256sum -c deps.sha256
sha256sum -c sigint-app.sha256

10. Field trap: If checksums fail, do not proceed—assume the data is corrupted or compromised.

11. Deploy the Pipeline

12. Load the Docker image (if allowed):
    bash
docker load < sigint-app.tar
13. Or install dependencies manually:
    bash
pip install --no-index --find-links=./deps -r requirements.txt

14. Field reality: If Docker is banned, use podman or a Python virtualenv.

15. Test in the Customer Environment

16. Run a smoke test with a small PCAP file:
    bash
python process_pcap.py --input test.pcap --output test.json
17. Check file permissions (STIG requires 640):
    bash
chmod 640 test.json

18. Field tip: Always test with real customer data—synthetic data won’t catch encoding issues or proprietary protocols.

19. Hand Off to Analysts

20. Train 1–2 power users (they’ll be your on-site support).
21. Document exactly how to run the pipeline (e.g., a README.txt with commands and screenshots).

22. Field trap: Never assume analysts know how to use the CLI—provide a one-click script or GUI wrapper if possible.

23. Post-Deployment: ATO and Monitoring

24. Submit the system for ATO (if required). Key docs: System Security Plan (SSP), Security Assessment Report (SAR).
25. Set up minimal monitoring (e.g., a cron job to check disk space, a log file rotated daily):
    bash
echo "0 3 * * * /usr/bin/python3 /opt/sigint/check_disk.py" | crontab -
26. Field reality: In air-gapped environments, you can’t use cloud monitoring (e.g., Datadog). Use local tools like logrotate and netdata.

Common Mistakes

FDE Interview / War Story Insights

Interview Questions They’ll Ask

1. "You’re deploying a GEOINT pipeline to a ship with intermittent satellite connectivity. How do you handle data syncs?"
2. Answer: Use delta syncs (only transfer new/changed data), compress data (e.g., gzip), and implement local caching (SQLite) with conflict resolution.

3. Why: Ships lose connectivity for hours; you can’t rely on real-time syncs.

4. "The customer demands a feature that wasn’t in the original scope, and it violates security policies. How do you respond?"

5. Answer: Acknowledge the need ("I understand why this is important"), explain the risk ("This would require opening port 22 to the internet, which violates STIGs"), and offer alternatives ("We could implement X instead, which achieves the same goal without the risk").

6. Why: Customers respect honesty and solutions, not technical jargon or pushback.

7. "You’re on-site and the system crashes during a live mission. The customer is panicking. What do you do?"

8. Answer: Stay calm, reproduce the issue (check logs, ask for the exact steps), implement a quick fix (e.g., restart the service, roll back to a known-good version), and document the root cause for a permanent fix later.
9. Why: In high-stakes environments, downtime = mission failure. Your job is to restore capability first, then debug.

War Stories (How to Frame Your Experience)

• "I deployed a SIGINT dashboard to a classified network where Docker was banned. I had to rewrite the app as a standalone Python script, package it with pyinstaller, and manually install dependencies via USB. The lesson? Always have a Plan B (and C) for deployment."
• "During a disaster response mission, the customer’s GEOINT data was in the wrong coordinate system (WGS84 vs. UTM). I wrote a quick pyproj script to convert it on the fly, saving the team 8 hours of manual work. The lesson? Data validation is non-negotiable—always check formats, encodings, and schemas."
• "I once spent 3 days debugging a pipeline that worked in my lab but failed on-site. The issue? The customer’s firewall blocked outbound DNS requests, and my app was trying to resolve a hostname. The lesson? Test with the customer’s exact network conditions before deploying."

Quick Check Questions

1. You’re deploying to an environment where you can’t run standard Docker images due to security restrictions. What’s your first step?
2. Answer: Check if podman (a Docker alternative with rootless containers) is allowed, or fall back to a standalone binary (e.g., pyinstaller for Python apps).

3. Why: Docker requires root privileges, which are often banned in classified environments.

4. An analyst reports that your SIGINT pipeline is missing data. How do you debug?

5. Answer: First, reproduce the issue with the exact input file they used. Then, check:
   • Is the PCAP file corrupted? (capinfos test.pcap)
   • Are there proprietary protocols the parser doesn’t handle? (scapy or Wireshark for manual inspection)
   • Is the data being filtered out? (Check pandas/SQL queries for unintended WHERE clauses)

6. Why: Missing data is almost always a parsing or filtering issue, not a bug in the core logic.

7. You’re asked to deploy a GEOINT system to a tactical edge device with 4GB RAM and no GPU. What optimizations do you make?

8. Answer:
   • Use vector tiles instead of raster data (smaller, faster to render).
   • Replace geopandas with SQLite + spatialite (lighter than PostGIS).
   • Pre-process data offline (e.g., simplify geometries with shapely.simplify).
   • Use memory-mapped files (numpy.memmap) for large datasets.
9. Why: Edge devices can’t handle the same workloads as a cloud server—optimize for the environment.

Last-Minute Cram Sheet

1. Air-gapped deployment checklist:
2. ✅ Offline dependencies (pip download, apt-offline)
3. ✅ Checksums for all files (sha256sum)
4. ✅ STIG-compliant base OS (RHEL, Ubuntu LTS)
5. ✅ No hardcoded secrets (use env vars or vaults)

6. ✅ Manual ATO documentation (SSP, SAR)

7. Key ports to know:

8. 22 (SSH) – Often blocked; use 443 or 80 for bastion hosts.
9. 5432 (PostgreSQL) – Default for GEOINT databases.
10. 8080 (HTTP alt) – Common for dashboards in restricted networks.

11. 5601 (Kibana) – Often banned; use netdata or grafana instead.

12. Common acronyms:

13. ACO: Authority to Connect (network approval)
14. ATO: Authority to Operate (system approval)
15. STIG: Security Technical Implementation Guide
16. IAM: Identity and Access Management
17. FOB: Forward Operating Base

18. TTP: Tactics, Techniques, and Procedures (adversary behavior)

19. Field traps:

20. ⚠️ Never assume DNS works – Use IPs or hardcode hostnames in /etc/hosts.
21. ⚠️ Always test with real customer data – Synthetic data won’t catch encoding or protocol issues.
22. ⚠️ STIGs break everything – Test with SELinux/AppArmor enabled.
23. ⚠️ Edge devices have no swap – Monitor memory usage (free -h).

24. ⚠️ Classified networks block pip install – Always pre-download dependencies.

25. Quick commands for the field:

26. Check disk space: df -h
27. Check memory: free -h
28. Check open ports: ss -tulnp
29. Check STIG compliance: oscap xccdf eval --profile stig-rhel7-disa /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
30. Parse PCAP: tshark -r input.pcap -Y "tcp.port == 80" -w output.pcap
31. Convert coordinates: pyproj.Transformer.from_crs("EPSG:4326", "EPSG:32618") (WGS84 → UTM)