Senior Security Engineer

Queue builds robots to fill prescriptions. Our machine is designed to take stock bottles of medication and produce counted, labeled vials, so that pharmacists and technicians can spend their time on patients. Our first product is built to work behind the pharmacy counter and to be operated by pharmacy staff.

Queue builds robots to fill prescriptions. Our machine is designed to take stock bottles of medication and produce counted, labeled vials, so that pharmacists and technicians can spend their time on patients. Our first product is built to work behind the pharmacy counter and to be operated by pharmacy staff.

You own security engineering for a pharmacy robot and everything it talks to: the machine, its operating-system image, the software that runs on it, the cloud service that commands it, and the path that updates it. When a customer asks how each machine proves its identity, who can reach it and how, and what an independent test found and what was done about it, the answer rests on your work, and every statement in it is backed by something the system produces.

• The threat model — A written model of the trust boundaries: machine to cloud, operator to screen, the update path, remote support, and suppliers. You keep it current as designs change.
• Security review of designs — Designs come to you early; you review them and your review is recorded.
• Device identity and key custody — The threat model, the priorities and the verification are yours. The engineers who own the operating-system image build the platform side with you.
• Independent security testing — Scope, test environment, triage, remediation with the owning squads, and retest evidence. You run it end to end.
• Finding and fixing weaknesses — How weaknesses in our code, dependencies, device images and cloud are found, triaged and fixed. It is shared with the squads that own each part: you set the rules, track each finding to closure and report where we stand.
• Incident response — The security side of every incident: detection, triage, containment, evidence and what changes afterwards. It is shared with the owning squads, and you run it with the systems reliability engineers, who run the operational response.
• Customer security reviews — A customer's security review asks detailed questions and treats our answers as commitments. Before a statement is sent, you check it against the evidence that can substantiate it: the versioned implementation, the deployed configuration and the operational records. A statement says what is built, what is designed and what is planned, and keeps the three apart.
• Cloud posture — Identity and access, secrets, the review of infrastructure changes, and what the cloud provider's detection services report.
• Security and privacy controls — For the controls Queue commits to, including those that follow from HIPAA, you verify each control in the system and take its evidence from the system.

• Day 30:
  You have traced the trust boundaries yourself, and you hold the threat model and the record of independent testing. You have reviewed your first design.
• Day 60:
  You hold the priorities and the verification for device identity and key custody, with the engineers who own the operating-system image. You hold the inventory of secrets and keys and their rotation schedule. Every security statement that goes to a customer passes your check first.
• Day 90:
  You have written the scope for the next independent test and prepared the environment it will run against. Every design that came to you has a recorded review. You can hand an assessor a control's evidence as output from the system.

• Ownership — you have owned the security of a shipped product end to…