Threat Detection & Prevention

Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30

To preserve the confidentiality, integrity, and availability of the PHI Foundry stores, processes, and transmits on behalf of physician practices, Foundry runs layered threat detection and prevention controls, across endpoints, networks, the AWS control plane, and the application surface, and subscribes to the threat intelligence feeds that warn us before something hits.

1. Purpose & scope

This policy applies to every system that participates in delivering Foundry’s services to physician practices: workforce endpoints (laptops, mobile devices), the AWS production environment (the clinical workflow database, Foundry’s FHIR service, supporting services, and the workloads running on top of them), the customer-facing web surfaces, and the multi-tier agent runtime. It defines the threat-detection and prevention controls Foundry operates, the signals they generate, and how those signals flow into Incident Response.

2. Policy statements

Bioscope Foundry policy requires that:

(a) All critical systems, assets, and environments, including the AWS production environment, workforce endpoints, and the agent runtime, must implement real-time threat detection or prevention controls appropriate to their tier.

(b) Detection signals must aggregate to a central monitoring and alerting surface that the Security function reviews continuously; high-severity alerts page the on-call engineer.

(c) Foundry monitors threat-intelligence sources relevant to its dependency surface and operating environment, and triages relevant advisories through the Vulnerability Management process.

3. Endpoint malware protection

All workforce endpoints (laptops, desktops) must run endpoint protection.
- Endpoint detection and response (EDR): the EDR agent provides behavior-based threat detection and quarantine.
- Hosts are scanned continuously for malicious binaries in critical paths and on file events; additional scheduled scans run at reboot and on a recurring cadence.
- Signature and behavior models are kept current through automatic vendor updates.
- Logs of scans and detections are retained per System Audits & Monitoring.
Detected malware is evaluated and contained following the Incident Response process. Endpoints suspected of compromise are isolated from Foundry’s networks until cleared.
Foundry endpoints are issued for Foundry business use. Personal use is restricted per HR & Personnel Security.

4. Firewall & network controls

Firewall protection is implemented at three layers:

Network: VPC security-group and firewall rules scope ingress and egress to and from the healthcare data account; edge WAF and DDoS protections are being finalized as part of the network-hardening rollout. The healthcare data account sits behind network perimeter controls to limit exfiltration paths.
Host: local firewalls are enabled on managed workforce endpoints; production workloads run inside the AWS network perimeter and accept only mTLS-authenticated service-to-service traffic.
Application: a web application firewall protects customer-facing web surfaces against common web attacks (XSS, injection, scraping, DoS). Marketing-tier surfaces (marketing-website, pureethosmed-website) run on Cloudflare Workers Static Assets behind Cloudflare’s standard protections.

5. Network intrusion detection

5.1 Detection in the AWS production environment

Foundry’s PHI-handling production environment runs in AWS. Real-time detection in that environment is built from:

AWS CloudTrail from the healthcare data account is ingested by cloud-native threat-detection tooling for anomaly and threat detection; VPC flow-log coverage is being finalized as part of the network-hardening rollout.
Edge protection for internet-facing endpoints via cloud-provider WAF and DDoS services, being finalized as part of the network-hardening rollout.
network perimeter controls restrict data movement out of the healthcare data account. Alerts fire on perimeter violations.
Foundry’s FHIR service access logs are monitored for unusual patterns: bulk reads, off-hours access, access by service accounts outside their declared scope.

5.2 Detection in office and home networks

Foundry is a remote-first organization without a managed office network. Workforce members connect from home networks and trusted public networks. Endpoint posture (EDR + MDM) and federated identity compensate for the absence of an office firewall; access to production is mediated by identity, not network position.

6. Host intrusion detection

Host-based detection is provided by the EDR agent on workforce endpoints and by container/host runtime monitoring on provider-managed compute. Behavioral detections that match known attack techniques (e.g., suspicious child processes, credential dumping, persistence implants) are alerted to Security in real time.

7. Web application protection

Customer-facing web surfaces are protected against common attacks (SQL injection, XSS, CSRF, DoS/DDoS) by their hosting platform’s WAF:

conductor application: edge protection on the load balancer in front of the application services, being finalized as part of the network-hardening rollout.
Marketing surfaces (marketing-website, pureethosmed-website), Cloudflare Workers Static Assets with Cloudflare’s standard managed rule set and rate limiting.

The application layer also implements defense-in-depth against common web vulnerability classes per Foundry’s secure-development standards and the 2026-02-21 platform review (see Secure SDLC §5).

8. Agent-runtime threat controls

The foundry-master-agent runtime introduces threat-detection considerations distinct from a traditional web application: the system is multi-tier (Atlas at Tier 0; executives, ops, clinical agents, and sandboxed workers across Tiers 1–4) and operates on behalf of human principals over PHI-eligible mounts. The runtime’s HIPAA-aware invariants (documented in Foundry’s internal engineering guides) are themselves a class of detection: any code path that would let a Tier-4 Moltworker hold PHI, that would let a clinic-scoped Tier-3 agent reach another clinic’s data, or that would let free-text PHI escape into audit logs, fails the test suite. Specifically:

Mount-security checks enforce the tier-to-mount contract: Moltworkers cannot mount PHI-eligible volumes.
Beacon Layer redaction separates sanitized physician-facing insight surfaces from raw PHI; the Beacon Layer never exposes raw PHI or peer-private memory.
PHI-event routing in the agent runtime sends PHI-relevant events through a dedicated audit-event channel rather than the general object registry, with audit codes (not free-text content) emitted to the audit log.
Atlas Vector Engine placement and migration decisions are deterministic and auditable; placement violations are detectable in post-hoc audit.
nix flake check --impure runs after every flake change and is part of the gate before any agent build is promoted to production.

9. Centralized SIEM & correlation

Security events and alerts from endpoint EDR, AWS detection, WAF, Foundry’s FHIR service access logs, and application audit logs are aggregated to a central detection surface, the centralized log platform (rollout in progress). Correlation rules surface multi-source anomalies (e.g., an unusual workforce login followed by an out-of-scope FHIR query). High-severity alerts page the Security on-call engineer; lower-severity alerts are reviewed in the routine security cadence. Retention of security-relevant logs follows the schedule defined in System Audits & Monitoring; PHI never appears in those logs by design.

10. Threat intelligence monitoring

Foundry monitors a tailored set of threat-intelligence sources to anticipate threats relevant to its stack:

CISA advisories: Known Exploited Vulnerabilities catalog and emergency directives.
provider security bulletins: including AWS advisories for ECS, RDS, Lambda, IAM, and CI/CD tooling.
AI provider security disclosures: Anthropic and OpenAI security bulletins and model-card security notes (relevant because the agent platform consumes their APIs).
Upstream maintainer advisories for the dependencies of conductor (TypeScript / Node ecosystem, Vite, React, Hono, FHIR client libraries) and foundry-master-agent (Rust crates, Nix flake inputs).
Health-sector ISAC feeds: Foundry is establishing participation in healthcare threat-intelligence sharing communities for healthcare-specific threat sharing.
Vendor intelligence: feeds bundled with the endpoint EDR and WAF products feed automatically into their detection engines.
Regulatory monitoring: the Security and Privacy Officer monitors HIPAA, OCR, and state breach-notification law changes; updates to other frameworks tracked in the framework crosswalk; and updates to Foundry’s secure-development standards.

Relevant advisories are triaged into Linear under the Security project and dispositioned via the Vulnerability Management process.

11. Roles & responsibilities

Security Officer: owns this policy, the detection-tool inventory, and the threat-intelligence subscription list. Reviews high-severity alerts and tunes detection rules.
Security on-call: receives high-severity pages and triggers the Incident Response process.
Engineering Lead: owns the engineering response to confirmed detections that require code or configuration changes.
All personnel: report suspected security events to security@bioscopefoundry.com immediately.

12. Review & revision

This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale, including changes to the detection-tool inventory, the AWS control surface, or the threat-intelligence feed list. Material revisions are approved by the Security Officer in coordination with the Policy Management process.

13. Related policies

Vulnerability Management Configuration & Change Management