HW Blog

This radar map ingests data from two SF city government Socrata databases, fire and service calls, which update records of all open and closed service calls within the city limits every 10-20 minutes.

I created a cloudflare worker to handle API calls, and simply call it upon page load.

The SF APIs respond with a GeoJSON FeatureCollection containing a Feature for each incident. there's a lot of interesting data attached to these Features that simply does not map well or add to incident context, so I recommend checking out all of the data fields.

Each incident is parsed and mapped using Leaflet.js, a comprehensive library for easy construction of maps. The layer feature of this library is what I used to parse an incidents data into a Leaflet.js pointToLayer. Leaflet.js also uses tile-caching to keep performance speedy and supports web raster basemaps like the one i used from CARTO (they do a good job of trying to make you pay, but their free API access is still around).

Some calls are marked as sensitive and will not include a location. Generally, non-sensitive calls will have a cross-street as a location.

Severity is determined by the priority rating given to each call by the dispatchers, and will update if a call has been reassessed.

I'm currently in the process of integrating a grouping feature for calls that occur in the same area and are possibly connected. For example, multiple accounts of shots fired within a five-block radius are likely connected to a single incident and should be indicated as such.

In late January of 2026, my team at the University of Denver participated in the Rocky Mountain Collegiate Cyber Defense Competition (RMCCDC) qualifier. The RMCCDC is a regional round of the National Competition (NCCDC), a realistic and respected cyber defense competition in the U.S.

This was my first time participating in a defense competition, and I was particularly excited for the steep learning curve that comes from defending an enterprise network against professional red-teamers. Apart from service uptime and defense, the competition is also judged on successful injects. Think of these as technical business requests that the team must fulfill without violating an SLA (usually within 15-30 minutes).

Our team consisted of six undergraduate CS students and one master's cybersecurity student.

The tournament is judged using the following schema:
35-50%: functional services uptime,
35-50%: successful completion of inject scenarios,
10-20%: exploitation & incident response.

I was initially feeling a bit uneasy going into this tournament. I had heard that the first hour was very demanding, as we would be setting up firewalls and resetting credentials on all of the systems. I was right to be uneasy, but in reality, this part of the competition allowed us to learn the components of our services and which traffic we'd need to create custom rules for.

Thanks to the memo templates we had developed before flag drop, injects were not as difficult as initially estimated. For each inject, we delegated tasks based on experience, interest, and pre-decided team roles. I worked on a lot of firewall logging injects: I looked for malicious/unauthorized communications, configured traffic rules at each network layer, and investigated outages when they inevitably occurred.

Communication was a key factor in our success, and despite no prior NCCDC experience across our team, we did a great job at maintaining clarity and composure. Verifying credentials and making sure everyone knew where their purpose lied on each inject/outage was crucial to staying ahead of the attack curve.

I thought that the red team did a pretty good job, and was honestly a bit surprised we didn't get hit as hard as some of the other teams. One of the main lessons that we learned in the qualifier was to immediately check for patches on our firewalls, OS, and services. One of our eight services kept going dark, and we observed unauthorized changes to our services throughout the majority of the competition on said service. I can only presume that an early patch would have been a great step in increasing uptime on that particular service. It was a long, strung-out day, but extremely fun.

We have a lot to review and learn before the regional, which will be held on March 6th/7th at Regis University, and I am super excited!