Task 3

The client is a small business with around 25 to 50 employees. They don't have a centralized security monitoring system that collects, correlates, or analyzes security events across their network. While security logs are created on individual endpoints and servers, these aren't gathered centrally and stay on local devices. Because of this, the company struggles to spot unauthorized access attempts, malware infections, and other suspicious activities. These issues make it hard for them to prevent cyber-attacks from disrupting their operations.

The lack of a central view leaves security blind spots that amp up an organization's risk. Hackers keep hitting small businesses harder, seeing these firms as softer targets with fewer resources and less monitoring. If threats aren't caught early, problems can fester, causing disruptions, financial hurt, and maybe even hurting their reputation or landing them in hot water with regulators. So, the client needs a way to spot security issues fast and respond in a timely fashion to keep things running smoothly.

Our suggested plan is to configure a Wazuh Security Information and Event Management (SIEM) system into the client's setup. This means setting up a Windows Server as a hub for collecting and analyzing logs and sending alerts.

With the SIEM system, we'll gather security logs from all sorts of places like endpoints, servers, and network devices, making sure everything gets monitored in one spot. This setup gives us a bunch of useful abilities: central log management, real-time alerts, event correlation, and help with investigating incidents.

Instead of looking at separate system logs, admins can see everything happening across the whole environment. Plus, alerting rules will warn them if anything fishy shows up, allowing quick detection and response to incidents. This fix solves the client’s issue by getting rid of their fragmented monitoring. We replace it with a stronger system better at spotting threats. Not only does this improve their overall cybersecurity, but it also makes things easier for them as they grow.

Phase 1: Project Planning and Requirements Gathering (July 6 – July 10)

During this phase, the Project Manager leads a series of structured discovery meetings with organizational stakeholders, including department heads and the IT administrator, to formally document security monitoring requirements and define the scope of the SIEM deployment. Specific tasks include identifying which systems will serve as log sources (endpoints, servers, firewalls, and switches), establishing data retention requirements, and documenting any compliance obligations, such as PCI-DSS or HIPAA, that may affect the SIEM configuration. The Project Manager is responsible for producing a formal Project Charter and a Requirements Specification document that will be reviewed and signed off by stakeholders before work proceeds. The Security Analyst participates in these meetings to provide technical input on detection use cases and threat scenarios relevant to the client’s environment. This phase is estimated to take five business days and must be completed before any infrastructure work begins.

Phase 2: Infrastructure Preparation (July 13 – July 17) The Systems Administrator is responsible for provisioning and hardening the dedicated Windows Server 2022 that will host the Wazuh SIEM platform. Specific tasks in this phase include: partitioning and formatting storage volumes to accommodate at least 90 days of log data (estimated at 500 GB based on projected log volume), configuring static IP addressing and DNS entries, applying the CIS Benchmark Level 1 security baseline for Windows Server, enabling Windows Defender and host-based firewall rules, and disabling unnecessary services. The Project Manager coordinates with the client’s network administrator to open the required inbound firewall ports (514/UDP for Syslog, 1514/TCP for Wazuh agent communication, and 443/TCP for the web dashboard). The Security Analyst reviews the completed baseline configuration before the team advances to installation. All configuration settings are documented in a build record that will be retained as part of the project deliverables.

Phase 3: SIEM Installation and Configuration (July 20 – July 28)

The Systems Administrator installs and configures the Wazuh SIEM platform on the prepared Windows Server 2022 host. The installation process follows the Wazuh 4.x single-node deployment guide and includes configuring the Wazuh Manager, Wazuh Indexer (OpenSearch), and Wazuh Dashboard components. Specific configuration tasks include: creating administrative and read-only user accounts with role-based access controls, configuring the dashboard TLS certificate for secure browser access, setting log index retention policies to 90 days, and loading the default Wazuh ruleset for Windows, Linux, and network device events. The Security Analyst then customizes the base detection rules to add client-specific correlation rules targeting priority scenarios such as repeated authentication failures, privilege escalation events, and after-hours logins. The Project Manager validates that the dashboard is accessible and that baseline alerting is functional before approving progression to Phase 4.

Phase 4: Log Source Integration (July 29 – August 4)

The Systems Administrator deploys the Wazuh agent to all identified endpoints and servers in the client’s environment. This includes approximately 35 Windows 10/11 workstations, 8 Windows Server 2019/2022 instances (including domain controllers, file servers, and application servers), and 2 Linux-based servers. For network infrastructure, the Systems Administrator configures Syslog forwarding from the Cisco Meraki firewall and two managed network switches to the Wazuh Manager using UDP port 514. For each endpoint, agent deployment is performed via Group Policy Object (GPO) to push the Wazuh agent MSI installer across the domain. The Security Analyst monitors the Wazuh dashboard in real time during rollout to confirm that each agent successfully registers and begins transmitting Windows Event Logs, Security logs, and application logs. A log source inventory spreadsheet is maintained and updated as each device is confirmed active, and any connectivity issues are escalated to the Systems Administrator for resolution before proceeding.

Phase 5: Alert Development and Testing (August 5 – August 11)

The Security Analyst leads this phase, designing and testing a suite of custom detection rules and event correlation policies within the Wazuh platform. Specific alert scenarios developed include: five or more failed login attempts within a 10-minute window on any single host, successful login following a series of failures (brute force success), new administrator account creation outside of approved change windows, execution of known malicious process names or hashes, and large outbound data transfers occurring after hours. The Security Analyst conducts controlled attack simulations using a dedicated test workstation isolated from production systems, running scenarios such as Nmap port scans, failed RDP brute-force attempts, and simulated malware execution using the EICAR test file. Each alert is validated by confirming that the Wazuh dashboard generates the expected notification and that email alerting reaches the designated administrator's inbox. Results are logged in a test report, and any rules that produce false positives are tuned before sign-off.

Phase 6: User Training and Documentation (August 12 – August 17)

The Security Analyst delivers a hands-on training session for the two Systems Administrators who will be responsible for day-to-day SIEM operations. The training covers navigating the Wazuh dashboard, interpreting alert severity levels, executing the documented incident response procedures for high-priority alerts, performing log searches and threat investigations, and managing Wazuh agent health. Training takes place over two half-day sessions and includes scenario-based exercises using the test environment. Simultaneously, the Security Analyst produces the SIEM Administration and Incident Response Manual, which documents all configured alert rules, escalation procedures, agent deployment steps, and routine maintenance tasks such as index management and rule updates. The Project Manager reviews all documentation for completeness before distribution to stakeholders.

Phase 7: Final Validation and Deployment (August 18- August 20)

The Project Manager coordinates a formal User Acceptance Testing (UAT) session with organizational stakeholders. The Systems Administrator runs through a predefined test checklist that verifies: all 45 log sources are actively forwarding events, all required alert rules fire correctly against simulated attack scenarios, the Wazuh dashboard is accessible by authorized users, and the incident response manual is complete and accurate. The Security Analyst documents all test results in a Final Validation Report. Upon stakeholder sign-off on the report, the Project Manager transitions the system to operational status, issues final project documentation, and conducts a post-implementation review meeting to capture lessons learned. The completed project package, including the build record, test report, operations manual, and training records, is archived and delivered to the client.

The implementation team consists of three primary roles with clearly defined responsibilities across the project. The Project Manager oversees all phases, manages the project timeline, coordinates stakeholder communications, and is responsible for formal approvals at each phase gate. The Systems Administrator handles all hands-on technical tasks, including server provisioning, SIEM installation, agent deployment, and network configuration. The Security Analyst is responsible for detection engineering, alert rule design and testing, training delivery, and documentation authorship. Organizational stakeholders—including the client’s IT director and department managers—participate in requirements gathering, provide approvals at key milestones, and receive the final deliverables at project close.

Justification of Implementation Plan

The plan makes sense since it follows a clear path from planning to deployment, avoiding chaos along the way. Each step builds on what came before, reducing risks and ensuring all tech needs are addressed before the system goes live. Testing and training are included, too, which helps in the long run. They ensure the system works and that staff are ready to handle it once it's up and running.

Review of Other Work

Work 1: NIST Cybersecurity Framework

Aljumaiah et al. (2025) analyze cybersecurity risk and threat management in IT infrastructure using the NIST Cybersecurity Framework (CSF) as the foundational assessment model. The study’s core argument is that organizations that align their security programs to the CSF’s five functions, Identify, Protect, Detect, Respond, and Recover, achieve measurably better risk postures than those relying on ad hoc controls. A key finding of the research is that the Detect function is the most frequently underdeveloped area in small-to-medium organizations, largely because continuous monitoring capabilities require centralized tooling that many smaller firms have not yet deployed. The authors specifically recommend centralized log aggregation and real-time event correlation as foundational controls for strengthening the Detect function. This work is directly relevant to the proposed project because the client’s current environment lacks exactly the continuous monitoring capability the NIST CSF identifies as critical. Structuring the SIEM implementation around the CSF’s Detect and Respond functions provides the project with a recognized, auditable framework for measuring success (Aljumaiah et al., 2025).

Work 2: IBM Cost of a Data Breach Report

The IBM Cost of a Data Breach Report 2024 presents findings from a study of over 500 real-world data breach incidents across 17 industries and 16 countries. The report’s most directly applicable finding is that organizations with fully deployed security AI and automation tools identified and contained breaches an average of 98 days faster than those without such tools, and incurred average breach costs that were $2.2 million lower. The report further notes that the mean time to identify a breach across all organizations was 194 days, with an additional 64 days to contain it—a combined 258-day dwell time that allows attackers ample opportunity to escalate privileges, exfiltrate data, and move laterally through a network. For the client, who currently has no mechanism for correlating security events across systems, this statistic illustrates the concrete financial and operational risk of inaction. The IBM report directly supports the business case for the proposed SIEM by quantifying what poor visibility costs organizations and establishing that automated, centralized detection significantly reduces both response time and financial exposure (IBM, 2024).

Work 3: SANS Institute Security Monitoring Research

The SANS SOC Survey 2025, authored by Crowley (2025), examines the current state of Security Operations Center (SOC) capabilities across organizations of varying sizes, with particular attention to log management practices and detection effectiveness. A central finding of the survey is that organizations employing centralized log management in conjunction with a SIEM platform report a 40 percent higher rate of confirmed threat detections compared to those relying on decentralized or manual log review. The survey also identifies the most common detection gaps in under-resourced environments: lack of normalized log formats, absence of cross-system correlation, and insufficient alert tuning leading to alert fatigue. Crowley (2025) recommends that smaller organizations prioritize deploying a SIEM with pre built correlation rules as a minimum baseline for effective threat detection. This work informs two specific aspects of the proposed project: the decision to use Wazuh’s built-in ruleset as a detection baseline (addressing the pre-built correlation recommendation), and the inclusion of Phase 5 alert tuning to avoid the alert fatigue problem the survey identifies as a common implementation failure (Crowley, 2025).

Work 4: Microsoft Security Operations Best Practices

Azam (2025) presents a practical SIEM implementation study focused specifically on small business environments, examining the technical and organizational challenges that arise when deploying centralized security monitoring in resource-constrained settings. The study’s key argument is that small businesses face a unique implementation challenge: they have the same threat exposure as larger organizations but lack dedicated security staff, making it essential to select SIEM platforms that offer automated correlation and low maintenance operation. Azam (2025) recommends open source SIEM platforms as a cost-effective solution, citing Wazuh as a strong candidate due to its built-in ruleset, agent-based log collection, and active threat intelligence integration. The study also emphasizes that successful small business SIEM deployments require thorough administrator training as a critical success factor, since a SIEM that generates alerts no one can interpret provides no meaningful security benefit. This work is particularly relevant to the proposed project because it mirrors the client’s exact situation, a small business seeking enterprise-grade visibility within a constrained budget, and validates the selection of Wazuh as the deployment platform (Azam, 2025).

Each of the four reviewed works directly shaped specific decisions in this proposal. Aljumaiah et al. (2025) provided the overarching security framework, establishing that the NIST CSF’s Detect function—which requires continuous monitoring and centralized event correlation—is the capability gap most commonly found in organizations like the client. This finding justified the entire direction of the project, as the proposed SIEM implementation is specifically designed to address that gap. The IBM Cost of a Data Breach Report (IBM, 2024) provided the quantitative business justification, demonstrating that organizations without automated detection tools face breach dwell times approaching 260 days and significantly higher remediation costs. These figures were used to construct the financial risk argument in the Project Rationale section and to give the client concrete data for understanding the cost of inaction.

The SANS SOC Survey (Crowley, 2025) directly informed the technical implementation approach. The survey’s identification of alert fatigue and insufficient rule tuning as primary reasons SIEM deployments fail in smaller organizations led to the inclusion of a dedicated Phase 5 in the implementation plan, specifically focused on alert development, controlled testing, and tuning before go-live. Without this finding, alert tuning might have been treated as a minor configuration step rather than a critical phase gate. Finally, Azam (2025) validated the platform selection decision. Because the Azam study examines SIEM deployment specifically in small business environments and identifies Wazuh as a recommended open-source solution, it provided direct technical precedent for choosing Wazuh over commercial alternatives that would exceed the client’s budget. The study’s emphasis on training as a critical success factor also reinforced the decision to include a structured two-session training program in Phase 6 of the implementation plan.

The proposed project is necessary because the client currently operates with a complete absence of centralized security monitoring, leaving the organization unable to detect, correlate, or respond to security incidents in a timely manner. The client manages approximately 45 endpoints, including Windows 10/11 workstations, tablets, and remote access laptops, and eight servers running Windows Server 2019 and 2022. Each of these devices generates its own Windows Event Logs, Security logs, and application logs independently, but none of those logs are aggregated into a central system. In practice, this means that if an attacker gains a foothold on one workstation and begins moving laterally toward a domain controller, no alert will fire, no correlation will occur, and no one will know until something visibly breaks or a user reports a problem. The IT administrator, who manages the environment without a dedicated security analyst, would have to manually log into each system individually to review event logs, a process that could take days across 45 machines and is therefore almost never done proactively (Mallick et al., 2024).

The worst-case consequence of this gap is not hypothetical. According to IBM (2024), the average attacker dwell time in environments without automated detection tools is 194 days before the breach is even identified, and another 64 days to contain it. For the client, a 258-day undetected intrusion could result in the complete exfiltration of customer records, financial data, and proprietary business information, carrying the risk of regulatory penalties under applicable data protection laws, civil liability to affected customers, and reputational damage that small businesses rarely fully recover from. The urgency of this project is heightened by two specific factors. First, the client has recently expanded its workforce by approximately 15 employees over the past year, adding new endpoints and increasing the attack surface faster than any informal monitoring approach can scale. Second, the client’s industry has seen a measurable increase in phishing campaigns and ransomware targeting small businesses, as cybercriminals increasingly view under-resourced organizations as softer targets with a greater likelihood of paying ransom demands or going undetected for extended periods (Mallick et al., 2024). Without the proposed SIEM implementation, the organization remains in a position where a determined attacker has a significant advantage: unlimited time, no alerting, and no centralized record of what happened. Implementing the SIEM transforms that equation by introducing continuous, automated monitoring that narrows the window of opportunity for attackers and gives the administrative team actionable intelligence to respond before damage becomes irreversible

The critical gap in the current environment is the complete absence of centralized log management or security event monitoring. Each device generates Windows Event Logs, Security logs, system logs, and application logs locally, but these logs are stored only on the individual machine that generated them, with no aggregation, forwarding, or correlation occurring. Log retention on individual endpoints defaults to the Windows Event Log limit of approximately 20 MB per log category, meaning older events are overwritten as new ones accumulate. In a busy environment, this can result in logs being lost within days. There is no current process for proactively reviewing security logs, and log review occurs only when a specific problem is investigated after the fact. The Cisco Meraki firewall generates traffic and threat logs, but they are accessible only through the Meraki cloud dashboard and are not correlated with endpoint activity. This fragmented state means that multi-stage attack patterns, such as a phishing email leading to credential theft, followed by lateral movement and data staging, are entirely invisible to the IT administrator because the evidence is spread across a dozen separate, unconnected log sources. The proposed SIEM implementation will directly address this gap by deploying Wazuh agents to all endpoints and servers, forwarding the Meraki firewall logs via Syslog, and centralizing all event data into a single, searchable platform with real-time alerting and cross-device correlation.

The current environment’s existing infrastructure provides a solid foundation for the SIEM deployment. The Active Directory domain enables GPO-based agent deployment to all Windows endpoints, eliminating the need for manual installation on each machine. The Cisco Meraki firewall supports Syslog forwarding to external receivers, making network perimeter log integration straightforward. Microsoft Defender’s existing coverage means endpoint protection events will automatically become a log source once the Wazuh agent is deployed, enriching the SIEM with real-time malware detection data. The organization’s strategic priorities of operational reliability and data security are directly served by this implementation, as centralized monitoring will provide the visibility needed to detect and respond to threats before they cause downtime, data loss, or regulatory exposure.

Methodology

The Project Management Institute's (PMI) project management methodology will be used for the project. This structured methodology offers a systematic approach to planning, implementing, monitoring, and closing projects.

Initiation

During the Initiation phase, the Project Manager facilitates a kickoff meeting with organizational stakeholders to formally establish the project’s scope, objectives, and success criteria. For this SIEM project, the primary initiation deliverable is the Project Charter, which documents the business problem (lack of centralized security monitoring), the proposed solution (Wazuh SIEM deployment), the project boundaries (45 endpoints and 8 servers within the client’s on-premises network), the budget, and the names of key stakeholders and their roles. The Security Analyst contributes a preliminary log source inventory and a list of priority detection use cases to the charter. Formal written approval from the client’s IT Director is required before any technical work begins. This gate prevents scope creep and ensures all parties share a common understanding of what the project will and will not deliver.

Planning

The Planning phase translates the approved Project Charter into a detailed action plan. The Project Manager develops the project schedule using the seven implementation phases as milestones, assigns specific tasks to the Systems Administrator and Security Analyst, and identifies dependencies between phases. For this SIEM deployment, key planning outputs include: a detailed risk register identifying technical risks such as agent deployment failures or firewall compatibility issues; a resource allocation plan specifying the number of hours each team member will dedicate per week; a network diagram documenting the target log source architecture; and a communication plan establishing how and when status updates will be delivered to stakeholders. The Security Analyst drafts the initial detection use case catalog, listing the specific threat scenarios, such as failed authentication surges, unauthorized privilege escalation, and after-hours access, that alert rules must cover. All planning documents are reviewed by stakeholders and placed under version control before execution begins.

Execution

The Execution phase encompasses the technical implementation work described in Phases 2 through 6 of the Implementation Plan. The Systems Administrator provisions and hardens the Windows Server 2022 SIEM host, installs and configures the Wazuh platform, deploys Wazuh agents to all 45 endpoints and 8 servers via GPO, and configures Syslog forwarding from the Cisco Meraki firewall. The Security Analyst develops and tests custom detection rules covering the priority use cases identified during planning, conducts simulated attack scenarios to validate alert accuracy, and produces the SIEM Administration and Incident Response Manual. The Project Manager holds weekly status meetings during execution, tracks progress against the project schedule, and escalates any issues that threaten the timeline or scope to stakeholders. Each sub-phase concludes with a documented checkpoint review before the next phase begins, ensuring that infrastructure is verified before log sources are connected, and log sources are verified before alert rules are finalized.

Monitoring and Controlling

Throughout all phases of the project, the Project Manager conducts ongoing monitoring and controlling activities to verify that the project remains on schedule, within scope, and aligned with the approved success criteria. For this SIEM deployment, monitoring activities include weekly review of the project schedule against actual progress, tracking the log source onboarding count against the target of 53 total sources (45 endpoints, 8 servers, and the Meraki firewall), and reviewing the Security Analyst’s test results from Phase 5 to confirm alert accuracy meets the defined threshold. Any deviation from the plan, such as GPO deployment failures affecting multiple endpoints or a Wazuh indexer storage capacity issue, triggers a formal change review where the Project Manager documents the issue, assesses the impact on timeline and scope, and obtains stakeholder approval before adjusting the plan. Stakeholder progress reports are issued at the completion of each phase, ensuring continuous visibility into project status.

Closing

The Closing phase formalizes the completion of the SIEM deployment and transfers operational ownership to the client. The Project Manager coordinates the User Acceptance Testing session described in Phase 7 of the Implementation Plan, using a predefined checklist to verify that all log sources are active, all alert rules are functioning, and all documentation is complete. Once stakeholders sign the formal acceptance document, the Project Manager delivers the full project package, including the build record, Final Validation Report, SIEM Administration Manual, Standard Operating Procedures, and training completion records, to the client’s IT Director. A post-implementation review meeting is conducted to capture lessons learned and identify any enhancements the client may wish to pursue in a future project phase. The project is formally closed upon stakeholder signature and archival of all project documents.

This approach ensures transparency in the governance, risk, and accountability management process for implementation.

Goal 1: Implement NextGen Networking Solutions:

Objective 1.1: Deploy and configure the SIEM server.

Deliverable: The objective of the deliverable is to have a fully functioning SIEM server running in the Windows operating system. Include System hardening and security baselines.

Objective 1.2: Include all specified log sources.

Deliverable: Configured the collection of logs from endpoints and servers.

Goal 2: Enhance the ability to detect threats.

Objective 2.1: Create alert rules for high-impact security activity.

Deliverable: Set up alert policies.

Objective 2.2: Test detection capabilities.

Deliverable: Security testing and validation report.

Goal 3: Improve Incident Response Readiness

Objective 3.1: Train System Administrators.

Deliverable: Training completion certificates.

Objective 3.2 – To create operational documentation

Deliverable: SIEM administration and response procedures manual.

Goals, Objectives, and Deliverables Table

Success of the project will be judged by quantifiable operational and security measures.

Criteria for Success

The project will be deemed to be successful if:

· The SIEM platform is completely installed and working.

· All tagged log sources are able to send security logs to the SIEM.

· Alert rules send alerts on simulated security events.

· Administrators perform well on systems following training.

Final approval by stakeholders for implementation and documentation.

Data will be collected in the following ways:

Data will be gathered via logs generated by the system, testing reports, monitoring dashboards, training completion documents, and feedback from stakeholders. Security event simulations will also be employed to test the detection capabilities.

How data will be measured.

The following will be considered success indicators:

· Success rate of systems integrated into SIEM.

· Number of successful log transmissions received on the platform.

· Level of accuracy in alert generation for test activities.

· Incident detection and response times.

· Training completion rates.

Acceptance scores for stakeholders were collected at the end of the project.

The consolidated data will be used to take objective measures of the project's effectiveness and the organization's enhanced security monitoring abilities.