Personnel Security
Program: Security Foundations, Governance and Risk Module: Personnel and Third-Party Security Submodule: Personnel Security
"Humans are your weakest link" is the industry cliché. A more useful framing: humans are the most creative asset in the organization, and their creativity flows in both directions — finding faster ways to get work done, and finding faster ways to subvert security controls in the process. Personnel security is the discipline that keeps that creativity flowing productively without inviting insider threats to fester.
This submodule walks through the full employment life-cycle — job definition, hiring, ongoing employment, termination — and layers on the insider-threat controls described in CA/Broadcom's 2015 white paper "I Have to Trust Someone… Don't I?", which remains a widely cited reference frame.
1. Why Personnel Controls Matter
Security teams can implement every technical and physical control in the catalog, but humans will find ways to disable, bypass, or circumvent them if the controls make the job noticeably harder. That is not always malicious:
- A team told to exchange files through three approved workflows will start emailing the files to each other instead.
- A web administrator will use the corporate website as an ad-hoc file-drop for external parties.
- A user tired of typing a 30-character password will Post-It it to the monitor.
Personnel security therefore aims for reduction of misuse, theft, and fraud — not elimination, which is impossible. It operates in three layers:
- Requirements — policy defining who may access what and how.
- Technical enforcement — technical controls (AD groups, RBAC, MDM) that reflect those requirements.
- Physical enforcement — badges, cages, cameras, escorts.
2. The Employment Life-Cycle
Each stage has personnel-security controls attached; the following sections walk them in order.
3. Before Hiring — Job Definition and Screening
3.1 Clear, security-aware job descriptions
Frameworks like SOC 2 and ISO/IEC 27001 require documented, up-to-date job descriptions. From a security perspective, a good job description states:
- Which systems and data the role will access.
- Reporting line and formal escalation path.
- Sensitivity level of the work (e.g., handles PHI, PCI-DSS cardholder data, ITAR-restricted material).
- Whether the role requires security clearance (government work), licensure, or certifications.
- What separation-of-duty peers exist (see §5).
Poor job definitions are the root cause of over-privileged accounts: you cannot grant least privilege if no one has defined what "least" means for this role.
3.2 Screening
Common pre-hire checks:
- Character references — informal sense of the candidate.
- Background check — verify education, previous employment, criminal history (subject to jurisdictional law).
- Identity check — right to work; identity documents.
- Security clearance — government or defense contracts often require an active clearance (e.g., US Secret / TS / TS-SCI, UK SC/DV, EU equivalents).
- Credit check — for financial or highly-privileged positions (again, jurisdiction-dependent).
Screening is a legal and privacy minefield; work with HR and legal counsel to keep it defensible.
4. Onboarding — Agreements and Access
Once the candidate is hired, several employment agreements create contractual security obligations:
| Agreement | Purpose | Enforceability notes |
|---|---|---|
| Non-Disclosure Agreement (NDA) | Protects sensitive information — IP, credentials, unreleased plans | Widely enforceable |
| Non-Compete Agreement | Restricts future employment at competitors | Often unenforceable (courts recognize the right to work); useful mostly as a deterrent |
| Employee Handbook | Codifies policies: data classification, ethics, contact list | Basis for later disciplinary action |
| Acceptable Use Policy (AUP) | What may / may not be done with corporate IT | Must exist and be reviewed annually; the CA/Broadcom paper flags "no comprehensive written AUP" as a top insider-risk factor |
| BYOD policy | Rules for personal devices touching corporate data | Ties into MDM enrollment |
| Code-sharing policy | Whether developers may post code snippets to forums (Stack Overflow, GitHub Gists) | Especially important where snippets could leak IP or credentials |
Initial access provisioning should follow least privilege, be tied to the documented role, and be granted through the same identity governance system that later reviews and revokes it (see §8).
5. Separation of Duties and Least Privilege
Two of the most-quoted principles in security, easy to state and hard to enforce.
Separation of Duties (SoD) — no single person can complete a sensitive workflow end-to-end. One requests, another approves; one codes, another deploys; one initiates a payment, another releases it. SoD makes a single insider attack require collusion to succeed.
Least Privilege — every identity has the minimum privileges necessary to perform its role, and no more.
5.1 Worked example — a small ops team
| Task | Primary | Backup |
|---|---|---|
| Physical security | Engineer A | Engineer F |
| User access control | Engineer B | Engineer H |
| Web server administration | Engineer C | Engineer E |
| Database administration | Engineer D | Engineer E |
| Network security controls | Engineer F | Engineer G |
Observations from the table:
- Engineer A handles physical security but has no access to user account control — an admin taking someone's badge cannot also grant them a shell.
- Every task has a primary and a backup so vacations, sickness, or resignations do not stop the business.
- Engineers D and E can administer databases but need Engineer C for anything on the web tier — combining a data theft with covering tracks requires collusion.
5.2 Non-obvious over-privileged roles
A lesson repeatedly surfaced by both academic research and penetration tests: the most over-privileged users in an organization are often not the ones you first think of:
- Cleaning and building-maintenance staff — badge access to every office, network closet, and server room. Physical access trumps most logical controls.
- Executive assistants — mailbox access to the C-suite.
- Third-party support engineers — support tunnels into production databases that outlast the actual support ticket.
Treat privileges as a renewable license, not a permanent grant.
6. Ongoing Employment — Access Reviews and Compliance
6.1 Periodic access audits
Access should be reviewed regularly — quarterly for high-privilege roles, at least annually for the general population. Every review answers three questions:
- Does this account still need to exist?
- Do the entitlements still match the role?
- Was the last recorded access consistent with the role?
Access logs should be actively monitored for events like:
- A low-privilege account attempting to open a database it has no business touching (e.g. a front-desk user opening a credit-card table).
- Terminated employees whose accounts still show login attempts (a red flag for both cleanup failure and possible impersonation).
- Sudden location or time-of-day anomalies (see §9 on advanced authentication).
6.2 Role changes — the entitlement-creep problem
The most-cited failure mode: users keep permissions as they move up the ladder. A CTO who came up through the identity team may still hold access to the IAM system; a VP of HR promoted from Risk Management may still see the enterprise risk register. This "entitlement accumulation" is the number-one insider-threat risk factor named in the Broadcom paper.
The fix is role-based provisioning tied to a governance process that removes old rights when new rights are granted, not in addition.
6.3 Compliance and privacy
Compliance and privacy are everyone's responsibility. The handbook must state:
- The compliance obligations that apply (HIPAA, GDPR, PCI DSS, SOX, ...).
- How compliance is audited (evidence retention, sampling frequency).
- The balance between security monitoring and employee privacy — is browsing history on a work laptop considered PII? Content filters, DLP tools, and endpoint monitoring must be disclosed clearly in the AUP.
- The obligation to inform individuals if their privacy is violated (as required, for example, by GDPR breach-notification rules).
7. Termination — The Highest-Risk Event
Termination is emotionally charged and procedurally dense. Get it wrong and one of two failure modes appears: continued access after departure, or a departing employee taking assets and data with them.
A working checklist:
- Formal termination procedure documented, rehearsed, and reviewed with HR and legal.
- Access revocation timing — synchronized with the exit conversation, ideally to the minute. Who owns removal? Who confirms it? What is the SLA?
- Device inventory returned — laptop, phone, badge, MFA fob, hardware key, VPN token. Track everything issued, not just laptops.
- Data extraction rules — is the departing employee allowed to copy personal files off their laptop before returning it? If so, what constitutes "personal"?
- Knowledge transfer — has a primary + backup existed for every task the employee owned? If not, this becomes an urgent problem. Cross-training long before termination avoids disruption and keeps the exit interview less awkward.
- Post-termination access audit — periodic review of former employees to confirm no access was missed.
Insider-threat research (cited in the Broadcom paper) finds that ~65% of employees who commit insider IP theft had already accepted a competing position at the time of the theft, and more than half steal data within a month of leaving. The termination period is the peak risk window.
8. Insider Threats — The Three Types and How to Address Them
The Broadcom/CA paper divides insiders into three archetypes; each requires slightly different controls.
| Type | Description | Frequency vs. impact |
|---|---|---|
| Malicious insider | Deliberately steals information or causes damage. Includes privileged admins — the highest-impact case. | Least frequent, highest per-incident cost (Ponemon) |
| Exploited insider | Legitimate user tricked by an outsider (phishing, pretexting) into surrendering credentials or performing an action. | Common; the pathway of most external breaches after perimeter compromise |
| Careless insider | Presses the wrong key — deletes the wrong record, emails to the wrong recipient, plugs in the wrong drive. | Very common; often high aggregate cost |
CERT's classical definition of a malicious insider is worth memorizing:
A current or former employee, contractor, or other business partner who has or had authorized access to an organization's network, system, or data and intentionally exceeded or misused that access in a manner that negatively affected the confidentiality, integrity, or availability of the organization's information or information systems.
8.1 Insider risk factors
The paper lists a canonical set of organizational risk factors — useful as an audit checklist:
- Ineffective privileged-user management — shared
root/Administratorpasswords; no accountability for who did what. - Inappropriate role and entitlement assignment — overlapping roles, duplicated entitlements, missing de-provisioning, orphan accounts.
- Poor overall identity governance — no unified process across systems.
- Poor information classification and policy enforcement — organizations that don't know where their sensitive data lives.
- Inadequate auditing and analytics — logs exist but no one reviews them.
- Audit-log complexity — so much data that forensic investigations drown.
- Reactive-only response — no predictive analytics; every detection happens after the damage.
- No comprehensive written AUP — no baseline for what is acceptable use.
8.2 In-depth mitigations
Five families of controls address the three insider archetypes:
| Control family | What it does | Insider type addressed |
|---|---|---|
| Privileged Identity Management (PIM) — shared-account password vaults, fine-grained access controls after login, user-activity recording (video-like session recordings), UNIX auth bridging to AD | Removes shared-password anonymity; limits blast radius when a privileged account is compromised | Malicious + Exploited |
| Identity Governance — role management, entitlement certification, automated de-provisioning | Prevents entitlement accumulation and orphan accounts | All three |
| Data controls (DLP) — classify data; enforce at four states: at-access, in-use, in-motion, at-rest | Blocks USB exfiltration, unauthorized email, print, or upload | Malicious + Careless |
| Advanced (risk-based) authentication — context-aware scoring; step-up MFA when risk is high | Detects impossible-travel and other anomalous logins | Exploited |
| Virtualization security — manage hypervisor-layer admins (who can copy/delete VMs in seconds); virtualization-aware automation | Contains the "one admin, many VMs" blast radius | Malicious |
Note the shared logic: accountability + least privilege + data control. The paper's summary is quotable — "Trust does not mean giving employees unrestricted and unnecessary access to information."
8.3 Well-known incidents
Real cases the paper cites (still frequently referenced):
- Edward Snowden / NSA (2013) — contractor-level privileged access enabled bulk exfiltration of classified programs (Prism, Boundless Informant).
- Terry Childs / San Francisco (2008) — a disgruntled network administrator locked the city out of its own FiberWAN, containing police and payroll systems. Remediation cost over $1M.
- Hanjuan Jin / Motorola (2012) — nine-year software engineer caught at O'Hare boarding a Beijing flight with 1,000+ confidential documents and $30k cash, representing $10-15M in trade secrets.
All three fit the pattern: privileged access + trigger event (politics, grievance, upcoming departure) + missing accountability control.
9. Balancing Enablement and Control
Overly restrictive controls damage the ability to be responsive, innovative, and functional. The right controls, however, make it possible to share more, not less — data that would otherwise be locked to a handful of trusted individuals can be safely opened to a much wider audience because the controls enforce accountability at the boundary.
The cultural message is important: apply controls uniformly across the organization, so individuals perceive them as an organizational priority rather than a lack of trust in them personally.
10. Key Takeaways
- Personnel security aims to reduce, not eliminate, misuse through the full employment life-cycle: define, screen, onboard, operate, review, terminate.
- Separation of duties and least privilege are the twin principles; enforce both with role-based provisioning and primary+backup coverage.
- Termination is the peak-risk window — most insider IP theft happens within a month of departure. Have a documented, time-synchronized offboarding procedure.
- Three insider archetypes: malicious, exploited, careless. Each needs different controls but they overlap.
- Five insider mitigation families: PIM, Identity Governance, DLP, Risk-based Authentication, Virtualization Security — all built on accountability + least privilege + data control.
- The most-privileged and most-forgotten roles are often non-technical: cleaners, contractors, executive assistants, third-party support engineers.
11. Glossary
- Personnel security — the discipline of controlling security risk arising from people employed by or contracted to the organization.
- Separation of Duties (SoD) — no single person completes a sensitive workflow end-to-end.
- Least privilege — every identity has the minimum privileges necessary for its role.
- Insider threat — risk of compromise from a current or former employee, contractor, or business partner; three archetypes: malicious, exploited, careless.
- Privileged Identity Management (PIM) — controls specifically for shared / admin accounts: vaulting, fine-grained access, session recording.
- Identity Governance — the discipline of role management + entitlement certification + automated de-provisioning.
- Entitlement accumulation — the pattern where a user retains old permissions after each role change; a leading insider-risk factor.
- Acceptable Use Policy (AUP) — written baseline of what employees may do with corporate IT.
- Risk-based authentication — authentication whose difficulty varies based on contextual risk score (device, location, time).
12. What's Next
- 03 · Vendor Risk Management — extends the same trust-and-verify discipline to third parties.
- Cross-refs: Program 3 · A07 · Authentication Failures (MFA hierarchy, session hygiene, risk-based auth in depth); Program 3 · A01 · Broken Access Control (RBAC/ABAC and IAM patterns).