Forem: SHUBHENDU SHUBHAM

5 Tips I Wish I Knew Earlier as a Security Architect

SHUBHENDU SHUBHAM — Sun, 05 Oct 2025 15:00:55 +0000

Look, I'm not going to sugarcoat it. My last year as a security architect was rough. Really rough. I spent countless nights second-guessing other architects work, reading their documentation and sometimes second-guessing my decisions dealing with messy solutions proposed by other architects or my previous architects. Anyway, it was learning lessons hard way.

Here's the thing about this field-we all make mistakes. The key is learning from them before they cost your organisation millions or worse, land you on the front page of TechCrunch for all the wrong reasons.
Now I have finally figured out some things that would have saved me countless headaches. So grab your coffee, and let me share the five lessons that fundamentally changed how I approach security architecture.

Perfect is the enemy of Done (and Security)

Early in my career, I designed what I thought was the most beautiful security architecture for a financial services client. Multi-layered defenses, microsegmentation everywhere, strict zero-trust policies down to the individual file access level. On paper, it was gorgeous. In reality? It never got implemented.

The development teams revolted. The timeline slipped by six months. The budget exploded. And you know what happened during those six months we spent arguing about the perfect solution? We got breached through a vulnerability that my "phase one" plan would have actually caught.

Here's what I learned: an 80% solution implemented today beats a 100% solution implemented never. I'm not saying to compromise on critical controls, but I am saying that waiting for the perfect IAM solution while your developers are storing Azure credentials in Git repos is insane.

Now, I approach architecture in phases. Quick wins first – MFA, basic network segmentation, logging enabled. Then we iterate. Last quarter, we rolled out a "good enough" microsegmentation strategy that took three weeks instead of three months. Did it cover every edge case? No. Did it reduce our blast radius by 70%? Absolutely. We refined it over the next two quarters, but we had protection from day one.

The key question I ask myself now: "What's the minimum viable security architecture that meaningfully reduces our risk?" Then I build and iterate. Your threat actors aren't waiting for your perfect architecture to be done before they attack.

2.Business Context Isn't Optional – It's Everything

This one still makes me cringe. Two years ago, I mandated that all database connections had to go through a specific secure gateway. Made perfect sense from a security standpoint – centralized monitoring, policy enforcement, the works. Know what I didn't account for? The legacy trading system that processed millions of transactions per day and couldn't handle the 3ms latency my gateway introduced.

BFSI customer software went ballistic, causing failed transactions, financial blockages. The principal Architect pulled me into call, and let me tell you, that wasn't a fun conversation. we had to roll back the change and I had to redesign the whole approach.

The hard truth: If your security architecture breaks the business, you're not securing anything – you're becoming the problem that people route around.

I learned to start every architecture discussion with these questions: **What does this business unit actually do? What are their critical workflows? What's their tolerance for latency, downtime, or process changes? **I actually shadow people now before I design solutions for their areas.

For example, before rolling out our zero-trust implementation for the DevOps team last year, I spent two days just watching how they worked. Turns out, they had automated deployment pipelines that ran hundreds of API calls per minute. If I'd implemented my original plan with strict per-request authentication, their deployments would have gone from 10 minutes to 2 hours. Instead, we designed a solution using short-lived tokens with strong initial authentication that worked with their workflow. Deployment time actually improved by 15% because we optimized some other bottlenecks we discovered during the observation.

Security architecture isn't about what's theoretically best – it's about what actually works in your specific business context. And if people are finding workarounds to your security controls, you've failed as an architect.

3.Your Threat Model is Probably Wrong (And That's Okay)

Remember when everyone was obsessed with defending the perimeter? Yeah, I built architectures around that concept. Fancy firewalls, DMZs, the works. Then I watched helplessly as an intern clicked a phishing link and gave attackers access to our internal network. None of my beautiful perimeter defenses mattered.

Here's what nobody tells you: You will never have a perfect threat model. Threats evolve. Your business changes. New technologies emerge. The adversary gets a vote. The best you can do is be honest about your assumptions and build in resilience.

These days, I assume breach. Always. It's not pessimism; it's realism. When I designed the security architecture for our cloud migration, I didn't start with "How do we keep attackers out?" I started with "What happens when they get in?"

This mindset shift changed everything. Instead of spending 80% of our budget on prevention, we redistributed it: 40% on prevention, 40% on detection and response, and 20% on recovery capabilities. We implemented proper network segmentation so a breach in one area doesn't cascade everywhere. We built in kill switches. We ensured our logging was tamper-evident and stored separately from the systems being logged.

Last year, we did get breached – phishing attack, nothing exotic. But because we'd designed for breach, we detected it within 4 hours, contained it within 8, and fully remediated within 24. Total damage? One compromised workstation. Five years ago, that same breach would have been catastrophic because my architecture assumed it wouldn't happen.

Also, I update our threat model quarterly now. Every quarter, the team sits down and asks: "What changed? What are we seeing in the wild? What did we miss?" It's a living document, not a one-time exercise. Last quarter, we realized we'd completely underestimated the threat from supply chain attacks. We're adjusting our architecture accordingly, adding deeper vendor assessment processes and code signing requirements.

4.Complexity is a Security Vulnerability

You know what's worse than a known vulnerability? A security architecture so complex that nobody understands it. I learned this the painful way when I left my first sec architect role and my replacement needed three months to understand what I'd built. Three months where critical security decisions were delayed because people were afraid to touch something they didn't fully understand

I once inherited a security architecture with 47 different tools, each solving a specific niche problem. Sounds comprehensive, right? It was a nightmare. The tools didn't integrate properly. We had 12 different dashboards. Alert fatigue was crushing the SOC team. And the kicker? There were massive blind spots because some tools' coverage overlapped while other areas were ignored entirely.

Simpler architectures are more maintainable, more understandable, and ultimately more secure. Now I follow what I call the "3am test" – if I get a call at 3am about a security incident, can whoever is on call understand our architecture well enough to respond effectively? If the answer is no, the architecture is too complex.

I led a consolidation effort. We went from 35 security tools to 18. Yes, we lost some niche capabilities. But our detection rate actually improved by 30% because the SOC team could finally see the whole picture. Our mean time to respond dropped from 6 hours to 2.5 hours. And our annual licensing costs dropped by $400K, which we reinvested in actually training people.

I also started documenting architectures with a "why" focus. Not just "we use X tool to do Y" but "we chose X tool because our threat model prioritized Y, and we explicitly decided not to address Z because the risk is acceptable." Future you (and your successor) will thank present you.

5.Relationships Matter More Than You Think

This is the one that took me longest to learn, and honestly, it's the most important. You can have the most brilliant security architecture in the world, but if the developers hate you, the business units don't trust you, and the infrastructure team thinks you're obstructionist, it's all worthless.

My breakthrough moment came during a post-incident review. We'd had a configuration error that exposed some customer data. During the review, a senior developer said something that hit me hard: "We knew that configuration was risky, but we were afraid to ask security for help because you always say no." That stung. But it was true.

I'd spent so much time being the "security guardian" that I'd become the person people avoided. They weren't coming to me for advice; they were finding ways around me. And that made everything less secure, not more.

Security architecture is fundamentally a people problem, not a technology problem. Now I spend probably 40% of my time on relationship building. I have regular coffee chats with development leads. I attend sprint planning meetings, not to audit them, but to understand what they're building and offer security advice early. I've started a "security office hours" where anyone can drop by with questions, no judgment.

The results have been remarkable. Last quarter, three different teams came to me proactively while designing new features, asking "How do we make this secure?" Two years ago, they would have built it first and I would have found out during a compliance review. We caught and fixed potential issues at design time instead of after deployment, which saved huge amounts of rework.

I also learned to speak the language of whoever I'm talking to. With developers, I talk about threat modeling and secure SDLC. With finance, I talk about risk reduction and ROI. With executives, I talk about business enablement and competitive advantage. Same security architecture, different framing

And when I have to say no (which still happens), I don't just say no – I explain why and offer alternatives. "We can't do X because of Y risk, but we can achieve your business goal with Z approach instead." People can work with that.

The Real Secret

Here's the thing nobody tells you when you start out as a security architect: This job isn't really about firewalls, encryption algorithms, or zero-trust frameworks. It's about understanding risk, enabling business value, and building systems that are resilient when (not if) they fail.

The best security architecture I ever designed wasn't the most technically sophisticated. It was the one that balanced real risk reduction with business enablement, that the organization actually implemented and maintained, and that made security a natural part of how people worked instead of an obstacle to route around.

Would I have made different decisions if I knew then what I know now? Absolutely. But that's the nature of this field. We're constantly learning, adapting, and improving. The threats evolve, the technology changes, and we evolve with it.

My advice to anyone starting out in security architecture: Give yourself permission to be imperfect. Build relationships. Understand the business. Design for resilience, not perfection. And please, for the love of all that is holy, document why you made the decisions you made.

Your future self will thank you. And so will whoever inherits your architecture when you move on to your next challenge.

What lessons have you learned as a security architect? What do you wish someone had told you earlier? Drop a comment below – I'm always learning from this community.

Fixing Bluetooth Issues in Kali Linux

SHUBHENDU SHUBHAM — Sun, 17 Aug 2025 10:42:58 +0000

I recently ran into a frustrating problem on my Lenovo Ideapad 5 Pro running Kali Linux — Blueman refused to start, throwing the dreaded “Connection to BlueZ failed” error. It turned out my Bluetooth service wasn’t even running. Here’s how I diagnosed and fixed it.

error Photo:

Step 1 – Confirm the Adapter is Detected
First, I checked whether my Bluetooth hardware was visible to the system:

lsusb | grep -i bluetooth

Step 2 – Check the Bluetooth Service
Next, I checked the status of the Bluetooth daemon:

systemctl status bluetooth

Step 3 – Enable and Start the Service
To fix it, I simply enabled and started the service:

sudo systemctl enable bluetooth
sudo systemctl start bluetooth

Then I confirmed:

systemctl status bluetooth

The Docker Diet: How I Lost 1.1GB in 5 Steps

SHUBHENDU SHUBHAM — Thu, 24 Jul 2025 02:06:44 +0000

Last week, I was staring at a 1.2GB Docker image wondering where I went wrong. The build took forever, deployments were slow, and my registry storage costs were through the roof. Sound familiar?
After some serious container weight loss surgery, I managed to get that same image down to 98MB. Here's exactly how I did it.

Let's break down "Docker Diet" into 5 simpler steps:-

Phase 1: The Alpine Cleanse
Phase 2: Multi-stage Meal Prep
Phase 3: Cache Detox
Phase 4: Layer Liposuction
Phase 5: Final Weigh-IN

The Starting Point: My Chunky Container

My original Dockerfile looked innocent enough:

FROM node:22
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["npm", "start"]

Simple, right? But this little guy was packing 1.2GB of unnecessary baggage. Time for an intervention.

Phase 1: The Alpine Cleanse

First step was ditching the bloated base image. Ubuntu-based Node images are huge. Alpine Linux? Tiny and efficient.

FROM node:22-alpine
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["npm", "start"]

Result: Down to 680MB. Not bad, but we're just getting started.
The difference is massive - Alpine gives you a full Linux distro in about 5MB instead of 100MB+. Your app doesn't care what's underneath as long as Node runs.

Phase 2: Multi-Stage Meal Prep

This is where the magic happens. Think of it like meal prepping - you do all the messy cooking in one kitchen, then serve the clean final product.

# Build stage - the messy kitchen
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Runtime stage - the clean serving plate
FROM node:22-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY src/ ./src/
COPY package*.json ./
EXPOSE 3000
CMD ["node", "src/server.js"]

Result: Down to 320MB. We're getting somewhere!
The builder stage contains all the npm install mess, but the final image only gets the clean node_modules folder. All the npm cache and intermediate files? Gone.

Phase 3: Cache Detox

Time to clean house. Package managers love to hoard cache files, and we need to evict them in the same layer they're created.

FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

FROM node:22-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY src/ ./src/
COPY package*.json ./
EXPOSE 3000
CMD ["node", "src/server.js"]

Result: Down to 180MB. The cache cleanup made a bigger difference than expected.
Docker creates a new layer for each RUN command. If you install packages in one RUN and clean cache in another, the cache still exists in that earlier layer. Combining them into one RUN command actually removes the cache from the final image

Phase 4: Layer Liposuction

Now we get surgical. Every COPY and RUN creates a layer. Time to be strategic about what goes where.

FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json package-lock.json ./
RUN npm ci --only=production && npm cache clean --force

FROM node:22-alpine AS runtime
RUN addgroup -g 1001 -S nodejs && adduser -S nodeapp -u 1001
WORKDIR /app
COPY --from=builder --chown=nodeapp:nodejs /app/node_modules ./node_modules
COPY --chown=nodeapp:nodejs src/ ./src/
COPY --chown=nodeapp:nodejs package*.json ./
USER nodeapp
EXPOSE 3000
CMD ["node", "src/server.js"]

Result: Down to 120MB. Plus bonus security points for non-root user.
The --chown flag sets ownership without needing extra RUN commands. Less layers = smaller image. And running as non-root? That's just good manners.

Phase 5: The Final Weigh-In

Last step - a proper .dockerignore diet. This file is like telling Docker "don't even look at this stuff."

Create .dockerignore:

node_modules
npm-debug.log
.git
.gitignore
README.md
.env
.nyc_output
coverage
.nyc_cache
docs/
tests/
*.test.js

Final result: 98MB. Mission accomplished.

Now coming to the main question

Why This Matters?

Beyond the obvious storage savings, smaller images mean:

Faster builds and deployments
Lower registry costs
Reduced attack surface
Happier developers (nobody likes waiting for slow pulls)

The multi-stage approach is the real game-changer here. It lets you have your cake and eat it too - use all the build tools you need, then ship only what actually runs your app.

One More Thing

If you're working with compiled languages like Go, the size reduction can be even more dramatic:

FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o main .

FROM scratch
COPY --from=builder /app/main /main
EXPOSE 8080
CMD ["/main"]

That Go app? It'll probably be under 20MB.

The Docker diet isn't about starving your containers - it's about feeding them only what they actually need. And trust me, they'll thank you for it.

No More Secrets in State! Write-Only Arguments in Terraform 1.11

SHUBHENDU SHUBHAM — Thu, 17 Jul 2025 04:11:48 +0000

If you’ve been working with Terraform for a while, you’ve probably run into this frustrating situation: you need to pass a password or API token to a resource, but you don’t want that sensitive data sitting in your state file for everyone to see. Maybe you’ve tried creative workarounds with external data sources or complex scripting, but let’s be honest – it always felt like a hack.

Well, good news! Terraform 1.11 introduces write-only arguments, and they’re about to change how we handle secrets in our infrastructure code. Think of them as a secure handoff mechanism – you can pass sensitive data to resources during deployment, but Terraform immediately forgets about it once the job is done.

What Are Write-Only Arguments?

Write-only arguments are exactly what they sound like: arguments that you can write to (pass values to) but Terraform never stores anywhere. No state file, no plan file, no logs – nowhere. It’s like whispering a secret that gets forgotten the moment it’s used.

Here’s the key insight: most of the time, we don’t actually need Terraform to remember passwords and tokens. We just need to pass them to the cloud provider during resource creation or updates. Once the resource is created, the cloud provider handles the secret internally.

The Problem This Solves

Before write-only arguments, here’s what typically happened:

`# The old way - DON'T do this!

resource "aws_db_instance" "example" {
instance_class = "db.t3.micro"
allocated_storage = "5"
engine = "postgres"
username = "dbuser"
password = "super-secret-password" # This ends up in state!
skip_final_snapshot = true
}`

That password would sit in your state file, readable by anyone with access to it. Not great for security.

How Write-Only Arguments Work

With Terraform 1.11, providers can now mark certain arguments as write-only. The AWS provider, for example, introduces password_wo (write-only) arguments for database resources:

resource "aws_db_instance" "example" { instance_class = "db.t3.micro" allocated_storage = "5" engine = "postgres" username = "dbuser" password_wo = "super-secret-password" # Never stored! password_wo_version = 1 skip_final_snapshot = true }
Notice two things:

The password_wo argument – this is write-only
The password_wo_version argument – this is how we trigger updates

Learn in detailed here Blog

My Firebase Webapp almost got pwned by a bot. Then another bot saved it.

SHUBHENDU SHUBHAM — Tue, 15 Jul 2025 03:45:16 +0000

My Firebase Webapp almost got pwned by a bot. Then another bot saved it.

Running Firebase 9.22.1 in prod → hashtag#Snyk bot drops a PR → "Just another dependency update" I thought. WRONG.

Hidden 4 levels deep: SNYK-JS-GRPCGRPCJS-7242922 - a DoS vulnerability that could've nuked my entire app with crafted gRPC messages.

The bot found it. Fixed it. Explained it. All automated.

Last week, I got an unexpected visitor to my GitHub repository. Not a human contributor, but Snyk's automated security bot, flagging a critical vulnerability in my Firebase project. What started as a routine dependency check turned into a fascinating case study of how modern security tools can catch threats that even experienced developers might miss.
The culprit? An uncontrolled resource consumption vulnerability lurking in the @grpc/grpc-js library, buried deep within Firebase's dependency chain. With a severity score of 559 and the identifier SNYK-JS-GRPCGRPCJS-7242922, this wasn't just another minor security hiccup—it was a legitimate denial of service risk sitting in production code.

Learn More about here :-
Website

Resolving Docker Socket and Daemon Conflicts: Unifying CLI and Docker Desktop on kali Linux

SHUBHENDU SHUBHAM — Sun, 23 Mar 2025 05:48:23 +0000

If you're using Docker Desktop on Linux and facing issues like conflicting results between docker ps and sudo docker ps, containers not appearing in Docker Desktop, or volume permission errors, this detailed guide will walk you through resolving these problems. We'll cover everything you need to know to harmonize Docker CLI and Docker Desktop under a unified context (desktop-linux) while troubleshooting common issues.

docker ps

sudo docker ps

and you're getting different results. Then you're at the right place.

Understanding the Problem

1.Different Results for docker ps vs sudo docker ps:

When you run docker ps, you might see no containers, but sudo docker ps displays running containers.
This happens because docker and sudo docker may be pointing to different Docker socket files (DOCKER_HOST endpoints).

2.Containers Not Showing in Docker Desktop:

Even if sudo docker ps displays running containers, they might not appear in the Docker Desktop UI. This occurs when the Docker daemon's configuration or context is not aligned with Docker Desktop.

3.Root Causes:

DOCKER_HOST environment variable overriding the context.
Docker CLI using /var/run/docker.sock while Docker Desktop uses ~/.docker/desktop/docker.sock.
Misconfigured permissions on directories and files used in volume mappings.

Step-by-Step Troubleshooting

Step 1: Identify the Active Contexts

To diagnose the issue, check which Docker context is active and ensure it matches the expected configuration for Docker Desktop.

List Docker Contexts:

docker context ls

eg output:

NAME	TYPE	DESCRIPTION	DOCKER ENDPOINT
default *	moby	Current DOCKER_HOST-based configuration	unix:///var/run/docker.sock
desktop-linux	moby	Docker Desktop	unix:///home/user/.docker/desktop/docker.sock

The * indicates the active context. If default is active but you’re using Docker Desktop, you need to switch to desktop-linux

Step 2: Unset the DOCKER_HOST Environment Variable

When DOCKER_HOST is set, it overrides the active context. To fix this:

Check DOCKER_HOST:

echo $DOCKER_HOST

If set (e.g., unix:///var/run/docker.sock), proceed to unset it.

Unset Temporarily:

unset DOCKER_HOST

Remove Permanently: Edit your shell configuration file:

nano ~/.bashrc

Remove or comment out any DOCKER_HOST line:

# export DOCKER_HOST=unix:///var/run/docker.sock

Reload the shell:

source ~/.bashrc

Step 3: Align Docker CLI with Docker Desktop

Ensure that the Docker CLI points to the desktop-linux context:

1.Set desktop-linux as Active Context:

docker context use desktop-linux

2.Verify Context:

docker context ls

Expected Output:

NAME	TYPE	DESCRIPTION	DOCKER ENDPOINT
default	moby	Current DOCKER_HOST-based configuration	unix:///var/run/docker.sock
desktop-linux *	moby	Docker Desktop	unix:///home/user/.docker/desktop/docker.sock

3.Test docker ps: Run docker ps to confirm it now shows running containers managed by Docker Desktop

Step 4: Debug docker ps vs sudo docker ps

If docker ps and sudo docker ps still show different results, the issue lies with permission conflicts on the Docker socket file

1.Check Socket Permissions:

ls -l /var/run/docker.sock

Example Output:
srw-rw---- 1 root docker 0 Mar 22 10:00 /var/run/docker.sock
2.Grant User Access to Docker Group:

Add your user to the Docker group:

sudo usermod -aG docker $USER

Log out and log back in to apply the group change.

3.Re-test docker ps:

docker ps

This should now show the same output as sudo docker ps.

Step 5: Resolve Missing Containers in Docker Desktop

If containers are visible in docker ps but not in Docker Desktop, verify and restart Docker Desktop services.

1.Restart Docker Desktop:

systemctl --user restart docker-desktop

2.Check Status:

systemctl --user status docker-desktop

3.Ensure Unified Context: Confirm docker ps aligns with Docker Desktop's context:

docker context ls

Step 6: Test and Validate

Now, test your setup to ensure all components are working correctly:

1.Run a Test Container:

docker run --rm hello-world

2.Inspect Running Containers:

docker ps

3.Verify in Docker Desktop: Check the Docker Desktop UI to confirm the container is listed.

in my case I have directly spined wazuh docker single node

ENJOY DOCKER DESKTOP 🖥️ ON KALI MACHINE

Conclusion

By following these steps, you can unify Docker CLI and Docker Desktop on Linux, resolve docker ps vs sudo docker ps conflicts, and fix permission issues for a seamless development experience. With the desktop-linux context configured, Docker will run harmoniously across CLI and Docker Desktop.

Keep learning, keep Troubleshooting !

Missing Dark Mode in Wazuh ?

SHUBHENDU SHUBHAM — Sun, 23 Mar 2025 04:12:03 +0000

Working on Wazuh in a bright interface can sometimes strain your eyes, especially during those long sessions. Luckily, Wazuh offers a sleek dark mode! Here’s a straightforward guide to enable it if you’re running Wazuh in a single-node Docker setup.

Steps to turn On Dark Mode:

Access the Dashboard Open your Wazuh web interface and log in.
Navigate to Dashboard Management Click on the hamburger menu (those three horizontal lines in the top-left corner). From there, select Dashboard Management.

Find Advanced Settings In the Management Menu, scroll down until you see Advanced Settings. Click on it.

Change Appearance Settings In the Advanced Settings section:
Look for the Appearance category.
You’ll see an option for Dark Mode with a toggle labeled theme:darkMode.
Enable Dark Mode Switch the toggle to On. A quick page refresh might be required for the new theme to take effect.

Clear command not found inside docker container ?

SHUBHENDU SHUBHAM — Thu, 20 Mar 2025 16:19:59 +0000

if you're inside docker container using cli trying to modify files and wanna clear yout terminal , you tried ctl + l or clear command but getting response like

bash: clear: command not found

don't worry it's due to container nature, since it always install bare minimum utilities so we can manually install linux utility to work smoothly .

Find out container os image

bash-5.2# cat /etc/os-release

here in my case Wazuh Manager container is running on Amazon Linux, which is based on Fedora, the package manager to use is dnf.

now we can install clear utility in you container by following steps

Install util-linux package it contains the clear command

dnf install util-linux -y

or else you can install ncurses

See Clear command will work now .

before

After

keep Learning, Keep Troubleshooting !

Upgrading wazuh 4.11.0 using docker in single node

SHUBHENDU SHUBHAM — Wed, 19 Mar 2025 16:25:57 +0000

In Feb Wazuh released V4.11.0 let's understand what are the major updates and how to upgrade it using docker in single node.

Instead of writing changes in bullet points it's better to visualise through mind map.
Official Blog

Now Let's do technical part to upgrade it

Step 1: Backup your Data

docker compose down

Step 2: Download the latest Wazuh Docker compose files

Navigate to your wazuh Docker directory and pull the latest version

cd /path/to/your/wazuh-docker
git fetch --all --tags

Step 3:

git checkout v4.10.0

if you have custom configurations, ensure they are compatible with the new version

Step 4: Start the New Wazuh version

docker compose up -d

Step 5: Check the latest version

 docker ps

Fix It Before They Break It: The True Role of Vulnerability Management

SHUBHENDU SHUBHAM — Tue, 11 Mar 2025 14:41:29 +0000

Before we start let's understand a few keywords

Vulnerability: Vulnerability is always defined by the ISO 27002 and VM is a weakness of an asset or group of assets that can be exploited by 1 or more threats.
Assets: Anything that needs to be monitored and protected is known as assets , eg data, systems, Hardware, S/w or process.
Threat: The potential actor or event that can exploit the vulnerability eg. Malware, Hacker
Risk: The Potential damage or loss caused if the threat exploits the vulnerability eg. financial loss due to data breach.

Let's understand the those keywords with the realtime eg

A banking app with weak password policies (vulnerability) could be targeted by phishing attacks (threat), resulting in unauthorized access to customer accounts (risk)

Who categories & ranks Vulnerability?

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard that provides a standardized way to access and communicate the severity and characteristics of s/w vulnerabilities.

The National Vulnerability Database (NVD) adds a severity rating for CVSS scores. NVD maintains an updated library of common vulnerabilities and exposures (CVEs) with rankings and related details like vendor and product information. Originating from the MITRE Corporation in 1999, this list is synced with NVD and offers basic insights into each vulnerability.

The CVSS Base Score ranges from 0.0 to 10.0

0.0: No impact (None)
0.1–3.9: Low severity
4.0–6.9: Medium severity
7.0–8.9: High severity
9.0–10.0: Critical severity

Let's understand with the real world eg

The 2021 Log4Shell vulnerability (CVSS score: 10.0) in the popular Log4j library posed critical risks to organizations globally, as attackers could remotely execute code on affected systems.

The Vulnerability Management Lifecycle

An effective vulnerability management program involves five key stages, each critical for ensuring a robust security posture:

Assess:

Identify vulnerabilities across assets using tools like network scans or agent-based systems.
Example: A company scans its servers with a vulnerability scanner to detect weak points like unpatched software.

Prioritize:

Rank vulnerabilities based on their CVSS scores, threat exposure, and business impact.
Example: A healthcare provider prioritizes vulnerabilities in its patient data system over an internal HR tool.

Act:

Apply one of the following actions:

Accept: Acknowledge the risk but take no action for non-critical issues.
Mitigate: Reduce risk through controls like firewalls.
Remediate: Fix the vulnerability entirely, such as by applying patches.
Example: Patching a critical operating system vulnerability in servers.

Reassess:

Verify the effectiveness of remediation actions and ensure no new vulnerabilities have emerged.
Example: After patching software, the IT team conducts another scan to confirm the issue is resolved.

Improve:

Use lessons learned to refine processes and tools for future vulnerabilities.

Example: Automating patch deployment to reduce manual errors and delays.

for mindmap
https://sivolko.github.io/mindmaps/

How to troubleshoot a Disconnected Wazuh Agent in a Docker Single-Node Environment?

SHUBHENDU SHUBHAM — Thu, 06 Mar 2025 05:38:25 +0000

In this blog post, we'll walk through the steps to troubleshoot and resolve a disconnected Wazuh agent when using a Docker single-node setup. Wazuh is a powerful security monitoring tool, and it's essential to ensure that all agents are properly connected to the Wazuh manager for effective monitoring. We'll cover checking logs, verifying configurations, and ensuring network connectivity.

Step 1: Verify Docker Container Status

First, ensure that all relevant Docker containers are running. Use the following command to list all running containers:

docker ps

Check for the Wazuh manager, indexer, and dashboard containers. Example output:

CONTAINER ID   IMAGE                           COMMAND                  CREATED         STATUS                      PORTS                                                                                                                                                                 NAMES
22825f91974b   wazuh/wazuh-dashboard:4.10.0    "/entrypoint.sh"         7 weeks ago     Up 9 days                   443/tcp, 0.0.0.0:443->5601/tcp, [::]:443->5601/tcp                                                                                                                    single-node-wazuh.dashboard-1
e951f7c6be71   wazuh/wazuh-manager:4.10.0      "/init"                  7 weeks ago     Up 9 days                   0.0.0.0:1514-1515->1514-1515/tcp, [::]:1514-1515->1514-1515/tcp, 0.0.0.0:514->514/udp, [::]:514->514/udp, 0.0.0.0:55000->55000/tcp, [::]:55000->55000/tcp, 1516/tcp   single-node-wazuh.manager-1
1a20bb195d5b   wazuh/wazuh-indexer:4.10.0      "/entrypoint.sh open…"   7 weeks ago     Up 9 days                   0.0.0.0:9200->9200/tcp, [::]:9200->9200/tcp                                                                                                                           single-node-wazuh.indexer-1

Step 2: Check Wazuh Manager Logs

Check the logs of the Wazuh manager container for any errors or warnings. This can provide insights into why the agent might be disconnected:

docker logs e951f7c6be71

Step 3: Verify Agent Configuration

Ensure that the Wazuh agent configuration file (/var/ossec/etc/ossec.conf) on the agent machine is correctly configured with the manager's IP address.

Open the agent configuration file:

sudo nano /var/ossec/etc/ossec.conf

Verify the section has the correct manager IP address:

<client>
    <server>
        <address>xxx.xx.x.x</address>
        <port>1514</port>
    </server>
</client>

Step 4: Re-register the Agent

If the agent is listed as disconnected, re-register it with the Wazuh manager. First, remove the existing agent registration from the Wazuh manager:

docker exec -it e951f7c6be71 /var/ossec/bin/manage_agents -r 001

Re-register the agent using the following command on the agent machine:

sudo /var/ossec/bin/agent-auth -m xxx.xx.x.x -A kali

Step 5: Restart Wazuh Agent

After updating the configuration and re-registering the agent, restart the Wazuh agent service:

sudo systemctl restart wazuh-agent

Step 6: Check Network Connectivity

Ensure that the agent machine can communicate with the Wazuh manager. Use ping and telnet to test connectivity:

ping xxx.xx.x.x
telnet xxx.xx.x.x 1514
telnet xxx.xx.x.x 1515

Step 7: Verify Agent Status

Check the status of the agent from the Wazuh manager container:

docker exec -it e951f7c6be71 /var/ossec/bin/agent_control -l

Verify over Wazuh Dashboard UI

Thanks for reading, Keep troubleshooting!

Mitigating vs Eliminating Threats

SHUBHENDU SHUBHAM — Sat, 01 Mar 2025 04:23:23 +0000

In security industry I have often seen people getting confused or thinking both as same Mitigating Threats vs Eliminating Threats. Let's discuss as security Threat Modeling POV.

When it comes to securing systems, there are four main ways we can address threats: Mitigating threats, Eliminating threats, Transferring threats, and Accepting the risks. In this blog, let's focus on the first two: Mitigating and Eliminating threats.

Mitigating Threats

Mitigating threats means taking steps to make it harder for potential threats to be exploited. Think of it as adding barriers or safeguards to protect your system.

Passwords for Login Control: By requiring passwords, you control who can access your system, mitigating the threat of spoofing (someone pretending to be someone else).

Password Controls: Enforcing complexity requirements (e.g., a mix of letters, numbers, and symbols) and expiration policies makes it less likely that a password can be guessed or misused if stolen.

Eliminating Threats

Eliminating threats involves removing the threat entirely. This is usually done by eliminating features that introduce vulnerabilities.

Administrative Access via URL:

Mitigation: Use passwords or other authentication methods to secure the URL.
Obfuscation: Change the URL to something less obvious (e.g., /j8e8vg21euwq/) to make it harder to find.
Elimination: Remove the web interface altogether and handle administration through a more secure method, like the command line.

Moving Away from HTTP:

Switching from HTTP to a more secure protocol reduces the attack surface, making it easier to manage and mitigate threats.

Key Considerations

Threat Analysis: Identify which threats can be mitigated and which need to be eliminated.

Feasibility: Consider how likely and practical it is to address each threat.

Comprehensive Models: Ensure your threat model covers various scenarios, even those that seem unlikely.

Visualizing Threat Mitigation and Elimination

Below is a simple chart to help visualize the process of mitigating and eliminating threats:

| Strategy         | Example                                              | Description                                                      |
|------------------|------------------------------------------------------|------------------------------------------------------------------|
| Mitigating       | Passwords for Login Control                          | Controls access to the system, reducing spoofing threats.        |
|                  | Password Complexity Requirements                     | Makes passwords harder to guess or misuse.                       |
| Eliminating      | Administrative Access via URL                        | Remove web interface; use command line for administration.       |
|                  | Moving Away from HTTP                                | Reduces attack surface by using a more secure protocol.          |

Mitigating threats adds layers of protection, making it harder for vulnerabilities to be exploited. Eliminating threats removes the vulnerabilities altogether, reducing the potential attack surface. Both strategies are essential for effective threat modeling and securing systems.

By understanding and applying these concepts, organizations can better protect their systems from potential threats and vulnerabilities.

Thanks for reading!