M.Eng in Cybersecurity from the University of Maryland (3.9 GPA), with hands-on experience supporting enterprise infrastructure for 120+ users on Cisco, Palo Alto, and Meraki equipment — plus a fully independent, real-hardware lab project built from the ground up. CCNA in progress.
Focus: Networks & Protocols, Network Security, Security Tools & Information Assurance, Penetration Testing
Focus: Cloud Security, Cloud Computing, Linux System Administration, Virtualization & Containerization
Certified
Certified
Certified
In progress
A multi-factor authentication security device, developed and published during network research work at Geethanjali College of Engineering.
Three flagship builds below, all on real hardware end to end. Additional applied work and what's next follow after.
A segmented enterprise network for a fictional healthcare organization — designed, built, and hardened end-to-end on real, physical Fortinet and Cisco hardware. Full command reference and troubleshooting log in the GitHub repo.
Every device, model number, and technology actually used in the build — not a simulated topology.
| Device | Model | Role |
|---|---|---|
| Firewall / Core Router | FortiGate 60E (FortiOS 7.4.11) | Perimeter firewall, inter-VLAN policy, SSL-VPN, RIP |
| Core Switch | Cisco Catalyst 3560E-24PD-S (PoE) | VLAN trunking, 4-zone segmentation |
| Branch Router | Cisco 1921 ISR (IOS 15.x) | Site-to-site routing, Branch LAN gateway |
| HQ Access Point | Cisco AIR-CAP3702I-A-K9 (Autonomous) | Dual-SSID wireless — Trusted / Guest |
| Spare AP | Cisco AIR-LAP1142N-A-K9 | Backup / spare unit |
| Branch AP (attempted) | Cisco AIR-CAP3502I-A-K9 | Diagnosed as Lightweight/CAPWAP firmware, unrecoverable secondhand credentials — documented, substituted |
| Branch WiFi (deployed) | TP-Link Archer AX21 | Practical substitute for the Branch AP, per above |
| Homelab Host | Lenovo T14 | Runs Proxmox VE — all monitoring & automation containers |
| Layer | Technology |
|---|---|
| Virtualization | Proxmox VE, Debian 12 LXC containers |
| Metrics collection | Prometheus v2.53.0 |
| Dashboards | Grafana |
| SNMP polling | SNMP Exporter v0.26.0, SNMPv2c |
| Host metrics | Node Exporter v1.8.2 |
| Public site delivery | Cloudflare Tunnel (cloudflared), nginx |
| Dynamic DNS | DuckDNS |
| Remote access | FortiGate SSL-VPN, FortiClient |
| Automation | Bash, cron, SSH (Ed25519 / RSA-2048) |
| Routing protocol | RIPv2 |
The internal MSP division of Cherwood Corporation — building and operating the automation that manages, backs up, and secures every other Cherwood property, starting with Cherwood Health. Now extended into the ITSM process layer with a real ServiceNow integration. Full writeup, code, and the real troubleshooting story in the GitHub repo.
An unattended nightly system that backs up, version-controls, drift-checks, and maps the topology of three production devices — zero manual steps, built the way a real MSP scopes access into a client's environment. Real config drift now also opens a ServiceNow Incident automatically, with severity mapped from the diff content, and the same pipeline was verified against a full ServiceNow Change Request lifecycle — the process half of network operations, not just detection.
| Device | Role |
|---|---|
FortiGate 60E | Perimeter firewall — config pulled and normalized nightly |
Cisco Catalyst 3560E | Core switch — config pulled nightly |
Cisco 1921 ISR | Branch router — config pulled nightly |
| Bug | Root cause |
|---|---|
| Netmiko/Cisco IOS SSH failure | Legacy IOS SSH servers don't follow RFC 4252's public-key handshake correctly — traced via debug-level Paramiko logs and a decade of open GitHub issues, fixed with a targeted compatibility patch rather than a workaround |
| False drift alerts, every run | FortiGate re-encrypts password/key fields with a random salt on every pull — fixed with a normalization pass applied only to the drift-comparison copy |
| Site silently served the wrong content | Reverse proxy connected over IPv6 loopback (::1) while the new nginx site only listened on IPv4 — traced by systematically ruling out DNS, Cloudflare cache, and tunnel config before finding the missing listen [::]:80; line |
| Same physical link counted as two edges | Cisco and FortiGate each reported the other's hostname differently (short name vs. full FQDN) — fixed by normalizing every reported name against the canonical device inventory before deduplicating |
| A form field that silently refused to change | ServiceNow's Normal Change model gates state transitions behind a real approval workflow and a required Assignment Group field, neither obvious from the form — fixed by working through genuine CAB-style approver records instead of fighting the state field |
A real two-switch HSRP failover pair, proven against an actual power-pull rather than a config toggle — closing the one gap none of the other divisions cover: redundancy under real failure. Full writeup, code, and the real troubleshooting story in the GitHub repo.
Two physical Cisco 3560E switches share one virtual gateway IP on a dedicated VLAN, with explicit priorities, tuned timers, and Spanning Tree deliberately aligned to the same switch HSRP favors. Proven by actually cutting power on the active switch mid-ping and measuring what happened.
| Component | Role |
|---|---|
Cherwood-3560E | Primary — priority 150, HSRP Active, STP root |
Financial-SW2 | Spare — priority 100, HSRP Standby, STP root secondary |
10.10.70.1 | Virtual IP — the actual gateway clients point to |
| Bug | Root cause |
|---|---|
| New switch unreachable from the automation container | A firewall policy permitting management access was scoped to a single host object, not the subnet — the new device's IP was never covered, so the connection silently timed out at the firewall |
| Spare switch rejected key-based SSH setup entirely | Same vendor and switch family as the primary, but an older IOS train that never implemented key-based auth for interactive sessions — confirmed via ip ssh ? showing no such command exists |
| New link showed a nonsense port label on the topology map | A 22-character hostname overflowed a fixed-width CLI column, causing the parser to misread the Hold-time value as a port name — silently wrong data, no error raised |
A passive intrusion-detection lab on real hardware — a dedicated VLAN, a live Suricata sensor running a real 52,713-signature ruleset, and two independently verified detections: a malware-signature transfer and a live port scan, both surfaced through a lightweight custom dashboard. Full writeup, code, and the real troubleshooting story in the GitHub repo.
A dedicated VLAN carries traffic through Proxmox's own VLAN-aware sub-bridge, watched directly by a Suricata sensor running the full Emerging Threats Open ruleset plus two custom rules. Proven against two real tests: a real malware-signature file transfer and a live port scan — both fired, both correctly attributed, both surfaced in a lightweight triage dashboard instead of raw log files.
| Component | Role |
|---|---|
VLAN50_Legal | 10.10.50.0/24 — internet-only firewall policy, fully logged |
vmbr0v50 | Proxmox's VLAN-aware sub-bridge — the actual sensor capture point |
| Suricata 7.0.10 | systemd service, 52,713 rules loaded, 0 failed |
| Bug | Root cause |
|---|---|
| RSPAN mirror caught broadcast traffic, never a real conversation | The switch mirrored VLAN 50 back out the same trunk port already carrying that traffic live — a documented Cisco loop-prevention behavior that silently drops mirrored unicast frames |
| A completed EICAR download the sensor still couldn't see | Every convenient EICAR mirror, including the one labeled official, transparently redirects to HTTPS — a passive sensor cannot inspect encrypted payloads by design |
| 1,000-port scan completed with zero alerts fired | Emerging Threats Open ships no generic, low-threshold connection-rate rule tuned to a fast, small scan out of the box |
Active Directory, 802.1X wireless authentication, and RADIUS-backed SSL-VPN for a nonprofit client — replacing a shared Wi-Fi password and unmanaged local VPN accounts with one verified identity. Full writeup, code, and the real troubleshooting story in the GitHub repo.
A new Active Directory domain with AD-integrated DNS and a real OU structure, an Enterprise CA issuing the certificate 802.1X requires, and NPS acting as RADIUS between the directory and two entirely different client devices — a Cisco access point and a FortiGate firewall — each with its own policy. Proven end-to-end: valid and invalid logins tested on both Wi-Fi and VPN, with server-side log evidence for each, plus a domain-joined client and an enforced Group Policy.
| Component | Role |
|---|---|
foundation.cherwood.local | AD domain — DC at 10.10.60.20 |
FOUNDATION-CLIENT01 | Domain-joined client — 10.10.60.21 |
| NPS / RADIUS | Two independent Network Policies — one for Wi-Fi, one for VPN |
| Bug | Root cause |
|---|---|
| DNS role silently missing after promotion | AD DS promotion should auto-install DNS; it didn't, despite the AD-integrated zone data existing correctly — installed the role manually, verified via live queries |
| A correctly-scoped Wi-Fi policy silently rejected every VPN login | The Network Policy's "Wireless" condition meant NPS skipped it entirely for VPN's "Virtual" connection type, with no second policy to catch the fallthrough — fixed with an independent VPN-scoped policy |
| A failure with no log entry at all | Mismatched RADIUS shared secret between the firewall and NPS — fails completely silently by design, since the packet can't be authenticated well enough to log; confirmed via a direct RADIUS test bypassing the VPN portal |
Four real packet captures, each tied to a specific bug or design decision from Cherwood Health, HA/Failover, and Network Solutions — not a tutorial series, evidence that packets can actually be read, not just described. Full writeup, raw captures, and screenshots in the GitHub repo.
Every capture here rides on traffic already in motion elsewhere in the portfolio — no infrastructure was built just to generate it. Each entry pairs a real .pcap/.pcapng file with the troubleshooting story behind getting it, including the mistakes.
| Capture | What it proves |
|---|---|
| SSL-VPN TLS handshake | Cipher-hardening config confirmed live on the wire — plus an unsolicited internet scanner caught mid-handshake against the intentionally exposed portal |
| HSRP failover cutover | 3.33s measured from packet timestamps, replacing the original stopwatch estimate; full trail from wrong capture point → SVI-down root cause → fix |
| LLDP discovery frames | Raw TLVs matched against what topology.py actually parses, plus a verified explanation for why FortiGate's LLDP never crossed a SPAN capture |
| Blocked DMZ→Trusted recon | Segmentation enforcement proven at the packet level — request in, no reply, ever |
| Bug | Root cause |
|---|---|
| HSRP capture showed total silence during the outage | The standby switch's only VLAN 70 member port was the trunk to the primary — when that link died, its SVI went down with it, and HSRP cannot transmit in any state while its interface is down |
| FortiGate's LLDP frame never appeared in a switch-side SPAN capture | Confirmed transmitting reliably via the FortiGate's own native sniffer; the likely cause is the switch's control plane consuming the shared LLDP/STP destination MAC rather than flooding it through SPAN |
| An unsolicited public IP completed a full TLS handshake against the lab VPN | Traced through FortiGate policy and VIPs (both clean) to a real, intentional port-forward rule on the home router — confirmed as designed, not a leak |
A passive 802.11 site survey of the Plainsboro Public Library — a three-storey, 46,500 sq ft public building — conducted with permission. Full RF analysis extracted directly from the survey database rather than read off a heatmap. Full write-up, raw data, and findings in the GitHub repo.
Every measured location met the −67 dBm design threshold — no dead zones anywhere. The real problem was eight access points competing with each other for airtime on an unbalanced channel plan.
| Metric | Result | |
|---|---|---|
| Measurement points | 67 across two floors | |
| Network observations | 1,523 individual beacon readings | |
| Access points identified | 8, grouped from 94 distinct BSSIDs by radio prefix | |
| Coverage vs. −67 dBm threshold | 100% of points, both floors | |
| Instrument | Moto G Stylus 5G (2024) — Wi-Fi 5, 1×1, dual-band |
| Finding | Severity | Summary |
|---|---|---|
| F-01 | High | 5 of 8 APs share 2.4 GHz channel 6 — co-channel contention |
| F-02 | High | 6 of 8 radios crowded into 5 GHz UNII-3 at mismatched widths |
| F-03 | Medium | AP density exceeds coverage requirement — confirmed by client link rate at 1/5 of device ceiling |
| F-05 | Medium | Coverage propagates freely between floors through the central atrium |
Applied infrastructure and cloud work from the UMD assistantship, plus what's next in the lab.
Designed and deployed network infrastructure using Cisco routers/switches, Palo Alto firewalls, and Meraki access points for 120+ users. Implemented segmentation and security zones; optimized performance with OSPF routing and QoS policies; used Wireshark to identify and resolve latency issues.
Applied AWS core services (EC2, VPC, S3, IAM) through coursework tied to the Graduate Certificate in Cloud Engineering, covering cloud networking, security, and Linux-based virtualization.
Suricata on a mirrored switch port — real detection and alert triage practice.
Open to Network Engineer, Network Analyst, Network Architect, and Wireless Engineer roles.