Northline Learning: a leaked key, a shared admin user, and a district questionnaire
Northline Learning is a 30-person SaaS company hosting student records for 14 school districts. Its contracts require encryption of student data at rest and in transit, and a record of every administrative action taken on that data. The platform runs on Amazon RDS for PostgreSQL and a small EC2 fleet. Last week a contractor pushed a file containing an IAM access key to a public GitHub repository. The key belonged to a shared IAM user that four engineers use for production work, and that user has AdministratorAccess attached. Nobody noticed for two days. Multi-factor authentication is optional, and only two of the four engineers have enabled it. The head of engineering wants to "turn on GuardDuty and be done". The districts have started sending security questionnaires, and one asks whether AWS or Northline is responsible for patching the database engine.
1. A district asks who patches the database engine and who is responsible for encryption. Answer precisely, distinguishing RDS from the EC2 fleet.
Read the worked answer
Split the answer by service model, because the boundary moves.
On RDS, AWS operates the undifferentiated heavy lifting: the physical hosts, the storage, the network, and the database engine and operating system patches, which AWS applies during a maintenance window that Northline chooses and can defer within limits. Northline still owns the data itself, the database users and credentials, the VPC subnets and security groups that decide who can reach the instance, whether encryption at rest is turned on at creation, and the KMS key policy that governs who can use the key.
On EC2, the boundary moves further toward Northline: AWS patches the hypervisor and the physical layer, but the guest operating system, the middleware and anything Northline installs are Northline's to patch and harden.
In both cases the encryption of data in transit is a configuration decision Northline makes, not something AWS enables for it. Getting this wording right in the questionnaire matters: overclaiming that "AWS handles security" is the kind of statement that fails an audit later.
2. The key has been public for two days. What are the first actions, in what order, and why that order?
Read the worked answer
Containment before investigation before hardening.
- Neutralise the credential: attach an explicit deny or deactivate the access key, then delete the shared IAM user. Every additional minute is unauthorised access potential.
- Preserve the evidence rather than destroying it: the CloudTrail event history for that key's access key ID, including source IPs, regions and API calls; do not delete logs or terminate instances before capturing state.
- Scope the damage from the trail: did the key create users, roles or access keys, modify bucket policies, or read the student data? That determines whether this is a notification event under the district contracts.
- Replace the shared identity with individual IAM users or federated roles, least privilege instead of AdministratorAccess, and enforce MFA through policy rather than asking politely.
- Notify internally (legal, leadership) on the contractual clock, and decide on external notification based on step 3.
GuardDuty is worth enabling, but it is a detection control that would have helped two days ago; it does not close an open door, and offering it as the whole answer signals that the team has mistaken a monitoring service for a remediation plan.
3. Design the minimum control set that satisfies the contractual requirements for encryption and administrative audit, and state what Northline still has to do itself.
Read the worked answer
Services: KMS with customer-managed keys for encryption at rest, TLS enforced for connections, CloudTrail recording management and data events into a dedicated, access-restricted S3 bucket with log file integrity validation, and CloudWatch alarms or an event-driven alert on sensitive API calls such as policy changes or key deletion.
Reasoning for each: a customer-managed key gives Northline its own key policy, rotation and the ability to revoke access independently of AWS; a CloudTrail bucket with restrictive permissions and object lock-style protection means an attacker with an access key cannot quietly erase their own tracks; alerts turn a record into a control, because a log nobody reads fails the "record of every administrative action" requirement in practice even if it passes on paper.
What Northline still owns: deciding which data is sensitive and classifying it; writing and reviewing key policies; setting retention that matches the districts' contracts; reviewing the trail and the alerts on a schedule with a named owner; and re-encrypting existing unencrypted RDS storage, which generally means snapshot, copy with encryption enabled, and restore rather than a toggle on the live instance.