Experience
Experience
Day-to-day security operations in the university's Network Security Operations Center, LLM red-team research in the Machine Psychology Group, and the retail systems job that came first.
Jun 2026 to present
Junior Security Analyst, NSOC
Network Security Operations Center, University of Massachusetts Boston. I monitor, investigate, and remediate security events across campus systems using SIEM, vulnerability management, and endpoint tooling.
What you won't find here: incident details, internal tool names, or anything about the university's environment. Tools are described by category, and I'm glad to go into specifics in an interview.
Security monitoring
Work the alert queue in a cloud-native SIEM and decide what needs a closer look.
Detection and response
Remediate endpoint threats with an enterprise EDR platform, including pre-deployment readiness checks.
Incident investigation
Supervisor-facing written findings mapped to MITRE ATT&CK, with IOCs checked against threat intelligence.
Email security
Reported phishing and smishing: header analysis, URL reputation, and DMARC/SPF review across the mail chain.
Vulnerability management
Agent-based scanning across 185+ endpoints, asset tagging, and prioritized remediation proposals.
Network and identity
VLAN configuration during a campus switch migration; AAA, SSO, Kerberos, and SAML fundamentals from NSOC training.
Case walkthroughs
How I work an alert
Three kinds of case from the queue, replayed one stage at a time. Every value is invented: the domains, addresses, hostnames, and counts don't exist anywhere.
-
Signal
A user reports a suspicious message
A staff member uses the report button on an email asking them to review a shared document. Reports like this are the cheapest detection there is, so each one gets a real look.
- source
- user report
- subject
- Shared file: Q3 budget review
- sender
- accounts@billing-notice.example
- queue
- email security
-
Triage
Read the headers before the body
The display name imitates an internal department, but the sending domain doesn't belong to the university and the Reply-To points somewhere else again. Authentication results settle it.
Decision Not a false report. Treat as phishing and keep going.
- spf
- fail
- dkim
- none
- dmarc
- fail
- reply-to
- mismatch with sender
-
Enrich
Find out what the link does
The URL is checked against threat intelligence, then opened in a sandbox rather than on a workstation. A recently registered domain serving a copy of a sign-in page is credential phishing, not spam.
Decision Credential harvesting confirmed. Scope it.
- url
- hxxps://docs-share[.]example/view
- domain age
- 4 days
- reputation
- flagged
- sandbox
- fake sign-in page
-
Scope
Find everyone else who got it
One report rarely means one recipient. A message trace shows who else received it and who clicked, and sign-in activity for those accounts gets reviewed next.
Decision Two accounts need follow-up. The rest need the message removed.
- recipients
- 14
- clicked
- 2
- credentials entered
- 1 suspected
- related cases
- unusual sign-in
-
Respond
Contain it, inside the runbook
The message is removed from mailboxes, the sender and URL are blocked, and affected accounts get a password reset with sessions revoked. Anything outside my permissions goes to a senior analyst with the evidence attached.
- message
- removed
- sender and url
- blocked
- accounts
- reset, sessions revoked
- escalation
- senior analyst
-
Record
Write it up so the next analyst can use it
Findings go into the ticket mapped to MITRE ATT&CK, with indicators listed so they can be searched later. If the same lure shows up again, the second case starts from this one.
- technique
- T1566.002 Spearphishing Link
- indicators
- 1 domain, 1 url, 1 sender
- ticket
- closed with findings
-
Signal
Two sign-ins that can't both be the same person
The SIEM raises an alert: one account signs in from Boston, then from another continent forty minutes later.
- account
- jdoe (synthetic)
- sign-in 1
- 198.51.100.24, Boston
- sign-in 2
- 203.0.113.77, overseas
- gap
- 40 minutes
-
Triage
Rule out the boring explanations first
Most of these are a VPN, a phone on a carrier network, or real travel. Device, client, and MFA details usually say which. Here the second sign-in is an unregistered device, and the MFA prompt was approved anyway.
Decision No benign explanation fits. Investigate as a compromised account.
- device
- unregistered
- client
- new browser profile
- mfa
- push approved
- vpn match
- no
-
Enrich
Look at where it came from
The second address belongs to a hosting provider the account has never used. Recent history adds context: the same user reported a phishing email two days earlier.
Decision Likely credential theft from the phishing case. Link the two.
- ip owner
- hosting provider
- reputation
- flagged
- prior use
- none
- linked case
- reported phishing email
-
Scope
Find out what the session did
What matters is what happened after sign-in: new inbox rules, forwarding, changes to MFA methods, files opened. A rule that quietly moves replies out of the inbox is a common way to hide.
Decision Mailbox tampering found. Contain now.
- inbox rule
- created, hides replies
- forwarding
- none
- mfa methods
- unchanged
- mail sent
- 0
-
Respond
Cut off access and undo the changes
Sessions are revoked, credentials reset, the rule removed, and MFA re-registered with the user. Account actions I can't take myself are escalated with the timeline attached.
- sessions
- revoked
- password
- reset
- inbox rule
- removed
- mfa
- re-registered
-
Record
Close the loop with the phishing case
The write-up records both techniques and ties this case to the email that started it, so the full chain is in one place.
- technique
- T1078 Valid Accounts
- technique
- T1564.008 Email Hiding Rules
- ticket
- closed, linked
-
Signal
A scan flags a critical finding
The scanning agent on a workstation reports an outdated browser runtime with a critical vulnerability.
- asset
- WS-LAB-0142 (synthetic)
- finding
- outdated browser runtime
- severity
- critical, CVSS 9.8
- id
- CVE-0000-00000 (placeholder)
-
Triage
Confirm it's real
Scanners report stale data and duplicates. Installed version against fixed version, the agent's last check-in, and whether the asset still exists all get checked before anyone is asked to patch.
Decision True positive on a live machine.
- installed
- older than fixed version
- last check-in
- today
- duplicate asset
- no
-
Enrich
Decide how much it matters
Severity alone isn't priority. The NVD entry gives the attack vector, and a listing in a known-exploited catalog means attackers are already using it. What the machine can reach matters too.
Decision Exploited in the wild and network-reachable. Move it up the queue.
- vector
- network, no privileges
- known exploited
- yes
- exposure
- user workstation
-
Scope
Find every machine with the same problem
Asset tags by hostname and address range turn one finding into a list: every endpoint running the same software version.
- affected endpoints
- 23
- tag groups
- 2
- already patched
- 5
-
Respond
Propose a fix someone can act on
The remediation proposal orders the work by exploitability and exposure, names the owning team, and sets a date. It goes to them as a ticket rather than a spreadsheet.
- order
- exposed machines first
- owner
- desktop support
- ticket
- opened
-
Record
Rescan, then close
A finding is closed when a fresh scan says so, not when a patch is reported as installed. Before-and-after results go in the ticket.
- rescan
- clean
- evidence
- before and after attached
- ticket
- closed
All roles
Timeline
Most recent first.
-
Jun 2026
PresentJunior Security Analyst
Network Security Operations Center / University of Massachusetts Boston
- Incident investigation: triage and document incidents in a cloud-native SIEM, from initial alert review through supervisor-facing written findings mapped to MITRE ATT&CK.
- Email and phishing analysis: investigate reported phishing and smishing through header analysis, URL reputation checks against threat-intelligence platforms, and social-engineering indicator review; work the inbound mail chain including transport rules, ATP scanning, AI-based behavioral detection, and DMARC/SPF.
- Vulnerability management: run agent-based scanning across 185+ endpoints, asset-tag by hostname and IP, schedule scans, and write remediation proposals prioritized by severity and exploitability.
- Network infrastructure: configured VLANs on campus switches during a migration from legacy switches to new hardware; completed DDI (DNS, DHCP, IPAM) lab training.
- Endpoint security: remediate endpoint threats with an enterprise EDR platform, including pre-deployment readiness checks that confirm provisioning software and agent enrollment before machines ship.
- Red team exercises: lead the red team side of an NSOC security tabletop exercise.
- Reporting: track findings in an ITSM ticketing platform and author incident reports in DHS format, with IOCs cross-referenced against threat intelligence.
- Writing: first author of “Anatomy of a Phishing Attack,” published through UMass Boston and drawn from NSOC casework.
-
Jul 2026
PresentUndergraduate LLM Security Researcher
Machine Psychology Group, Cyberpunk Division / University of Massachusetts Boston
Undergraduate Machine Psychology Fellow, advised by Daniel Haehn, PhD, Department of Computer Science. Adversarial security testing of large language models and embedded devices.
- BadToken HYDRA: building an automated red-teaming framework whose engine schedules garak, PyRIT, and a browser-based web module behind one shared evidence format.
- Red-team scanning: ran a ~20,000-prompt baseline across 20 garak probe families against a locally served model, then analyzed hit logs to separate real guardrail failures from compliance markers.
- Experiment design: leading a before-and-after weight-editing study testing whether resistance is refusal-mediated or capability-mediated, with encoding probes as a control and Z-scores against a 23-model calibration baseline.
- Research infrastructure: serve models with vLLM on A100 nodes under Slurm; maintain pinned CUDA/PyTorch environments and the group's cluster documentation.
- Hardware track: embedded device and wireless testing on an isolated, faculty-supervised bench.
- Writing: first-author manuscript in preparation.
-
Jun 2024
Aug 2026Service Supervisor
Cumberland Farms / Retail operations
Ran store operations day to day, with considerably more IT and systems work than the title suggests.
- Infrastructure: maintained the store's data cabinet (routers, switches, patch panels) so the network stayed up for POS, fuel systems, and back-office operations.
- Troubleshooting: resolved POS client-to-server polling failures and database sync errors, isolating hardware from network from software before escalating.
- Leadership: led shifts as key holder, onboarded staff on store systems, and handled escalations under pressure.