The Partners Who Say They Are Too Small to Be a Target
A 60-person accounting firm has three partners who are also the entire IT decision committee. Findings from a recent internal review: (1) all 60 staff are local administrators on their laptops because installing printers 'takes too long'; (2) eight billing staff share one 'Finance' login to the billing application, and the vendor quotes $4,200 plus three weeks to convert to named users; (3) the office manager keeps a spreadsheet of all passwords, including the domain administrator account, on a share readable by Everyone; (4) no one has reviewed file share permissions since 2019, so the 'Public' share contains payroll exports. The partners' position is that the firm is too small to be a target and that fixing items 1 through 3 will cost more in lost productivity than an incident would.
1. Rank the four findings by the risk they create for this firm and justify the ordering using least privilege, separation of duties, and accountability. Address whether 'we are too small to be a target' is a valid argument.
Read the worked answer
Rank on blast radius and detectability, not on how untidy a finding looks.
- #3, password spreadsheet including domain admin. One readable share yields total domain control with no attribution and no second factor. Every other finding becomes worse once this exists, so it is first by a wide margin.
- #2, shared Finance login. In a billing system this is a segregation-of-duties and repudiation failure: a fraudulent invoice cannot be traced to a person. High likelihood of internal misuse, moderate external exposure.
- #1, local admin everywhere. Enables persistence and credential theft after any single phish, but requires an initial compromise first.
- #4, payroll exports on Public. Serious confidentiality issue with regulatory weight if payroll data is personal data; a defensible case exists for ranking it second on that basis. State your criterion openly.
On 'too small to be a target': size is irrelevant to opportunistic attacks, which are automated and commodity. What size changes is the impact tolerance - a firm with no detection capability and no tested backups absorbs damage for weeks. Reframe the argument from likelihood to recovery capability, which is the actual exposure.
2. The partners approve fixing item 2 but defer the $4,200 until next quarter. What compensating controls reduce shared-account risk in the meantime, and what residual risk must be formally accepted?
Read the worked answer
Compensating controls, in order of value:
- Keep individual identity for the session. Staff log on to Windows with their own domain account, then launch the billing app through a wrapper that supplies the shared credential. You now have host-level attribution even though the app has none.
- Constrain where the shared credential can be used: a single VDI/RDP host, source-IP restricted, with session recording and time-of-day limits.
- Break-glass handling of the password itself: checked out from a password vault, rotated on a schedule, never written in a document or email.
- Alert on anomalies: concurrent sessions from two people, logins outside business hours, or bulk invoice edits.
- No browsing or email on that host, so the credential is not exposed to commodity malware.
Residual risk that must be accepted in writing by a partner, with a review date: during any fraud investigation you cannot prove which of eight people performed a transaction; the credential is shared with whoever is in the room; and rotation is manual. That accountability gap is the whole reason for the $4,200, and it should be stated that way on the acceptance form.
3. For item 1, propose a path to remove local administrator rights without the ticket-volume spike the partners fear, and name two metrics that prove it worked.
Read the worked answer
Sequence matters more than the tool:
- Measure first. Instrument how many elevation events actually occur per user per month. The fear is usually larger than the data.
- Publish a self-service path for the top drivers - printer drivers, approved line-of-business installers, and a handful of legacy tools - before removing rights, not after.
- Use just-in-time elevation on a pilot group of ten users: a request with a business justification, auto-approved for a defined catalogue, time-limited, logged. Nothing about the workflow should require a phone call to IT.
- Rotate local admin passwords to per-machine unique values (LAPS or equivalent) so the shared local admin password cannot be reused laterally.
- Pilot, publish the ticket count, then expand in cohorts, keeping a documented exception list with expiry dates.
Metrics to report to the partners:
- Standing local administrators per endpoint, target zero except documented exceptions.
- Elevation requests per user per month, which should fall as the catalogue matures - this is the productivity answer.
Track helpdesk tickets tagged 'install' alongside them so a rise in one number is not mistaken for failure when it is actually the new normal.