Cybersecurity Background and Experience

I’m building my cybersecurity career through hands-on labs, structured projects, and clear documentation. My background includes full-stack development, business intelligence, and systems troubleshooting, which helps me understand cybersecurity from both a builder’s and defender’s perspective.

Yes, I’m early in my cybersecurity career. At the same time, I have been focused on building real experience through labs, SIEM work, detection testing, architecture projects, and documentation instead of only studying theory.

Cybersecurity fits how I naturally think. I like understanding how systems work, where they can fail, how attackers take advantage of weaknesses, and how defenders can improve visibility, controls, and response.

My portfolio is built around evidence. I show the lab setup, the tools used, what I tested, what worked, what broke, how I fixed it, and what I learned from the process.

Because I take the work seriously. I’m coachable, consistent, and willing to put in the effort to learn. I may be early in the field, but I already practice the habits that matter: testing, troubleshooting, documenting, and improving.

I’m looking for entry-level roles such as SOC Analyst, Security Analyst, Junior Security Engineer, Detection Engineering Support, Cloud Security Support, API Security Support, Vulnerability Management Support, and security documentation or GRC-related roles.

I can support alert review, log analysis, evidence collection, basic triage, and investigation workflows. My Wazuh lab work helped me understand how suspicious activity appears in logs and how alerts should be validated.

I bring a builder’s mindset. I’m comfortable setting up systems, troubleshooting issues, reviewing configurations, documenting controls, and thinking through how security decisions affect real environments.

I have practiced writing and testing detection logic in Wazuh, simulating attack activity, validating alerts, and troubleshooting rule issues. I understand that detection work requires testing, tuning, and clear evidence.

My development background helps me understand applications, APIs, authentication, authorization, logging, and data flow. I’m continuing to build cloud and API security knowledge around access control, misconfiguration, and secure design.

I’m comfortable documenting risk, controls, evidence, findings, and recommendations. I care about making technical work understandable to both technical and non-technical readers.

I would focus on learning the environment, understanding the tools, asking good questions, reviewing existing processes, and helping wherever I can. My goal would be to become useful while learning from the team.

I have worked with Wazuh, Kali Linux, Hydra, VirtualBox, Linux, Windows endpoints, Nmap, Wireshark concepts, Sysmon concepts, GitHub, Next.js, TypeScript, and documentation/reporting workflows.

My focus areas include SOC analysis, SIEM monitoring, detection engineering, security architecture, risk assessment, cloud security fundamentals, API security, vulnerability management, IAM, logging strategy, and secure software development.

My strongest areas right now are hands-on lab building, Wazuh SIEM work, detection thinking, log analysis, security documentation, and risk-based architecture thinking.

My main focus is defense: detection, monitoring, hardening, architecture, and investigation. I use offensive techniques in controlled labs so I can understand what defenders should detect and how attacks appear in logs.

Yes. My full-stack development background helps me understand how web applications and APIs are built. I’m focused on authentication, authorization, input validation, logging, secure design, and common API weaknesses.

I’m building cloud security knowledge around IAM, least privilege, logging, secure configuration, misconfiguration review, and how cloud architecture decisions affect security risk.

I’m building knowledge around Windows endpoint security, event logs, Sysmon telemetry, account hygiene, Active Directory concepts, Microsoft 365 security basics, and endpoint visibility.

Yes. I’ve worked with Linux in lab environments, including SSH, authentication logs, services, basic hardening ideas, and how Linux activity can be monitored through Wazuh.

I use MITRE ATT&CK to connect attacker behavior to detection ideas. For example, SSH brute-force activity maps to brute-force behavior, which helps explain what a detection is designed to identify.

I’m building vulnerability management knowledge around identifying weaknesses, validating findings, understanding risk, prioritizing remediation, and documenting recommendations clearly.

I used Wazuh as a SIEM in my lab to collect logs, review authentication activity, validate alerts, and test custom detection logic for SSH brute-force behavior.

I use Kali Linux as a controlled attacker machine in lab scenarios. It helps me simulate activity safely so I can understand what should be detected on the defensive side.

I used Hydra to simulate SSH brute-force activity against a Linux server in my lab. That activity generated authentication failures that were reviewed and detected through Wazuh.

I use VirtualBox to build isolated lab environments with systems like Wazuh, Kali Linux, Linux servers, and Windows endpoints. It gives me a safe place to test and document security scenarios.

Programming helps me understand how applications are built, how APIs work, where security issues can appear, and how automation or dashboards can support security workflows.

Business intelligence helps me think about data, reporting, patterns, dashboards, and communicating information clearly. Those skills translate well into log analysis, alert reporting, and security documentation.

I’m continuing to improve with Wazuh, Sysmon, Windows logs, cloud security tooling, API security testing tools, vulnerability scanning, and MITRE ATT&CK mapping.

I break it down step by step. I try to understand what is happening, review logs or errors, test one thing at a time, and document what I learn along the way.

I treat it as part of the process. If something does not work, I slow down, review the error, test possible causes, fix the issue, and document what happened so I can learn from it.

I document setup steps, tools used, commands, screenshots, logs, alerts, findings, issues, fixes, and lessons learned. Good documentation helps me learn and helps others understand the work.

I try to stay structured. I focus on the most important issue first, avoid rushing blindly, and work step by step so I do not miss key details.

I can work independently when building and troubleshooting, but I also want to work with a team where I can learn from others, ask questions, and contribute to shared goals.

I’m looking for a team that values learning, clear communication, practical problem-solving, documentation, and steady growth.

I learn by building and testing. I set up labs, try scenarios, review what happens, troubleshoot problems, and document the process so I understand the work at a deeper level.

I’m continuing to improve my portfolio, build out security projects, strengthen detection engineering skills, and expand into cloud security, API security, vulnerability management, and Windows monitoring.

I’m working on going deeper with logs, detection logic, SIEM workflows, Windows telemetry, cloud security concepts, and explaining technical work clearly.

I focus on finishing small but complete pieces of work. Completing projects, documenting them, and improving them over time helps me stay consistent.

Progress motivates me. Every project teaches me something new, and I like seeing how each step builds toward a stronger understanding of security.

I measure progress by whether I can explain things more clearly, troubleshoot faster, build better projects, and understand the security impact of what I’m doing.

Yes. Cybersecurity changes constantly, so learning cannot stop. I want to keep building, training, improving, and growing into higher-level responsibilities over time.

I take the work seriously, I ask questions, I document what I learn, and I stay consistent. I do not expect to know everything, but I do expect myself to keep improving.

I enjoy the investigative side: looking at logs, understanding behavior, figuring out what happened, and connecting technical evidence to a clear explanation.

I would probably be Python. It is practical, flexible, readable, and useful across many areas. That fits how I like to work: keep things clear, solve the problem, and improve over time.

Hands-on and persistent. I learn best when I build something, test it, break it, fix it, and then explain what happened.

I want it to show that I am serious, organized, hands-on, and always improving. I want someone to see not just the result, but the way I think through the work.