Shaun Carrillo's Cybersecurity Portfolio

Scenario-based capstone. Gotham Legal Group is a fictional organization created for my WGU B.S. Cybersecurity & Information Assurance capstone. This is a design proposal and implementation plan, not a system I deployed.

I proposed replacing a 150-person law firm’s manual access process with Microsoft Entra ID (RBAC, MFA, Conditional Access, recurring access reviews) and CyberArk for six privileged IT accounts. The design targets the root cause of the firm’s breach: access that was never removed when people changed roles or cases

The Problem

The firm grew from 60 to 150 employees in two years without scaling how it managed access. IT still granted and changed permissions by hand, on request.

• Privilege creep: when employees changed roles or cases, old permissions were rarely removed.
• The breach: a paralegal’s credentials were phished. The attacker used them to open confidential files from a case the paralegal had left more than a year earlier.
• Standing admin rights: IT staff used always-on elevated permissions, with no central control or monitoring of privileged activity.

The phishing attack got the attacker in. Stale access is what let them reach sensitive files.

Proposed Solution

Two platforms, each covering a different layer of access, built on least privilege and Zero Trust.

The two layers have few dependencies on each other, so the plan configures them in parallel.

RBAC role and security group matrix

Access follows the role and the current case assignment, never the individual. This matrix is the baseline for provisioning and for every access review.

Role	Microsoft 365	General shared files	Case files	HR resources	Admin access
Attorney	Allowed	Allowed	Assigned cases only	None	None
Paralegal	Allowed	Allowed	Assigned cases only	None	None
Admin Staff	Allowed	Allowed	Limited	None	None
Mgmt	Allowed	Allowed	As required	Limited	None
IT Support	Allowed	Allowed	None	None	Limited
IT Admin	Allowed	Allowed	None	None	Privilege

“Assigned cases only” is the control that would have stopped the breach. Under this model, the paralegal’s access to the old case would have ended when they were reassigned.

Authentication and access reviews

Three Entra ID controls close the two gaps the breach exposed: a stolen password was enough to get in, and nobody checked whether old access was still needed.

• MFA for all employees. A stolen password alone no longer grants access. Following CISA guidance, MFA is prioritized for users handling confidential case data and for privileged accounts, with phishing-resistant methods such as authenticator apps and security keys.
• Conditional Access. Sign-in requirements are evaluated on user, device, location, and sign-in risk. Following Microsoft’s deployment guidance, policies are tested on a pilot group before they’re enforced for everyone.
• Recurring access reviews. Group memberships are reviewed on a schedule against the RBAC matrix, and also whenever an employee changes roles or cases. Unneeded access is removed within 5 business days.

Emergency (break-glass), service, and system accounts are excluded from these policies and documented separately, so a misconfigured policy can’t lock out the whole tenant.

Privileged access design

Six IT roles get a separate privileged account managed through CyberArk. Standing admin rights on everyday accounts go away.

Role	Count	Account model
IT Manager	1	Standard account + separate CyberArk-managed admin account
Identity Administrator	1	Standard account + separate CyberArk-managed admin account
Security Administrator	1	Standard account + separate CyberArk-managed admin account
System Administrator	2	Standard account + separate CyberArk-managed admin account
Senior IT Support Administrator	1	Standard account + separate CyberArk-managed admin account

Daily work (email, browsing) happens on standard accounts. Elevated tasks happen only through the controlled, monitored admin accounts. If an admin is phished, the attacker gets a standard account, not domain-level rights.

Joiner, Mover, Leaver procedures

Every lifecycle event changes group membership, not individual permissions. That keeps access matched to the RBAC matrix.

Event	Trigger	Access action
Joiner	New hire	Assign role security groups from the matrix; enroll in MFA before first access
Mover (role change)	Promotion or transfer	Swap old role groups for new ones; remove access the new role doesn’t need
Mover (case change)	Case reassignment	Remove the old case group; add the new one. This is the step that was missing before the breach
Leaver	Termination	Disable the account; remove all groups; revoke privileged access in CyberArk if applicable

Rollout plan

The plan uses a waterfall methodology with nine phases. Requirements were clear, and each phase depends on the one before it: you can’t clean up permissions until the RBAC baseline exists.

1. Current-state assessment: inventory accounts, groups, permissions, and admin accounts across all 150 users.
2. RBAC and policy design: build the role matrix, MFA and Conditional Access requirements, and JML procedures.
3. Entra ID configuration: create the role groups, MFA, Conditional Access, and access reviews.
4. CyberArk configuration: onboard the six privileged accounts. This runs in parallel with phase 3.
5. Pilot: 10–15 users from attorney, paralegal, admin, and IT teams test access, denial of out-of-scope files, and MFA.
6. Full permission review: remove stale group memberships and case access before migration.
7. Training: brief users before each group’s cutover; give the six admins separate CyberArk training.
8. Phased rollout: Attorneys → Paralegals → Admin/Operations → Management → IT, with major changes during low-usage hours.
9. Validation and handoff: test that users can reach what they need and are denied what they don’t, then move to recurring reviews.

Success criteria:

• 100% of active accounts covered by MFA and Conditional Access within 30 days, with documented exceptions.
• 100% of access assignments reviewed, with unneeded access removed within 5 business days.
• All six privileged accounts onboarded to CyberArk and monitored.

Scope creep, as written into the scenario: the assessment surfaced undocumented security groups and privileged accounts. They were folded into the existing permission review instead of being spun off as a separate project, which added about three business days to the plan.

What I’d do differently

Looking back, here’s where I’d go deeper and how I’d test it hands-on.

• Specify the PAM mechanics. The proposal sets the account model but not CyberArk’s moving parts. Next time I’d design credential vaulting, automatic password rotation, and session recording for each of the six accounts.
• Compare against Entra PIM. For a 150-person firm, Microsoft Entra Privileged Identity Management (just-in-time role activation) may cover most of the need at lower cost than CyberArk. That trade-off deserves its own analysis.
• Automate the Mover step. Case reassignment is the step that failed. Driving case-group changes from the case management system, rather than from manual tickets, would remove the human gap.
• Prove it in a lab. With an Entra ID P2 trial, I’d build the role groups, run the Conditional Access policies in report-only mode first, and set up a recurring access review to validate the design end to end.

Sources

• Microsoft: Plan a Conditional Access deployment
• Microsoft: Plan a Microsoft Entra access reviews deployment
• CISA: Require multifactor authentication
• Atlassian: Waterfall methodology for project management