Helping Continental Stock Transfer keep its servers patched and audit-ready
Continental Stock Transfer needed its AWS servers brought up to a security baseline and kept there. We built an automated loop that finds vulnerabilities and patches them on its own, with our cloud operations team reviewing what changed.
from a stronger audit trail and automated vulnerability remediation
Continental Stock Transfer & Trust Company
A business that runs on trust, and has to prove it
Continental Stock Transfer & Trust Company is one of the largest stock transfer agents in North America, handling more than 1,100 public and private issues and the records of over two million shareholders. The business runs on trust, and in their industry that means the systems behind it have to be secure and demonstrably so. Continental was already running on AWS under our managed cloud operations, with their environments under our ongoing support, when they set a specific goal: harden their application servers to meet the Center for Internet Security (CIS) baseline.
Meeting a baseline is easy; staying on it is the work
Bringing servers up to a hardening baseline once is not the hard part. The hard part is staying there. Servers drift as packages age and new vulnerabilities get published, and a transfer agent carries the added weight of regular audits, where you have to show not only that a system is secure today but that every change to it has been tracked and controlled over time. Continental wanted both: their servers brought up to the CIS baseline, and a way to keep them there that did not depend on someone remembering to log in and run updates by hand.
What we actually did
We split the work into two phases, an assessment first and then the automation built on top of it.
In the first phase we used Amazon Inspector to scan Continental’s application servers against the CIS baseline and find where they fell short. That gave us a concrete list of hardening improvements specific to their Amazon Linux servers rather than a generic checklist to work from.
In the second phase we scripted the remediation for those findings, applied it across all of Continental’s application servers, and then built a loop to keep them in that state:
- Amazon Inspector runs on a schedule, reassessing the servers continually instead of checking once and stopping.
- Each run’s findings publish to an Amazon SNS topic, which triggers an AWS Lambda function with the findings attached.
- The Lambda evaluates each finding, and when it sees a published CVE on a server, it calls AWS Systems Manager to run the security update on that server with no one logging in.
- The results go to our Cloud Operations team, so a person still reviews what was found and what changed.
Because this ran inside our managed cloud operations, the loop became part of how Continental’s environment is maintained day to day, not a one-time project that ended when we moved on.
What changed
The immediate effect was that known vulnerabilities started getting patched on their own, with our Cloud Operations team reviewing the activity rather than doing the manual work of finding and fixing each one. The effect that mattered more over time was on audits. Every system-level change now leaves a record, so when an auditor asks what changed and when, the answer is already written down. The result was a stronger audit trail and shorter audit cycles, with faster remediation on the occasions when something does turn up.
This was not a fix-it-once engagement, and we would not describe it as one. Keeping a fleet of servers at a security baseline is ongoing work by nature, which is why the automation matters more than any single round of patching. Continental still runs it as part of their managed operations with us, which is the outcome we were after: not a project that ended, but a system that keeps doing the work.
Stack
Amazon Inspector · AWS Lambda · Amazon SNS · AWS Systems Manager · Amazon Linux · Managed Cloud Operations