The Problem

Transitioning from SCCM Admin to an IT Admin of an organization is HARD. It comes with a lot of global challenges that go far beyond managing and being an admin of a particular tool or platform. Having no one to go to, limited industry experience and only a basic understanding of networking, building and managing an IT Network infrastructure of an org from scratch can be tough. This is the area where I had the most challenge in keeping systems running and keeping users sane, because everyone hates a slow network. Even me.

Pushing to PROD :

Unlike in development where there are separate environments ( even SCCM had it ) - Test, Pilot, Prod. In Org networking there is only one environment “the people” or rather PROD. Every change had to be made late at night and almost always came with new challenges the next day. Already being a big org with 70+ users and 200+ devices it was difficult to predict the full impact of each change. Every adjustment carried selective and calculated risks, and implementing major changes required extensive analysis and careful planning.

The OTT Challenge :

The goal is to make industry leading video products which meant streaming is at the forefront, demanding massive bandwidth. The environment I managed has TVs , Mobiles, Tablets, STBs, consoles and laptops. Getting Bandwidth to laptops is one thing; getting the same to all the other devices, all streaming in different resolutions, by multiple Teams was an entirely different challenge. TVs were particularly hard as they have weaker wifi modules which frequently caused streaming issues and connectivity drops.

Tools & Setup

In my arsenal I had a fixed Bandwidth and the usual networking instruments. Here’s are few changes I made to address the challenges without divulging too much.

Web Filter - We can’t always control how users consume bandwidth. Implementing web filtering helped me direct bandwidth where it mattered most. I learned the importance of whitelisting and maintaining an exception group, especially since TVs often react differently to network restrictions and there's always something new thats getting blocked.

MAC Binding - Initially, any device could connect to the network, it was a bandwidth and security risk. I collected all device MAC IDs, bound only the approved ones, and blocked the rest. It wasn’t a popular move among my peers, but it was necessary to stabilize and secure the network.

Traffic shaping - When I joined, there was no traffic shaping in place, I still wonder to this day how the org survived without it in its initial days because one device can literally eat up the whole Bandwidth and this used to happen for the first 4 months when I had limited access. Being new I had no clue but Reddit became my classroom for understanding and implementing traffic shaping policies. After multiple trials, I found the right balance to keep both users and the network stable.

LAN connection - Wi-Fi wasn’t reliable, especially for TVs with weak modules. I borrowed a LAN tester from our ISP Vendor team, mapped the patch panel, and set up dedicated LAN bays for the QA team to test TVs without bandwidth and signal issues.

Challenges from Bandwidth Constraints - Bandwidth is like the size of the room you can operate in — exceed it, and systems start failing. Every change had to be made with bandwidth in mind. Monitoring became a daily ritual, especially during client meetings and demos, with quick policy adjustments to keep everything within safe limits.

Requirements of the OTT Industry - There are many components in an app, and understanding how each interacts with the internet is crucial. Firewall restrictions, certificate issues, and failed API calls all need to be analyzed and worked around effectively with the other departments.

What I Learned

Through all the struggles and challenges of managing a network, I've understood one thing, the goal is not the perfect network with highest bandwidth to everyone, 0% latency and 0% packet loss but the MOST STABLE one. One which people can rely on for their day to day operations. All the challenges I faced ultimately helped me reach a point where I established a stable and reliable network connection for my org.

Still more work to be done, always room for improvement !

The Problem

I was asked to deliver the annual Cybersecurity training for the entire organization, but there was no platform to host or distribute the content. Unlike larger companies that use proper LMS platforms, we had nothing in place and since the content included internal policies and org-level security guidelines, it couldn’t just be shared casually over email or chat. And it needed to be ready available to all for reference.

Tools & Setup

I used our Internal Google Sites to build a lightweight, secure LMS-style platform. It allowed me to host the training material, control access, and organize modules in a clean format. From there, I shared it with all employees and tracked participation through simple internal processes. What I Implemented:

• Created a centralized space for Cybersecurity training content.
• Organized modules, policies, and assessments in a structured format.
• Made it easy to access without needing paid LMS software.

Impact

The same portal is now used for IT onboarding of all new employees, along with the live onboarding session.

No more PPTs. The same is shared along with the compliance assessment.

It became a repeatable process instead of a one-time workaround, so new joiners and existing staff get the same standardized training without any extra tooling.

The Problem

Every organization has an internal intranet, a central hub where users can review policies, apply for leave, access the employee directory, find essential forms, and stay updated with the latest news and events happening with the organisation. We hadn't had anything setup dedicated for that. And also we needed to create a unified platform where all users could easily access the company handbook, along with the IT and security policies.

Tools & Setup

Similar to how I setup the LMS system, I used our Internal Google Sites to build a central hub for all our company info.

• Created a centralized space for IT and Security Policies.
• Organized department-wise policies in a structured format.
• Created a centralised dashboard with icons for users to quickly navigate to all forms and links.
• Added my own easter egg space where users can click to see photos of company events and activities.
• Setup a basic Intranet without any additional expense.

Impact

Although a great deal of effort went into setting this up and developing numerous IT and security policies, the intranet was never released organization-wide for reasons I can’t specify here. I still wanted to highlight this project because it was genuinely impactful and could have benefited everyone in a meaningful way. Sadly, it never saw the light of day. The project isn’t shelved, just stuck in prolonged limbo.🥺

The Problem

IT assets were scattered across a shared spreadsheets used by multiple departments with inconsistent serials and ownership, which made device tracking a nightmare, especially in an environment where there are many remote users. Not to mention the annual asset auditing ! Managers had no way to see who had what and always had to wait for ME to get back to them with the details.

Tools & Setup

To efficiently track assets and help managers identify which employee had what, I used:

• SnipeIT - Open-source IT Asset Management
• Hosted the application on an EC2 Instance

Since the ITAM would be hosting critical infrastructure data, I closed down the IP to only be accessed using VPN and to select users based on RBAC.

Impact

Tracking and tagging assets with custom IDs became easy, and assigning or reassigning them across teams was much faster. Instead of scrolling through hundreds of rows, assets or collections of them could be found instantly with simple keyword searches. Managers were finally happy, audits became smoother, ownership was clear, and every device could be labeled with the right status in seconds. Basically made my job easier than ever on the asset front.

Project Documentation

I first heard about the open-source SIEM Wazuh from a senior-level Director I worked with. At the time, I wasn’t fully familiar with what a SIEM was, but the concept immediately intrigued me. This curiosity pushed me to explore and experiment with Wazuh in my home lab environment. That hands-on testing became the foundation of my understanding of modern detection and monitoring tools.

Tools & Setup

• Proxmox VE - Used to virtualize and manage both servers and endpoint machines.
• Wazuh Manager VM - Central SIEM platform that collects, normalizes, correlates, and alerts on security events.
• Windows 11 VM - Configured as an enterprise-like workstation with Wazuh agent installed.
• Kali Linux - To simulate attacks and scenarios.

1. Brute-Force Login Attempt

Starting with an easy-to-detect event like a brute-force attack, the first step I took on the VM was enabling the necessary audit policies so Wazuh could capture those attempts.

              
              auditpol /set /subcategory:"Logon" /success:enable /failure:enable
              auditpol /set /subcategory:"Account Lockout" /failure:enable /success:enable
              auditpol /set /subcategory:"User Account Management" /failure:enable /success:enable
   
              

To test brute-force detection, I first locked the VM and entered incorrect passwords until the threshold was reached. Since that scenario is too manual and all too common during routine password resets (trust me I know), I pushed the test further by using Kali Linux with evil-winrm and the rockyou.txt password list. Some screenshots of the attempts and alerts. Also at the end, manually tested with a dummy password to confirm brute force access.

I had more testing to do, so I didn’t go too deep into hardening. I only made changes that I could easily roll back, such as adjusting the password policy and disabling the Remote Management service.

Project Documentation

I am not sure if I should include this as a project, but this something I had a lot of fun making for my organisation. I felt compelled to share it because it comes with a valuable lesson and a story of a security misstep on my part that taught me a lot.

Tools & Setup

• Wix.com for domain and hosting
• CMS (Content Management System)

Educational Moment

Being part of the operations team means you often get asked to do a lot more than what’s written in your JD. I had already built a simple Secret Santa webpage for our Org for Christmas last year 2024, just a basic login page were people could sign in and click on a Christmas tree to reveal their assigned friend. Something simple ! But I underestimated my colleagues from other departments specifically the Backend team. Since I was short on time, I didn’t properly review the code I’d written, and I assumed that because it was hosted on Wix's CMS, all the data would automatically be secure. Unfortunately for me, it wasn’t. The code I wrote returned a webhook back which was, in my defence encrypted but in base64. My colleagues spotted this and decoded it, and saw the filter query I had used to fetch each user’s name and their Secret Santa match. By adjusting that query, they were able to retrieve the entire list of participants and their assigned friends in JSON. This vulnerability was made known.

This was pretty embarrassing because I had completely depended on the tech to hide everyone’s data. When the opportunity came around again this year, I decided to do it right. Before building anything, I went and spoke to the backend team to understand how to avoid the mistakes I made last time, and I took all their pointers seriously. This time, I set up a separate backend script to handle all data calls from the CMS. By seperating separating the frontend and backend, I was able to make the system much more secure. And just to be safe, I ran the demo script with the backend team to check if anything had been overlooked. Thankfully, they all gave a thumbs up.

Did not trust them fully so took it to AI bots just to make sure. 😁 I also updated the login tokens to 16-digit alphanumeric strings to prevent brute-force attempts and locked down the CMS as much as possible. Anyways; another solid lesson learned as always.

Wanted to end on a fun note. Many more to come...

Thank you for reading !