Alborz N.

Oct 20, 2026

Let's assume a hardening chain of thought. Suppose that you got hired to harden a business that appeals to two distinct types of clients: public and private. Public clients' concerns include GDPR and PII protection, while private clients' concerns include legal disclosures, confidential data, and third-party divisions. First, consider public clients who are individuals sharing extensive and relatable data. An offensive thinker uses stolen data to train models, comparing behavioral analysis from CCTV footage. This conduct is against GDPR and PII protections. Let's assume the stolen data sold on the dark web is several terabytes, as significant as needed to extract what it's scrupulously aimed at. Leaked data finds its way out of unsafe or vulnerable CCTV cams with default user/passwords, old firmware, or supposedly high-risk manufacturers. However, NIST guidance recommends isolating systems like the NVR. High-risk products are prone to exploitation and have a poor reputation, and each newly emerging CVE is worth identifying in our software. Another scenario is when a threat actor poses threats to the device that runs the camera software, which might be vulnerable, whether via web-application unencrypted protocols(HTTP, Telnet, FTP) or mobile application weaknesses. Each endpoint must run on TLS. It's imperative to secure all application endpoints with TLS and expose only 443 (or a VPN) to the internet, and allow internally only the ports each zone needs. Assume the software that holds financial systems and employees' information connects through wired 802.1X and WPA3-Enterprise Wi-Fi. A sound method for controlling internal access. 802.1X doesn’t encrypt wired traffic, so TLS is still required. Use certificate-based login (EAP-TLS) instead of password-based login. 802.1X with EAP-TLS authenticates the device or user and can dynamically assign the correct VLAN, but it does not encrypt the traffic itself. For link-layer encryption on wired networks, IEEE 802.1AE (MACsec) can be used where switches and endpoints support it. In the absence of MACsec, application-layer encryption (TLS) remains necessary for sensitive data.

Wired data is harder to sniff than public Wi-Fi, but only switch protections (DAI, port security) and encryption actually stop it. Wired traffic is harder to passively sniff than open Wi-Fi only when the switch is properly hardened (Dynamic ARP Inspection, DHCP snooping, port security, and no MAC flooding success). On a flat or poorly configured switched network, an attacker on the same segment can still intercept traffic via ARP poisoning or by forcing the switch into a hub-like state. These switch-level controls should be enabled alongside 802.1X. Nevertheless, the software and the machine are susceptible to a broad range of scenarios: e.g., physical access lets attackers plug into ports, steal devices, or use USB. But learning MAC addresses doesn’t even need physical access; being on the same network segment, such as guest Wi-Fi, is enough. Local networks transmit MAC addresses, but they do not travel over the internet. An attacker on guest Wi-Fi could reach a restricted network through a device connected to both, such as a shared printer. The first half of the MAC showcases producers' brands and reveals their perceived reputation. MAC filtering cannot provide trustworthy access control because attackers can spoof MAC addresses. Also, imagine all CCTVs contain IPs and MAC addresses at Layer 2, and cameras often have weak access controls. Here, firewalls that restrict data are effective. If the system allows outbound data, the reverse shell becomes useful once it gains initial access. Combining egress filtering with DNS filtering, a web proxy, and EDR enhances security. Private clients' data at rest and in transit is at high risk as long as computers that work with financial software are unsupported and unpatched. Patching fixes bugs, not design flaws. Design flaws remain until someone changes the architecture. Does the database use parametrised queries? How resilient is the design? Is least privilege applied to database accounts? Is encryption at rest valid and tested? Any tamper-proof logs and backups? help us mitigate risks for stages of risk management, and the life cycle-NIST CSF 2.0 organizes the system in the time of crisis or attack. First, I'd say, basically, separated networks based on separation of concerns instinctive thinking. They should isolate guest Wi-Fi from employees and management staff. They restrict each control, monitoring, and system to a separate and isolated network, secured with firewalls. It's okay to use VLANs and switches for segregation. VLANs provide logical separation but are not a reliable security boundary on their own. Misconfigured trunks, dynamic trunking protocol (DTP), or native VLAN handling can allow VLAN hopping. To make segmentation effective, disable unused ports, hard-set access ports, use dedicated firewall or ACL enforcement between VLANs, and consider private VLANs or microsegmentation for higher-risk zones such as CCTV. A compromised camera should not be able to reach finance or employee systems simply because both are reachable via inter-VLAN routing.Therefore, probably harder for the attacker; hacking one CCTV might not lead to access to finance, as it has no direct access to the rest. A great setup uses both network firewalls and host firewalls.

Finally, a couple of frameworks for compartmentalizing risk types: inherent and residual risks. Strategies to mitigate based on the specifications: Reduce, Transfer, Accept, or Avoid, and for general rules: First, for all accounts, do MFA, access control, separate admin and privileges. Apart from that, EDR on all endpoints, logs centralized in a SIEM. Second, public clients: Carry out a DPIA for CCTV processing. Third, Private clients: GDPR art .28(contracts with third parties that process the data) and NDA legality.

View post

Sep 28, 2026

Portfolio is live: https://alborznazari.github.io/

It's five 3D scenes: VFX pipeline, a museum sales floor, hands-on labs, my write-ups, and AI safety work.

DMs open. I am always glad to connect with people involved in AI safety and LLM security.

View post

Aug 28, 2026

Security-focused software engineer. Available for paid hourly work. I do the unglamorous work that protects production: review code, find weak points, document risk, and help the team close it. I communicate clearly and write well. Findings come back in plain language, with enough detail for engineers to fix and enough clarity for stakeholders to decide.

Best fit:

- Security Engineer roles

- SOC / SOC 1 operations support

- Pre-release security review

- API and auth hardening

- AppSec engineering assistance

- Secure-coding fixes with clean, usable notes

- LLM security and AI safety reviews

Remote. Fast turnaround. Strong written and verbal communication. If you need help locking down a product, a SOC workflow, or an LLM / AI system, let’s talk.

View post