The D&T InfoSec team are using Qualys for automated vulnerability scanning of EC2 instances, and they want us to install the Qualys "Cloud Agent" on our EC2 instances to assist with this process.
If we agree to do this (and I think there is a discussion to be had of the technical/political merits of this change, but I'm not having it), it'll involve a non-trivial amount of engineering – we have a bunch of different EC2 instances used for different things.
I've got agreement to punt it until the new Lead Engineer/PMs arrive; here are some notes I wrote for the Project Manager in D&T:
As discussed, the Platform’s team work is now fully planned for 2022–3 Q4, and any later work will need to be scheduled and coordinated with the new Technical Product Manager and the new Lead Engineer (when they’re both hired). We don’t have the capacity to look at this before October.
I’ll leave some notes for my successor.
Here’s a brief rundown of the EC2 instances in the Wellcome Collection AWS accounts:
== Anything named “goobi” or similar ==
Anything related to Goobi is part of the Goobi workflow tool used by the Digital Production team. This is used to manage the ingest of digitised material in Wellcome Collection.
Goobi is managed for us by a third-party contractor called Intranda, and we’d need to coordinate any changes to those instances with Intranda and the Digital Production team.
Note that we don’t install any software on these instances directly, and we only apply minimal configuration – they start from a standard Amazon Machine Image (AMI) that allows them to act as container hosts for Docker containers orchestrated by Amazon Elastic Container Service (ECS).
This is a very standard pattern in AWS, and we trust Amazon to secure the instances for us.
Note also that these instances are autoscaling – they stop/start based on demand, and frequently scale down to zero. Over the course of a day we may have a dozen or more distinct instances acting as container hosts, which may have implications for Qualys licensing.
== Anything named “archivematica” or similar ==
Anything related to Archivematica is part of the Archivematica workflow tool used by the Collections & Research team. This is used to manage the ingest of born-digital material in Wellcome Collection.
These use a similar pattern to the Goobi hosts – instances that are almost entirely managed by AWS, and act as ECS hosts for Docker containers. They also use autoscaling, and the instances may be replaced regularly.
The Platform team does manage these instances, so we could pick up this work, but it would need to be scheduled and coordinated with C&R.
== Anything in the “digirati/dlcs” account ==
Anything in this account is part of the services used to serve digitised images on [wellcomecollection.org](http://wellcomecollection.org/) .
These are managed for us by a third-party contractor called Digirati, and we’d need to coordinate any changes to those instances with them. We’d also need to schedule the work to avoid downtime for the Digital Production team and the public-facing website.
I’m less clear on the exact use of these instances, but I believe they’re also acting as ECS hosts for Docker containers, and largely secured by AWS. I don’t know how often those instances are replaced.
kenoir
commented
4 months ago
The D&T InfoSec team are using Qualys for automated vulnerability scanning of EC2 instances, and they want us to install the Qualys "Cloud Agent" on our EC2 instances to assist with this process.
If we agree to do this (and I think there is a discussion to be had of the technical/political merits of this change, but I'm not having it), it'll involve a non-trivial amount of engineering – we have a bunch of different EC2 instances used for different things.
I've got agreement to punt it until the new Lead Engineer/PMs arrive; here are some notes I wrote for the Project Manager in D&T: