SOC services help monitor security events, assess alerts and pass them to the responsible specialists. Dev4you.lt uses Wazuh for security analysis and Zabbix for infrastructure monitoring; we review this information from our office. Specialist working hours, response actions and log retention are defined in the service plan.Discuss security monitoringExplore this service
SERVICE ASSESSMENT
Assess security-data coverage, analysis, response and log governance systematically. After providing your email, see an answer-based overview, priorities and actions; a PDF will be sent to that address. This is not an independent audit conclusion.
Businesses needing consistent assessment of security signals and clear handover to responsible people.
Provide the critical-system list, current monitoring arrangements and contacts responsible for IT and response decisions.
Receive defined monitoring sources, an assessment process, escalation procedures and reviews of outstanding actions.
A SOC service combines security technology, specialist work and an incident management process. A SIEM collects and analyses events, while a SOC defines who assesses them and what happens next. Continuous automated data collection does not itself provide round-the-clock specialist cover.
Security monitoring is useful when important events are scattered across systems, alerts have no identified recipient or an internal team cannot assess them consistently. We start by asking which events the business needs to detect and who can act on them. Collecting more logs alone is insufficient: sources must be checked and response procedures made operational.
We review the infrastructure, administrative access and critical systems. Missing inventory, responsible contacts or basic access controls become preparation tasks in the onboarding plan. The service can complement an internal IT team, with clear ownership of alert assessment and system administration.
The source list follows risk and technical feasibility. For each source, we check that the required events are generated, can be transferred and contain enough context for analysis. A missing or interrupted source must be visible as a monitoring gap.
Before connecting it, we document required permissions, collected fields and the responsible administrator. A test event verifies the full path from source to final notification. The included-system list therefore reflects a working data flow rather than simply a count of installed agents.
| Source | Possible signals | Condition for inclusion |
|---|---|---|
| Workstations | Account, system and selected file events | Compatible environment, required access and verified delivery |
| Servers | Logins, service and system security events | Named logs, permissions and a source owner |
| Network devices | Selected connection or security logs | A supported format and a tested integration |
| Other systems | Relevant events from a selected application | Separately assessed collection capability and scope |
We use Wazuh as a platform for collecting and analysing security data. Available functions depend on connected sources, configuration and service scope. Deployment identifies the signals to be assessed, and test events verify that they reach the responsible person. The verified configuration provides a baseline for subsequent changes.
Log events are assessed in relation to their source, timing and associated activity. Rules are tuned so that an alert has a clear reason for investigation and the necessary context. Recurring low-value signals are reviewed while preserving visibility of meaningful changes.
File integrity monitoring helps identify changes to selected files. Relevant directories and exclusions are chosen for the system’s purpose, allowing routine updates to be distinguished from unexpected changes. Context matters: who made the change, when, and whether approved work was taking place.
Configuration assessment and vulnerability visibility are applied to the selected environment. A signal helps prioritise further investigation or remediation, while its significance is checked against how the component is used. Reports separate the observed state, recommended action and verification of a completed change.
The Wazuh capabilities documentation describes event collection and analysis; platform features do not themselves define analyst coverage or response commitments.
An alert is first linked to its source and circumstances: whether the activity is expected, which system is affected and what further evidence is needed. We then assign priority and inform the designated contact. The notification should explain what was observed, why it matters and which decision is required.
Response actions are defined before service begins. Blocking an account, isolating a device or stopping a system can affect operations, so each action requires a specific authorisation process. Where the client or its administrator makes the decision, the handover time and subsequent responsibility are recorded.
Collection Rule
Rule Analysis
Analysis Priority
Priority Escalation
Escalation Agreed action
An illustrative workflow. Specialist coverage, handover and permitted actions are defined in the service scope.
We use a shared BAN signal-sharing solution to apply observed threat indicators across participating environments. For example, a signal about a suspicious source can be assessed and passed to agreed protection tools. An alert is not conclusive proof that every request from that source is harmful, so blocking is considered alongside exceptions, expiry and a way to reverse the restriction.
Before enabling sharing, we define which technical indicators are exchanged, who may use them and how false positives are reviewed. Publishing a client’s logs or other private data is not part of this model. Automated restrictions apply only to included systems and rules agreed in advance; their outcome needs monitoring just like the original security alert.
Data collection hours, specialist coverage and response objectives are separate terms. This makes clear when an event is recorded, when a person assesses it and how the client contact is reached. Automated monitoring does not itself establish round-the-clock human coverage.
At onboarding, we check contact availability and a backup escalation route. Where the client has its own response team, we define the information handed to it and who closes the event. Specific timing can then be set against scope, system criticality and the staffing required.
| Condition | What is documented |
|---|---|
| Collection | Included sources, delivery health and detection of gaps |
| Specialist assessment | Working hours and alert-review scope |
| Response | Priority criteria and the objective for the first action |
| Incident handling | Permitted actions, approvals and responsible operators |
| Escalation | Primary contact, backup contact and handover channel |
Each stage defines the work, your input and the result to check.
01
We collect details of critical systems, log sources and responsible people. The client identifies relevant scenarios, while we assess collection feasibility and visibility gaps.
02
We document specialist coverage, escalation and permitted response actions. The client confirms decision-makers and data-retention arrangements. We separately agree the purpose of Wazuh and Zabbix signals, the office monitoring window and any permitted BAN rule actions.
03
Selected sources are connected and rules refined for the environment. Test events verify delivery, notification context and the availability of the intended contacts.
04
Signals are assessed against system and business context before prioritisation. The responsible contact receives the decision needed, and subsequent progress is recorded.
05
We review significant events, source gaps and the usefulness of rules. Improvements are selected with the client, and scope is updated when the environment changes. We also review false positives, blocking exceptions and the value of shared signals for the particular environment.
Wazuh security signals, Zabbix infrastructure measurements and Veeam backup information answer different questions. An investigation may need visibility of system operation, security indicators and recovery options together. The connection between these services is planned around a specific scenario and available access.
During a security incident, for example, the existence of a backup alone does not determine when or what to restore: incident scope and a suitable recovery point must also be assessed. Backup administration and recovery exercises are defined within their own service scope so responsibilities remain understandable.
| Tool | Primary purpose |
|---|---|
| Wazuh | Security events and analysis |
| Zabbix | Infrastructure health and availability |
| Veeam | Backups and recovery |
At the Dev4you.lt office, we monitor information from Wazuh and Zabbix. Looking at these signals together helps relate a security alert to actual infrastructure conditions: a connection failure, a stopped service, increased load or interrupted event collection. We select relevant metrics and recipients for each client so that responsibility for each system remains clear.
Before collecting logs, we define storage location, retention, access permissions and the data to be transferred. We assess whether events contain employee or customer information and restrict access according to operational need. We also document how the client’s data is separated from other client environments. These conditions must reflect the architecture actually selected.
Reviews cover source health, significant alerts, assessment outcomes and outstanding actions. Unobserved parts of the environment are also recorded so the report does not imply coverage of the entire infrastructure. Changes to retention or data sources are reflected in the updated service description.
We provide the connected-source list, monitored scenarios, escalation contacts and authorised response procedures. Initial validation shows whether a test event reaches the responsible person with the context needed to act. Periodic review helps select rules for refinement and gaps requiring attention first.
To begin, we need the critical-system list, current monitoring arrangements and responsible IT contacts. At service closure, client records are handed over, obsolete access is removed and the defined data-retention or deletion procedure is completed.
An alert shows administrative activity at an unusual time. We first compare the source and account with approved change information; the activity may be planned work or something requiring investigation. The responsible person receives context and a specific request to confirm whether the activity is authorised.
If a restrictive action is needed, it follows the permissions established in advance. The example illustrates the path from signal to authorised action without assigning the same significance to every alert.
| Factor | Why it matters | Information we need |
|---|---|---|
| Sources and devices | Their number and integration complexity determine deployment work. | Device and log source lists. |
| Log volume and retention | Data volume and retention determine infrastructure needs. | Expected volume and desired retention. |
| Specialist work and response | Analysis hours and incident remediation have separate scopes. | Preferred hours and the response team. |
Choose the service that matches the scope of your next task.
Assess the organisation’s security and provide an evidence-based report on gaps and priorities.
Assess a specific website and resolve agreed, verified vulnerabilities.
LET’S TALK
Describe critical systems, available log sources and your current response process. We will assess collection options, analysis needs and responsibilities.
