Small business monitoring

Not every one does. A company with a handful of laptops and everything in the cloud may get more from endpoint protection and good backups. NDR earns its place when there is a local network with servers, printers, cameras or machines that cannot run an agent, or when NIS2 or a customer contract asks you to detect and report incidents.

The basics stop most attacks: multi-factor authentication on e-mail and remote access, updates applied quickly, endpoint protection on every computer, backups kept offline or immutable and tested, and a short list of who to call in an incident. Add two habits that cost nothing: an up-to-date list of your devices and accounts, and a rule that payment changes requested by e-mail are confirmed by phone. Network monitoring comes after these, once you have a local network with servers, printers or machines you cannot install anything on, or when NIS2 or a customer asks you to detect and report incidents. NetSenX fits that next step, with core detection on every plan, Free included.

Something that runs on its own, covers the devices you cannot install software on, and explains its alerts to a generalist. Start with what you already have: switch on the logs and alerts in your firewall, e-mail service and cloud accounts. Then add network detection if you have a local network with servers, printers, cameras or machines. Look for published prices, a free way to test on your own network, deployment from one sensor on a mirror port, and alerts that say in plain words what happened. NetSenX was built for this: core detection on every plan, Free included, one agent on a SPAN or TAP port per segment, and explanations on every alert. It does not replace endpoint protection or backups.

Less than for a company with a local network, and sometimes not at all: if your staff work on laptops from anywhere and use only cloud services, there is little office traffic to watch. In that case, put the money into endpoint protection on each laptop, multi-factor authentication, the sign-in and audit logs of your cloud services, and backups of cloud data. Network monitoring becomes useful again as soon as an office has shared devices: printers, a NAS, phones, cameras, a building system or a server in a cupboard. It also helps if some laptops must be watched directly: the NetSenX agent runs on Linux and macOS and sees that machine's own connections wherever it is.

Use what you already own first, then add one sensor where it sees the most. Most firewalls and routers can log blocked and allowed connections and alert on new devices; switch that on and send it to a mailbox you read. Keep a simple device list and compare it with the router's list of connected devices each month. Turn on sign-in alerts in your e-mail and cloud services. Then put one network sensor where traffic converges: a mirror port on the switch that connects to the router or the servers. The NetSenX Free plan covers 3 devices with no time limit, and one agent on a SPAN or TAP port counts as one device for a whole segment, so a small office can start at no cost.

It depends on the number of devices and the features you need. NetSenX publishes its prices: the table on this page comes from the same plan catalog the product applies, from the Free plan to Enterprise.

A device is a host running the NetSenX agent. One agent on a SPAN or TAP port monitors a whole network segment and counts as one device.

It can be, if someone has the time and skills to install, update and tune it; the licence is free, the work is not. Open-source tools for traffic logging, intrusion detection and log collection are mature and widely used. For a small company the real cost is people: a server to run them, regular updates, rules to tune, and someone who reads the output every day and understands it. If you have an administrator who enjoys that work, it is a strong option. If not, the stack tends to be installed once and then forgotten. Ask honestly who will maintain it next year. A hosted tool with published prices and plain-language alerts trades some flexibility for less upkeep; the NetSenX Free plan lets you compare on your own network.

More than most small teams expect: installation is the easy part, keeping it useful is the ongoing work. Plan for a dedicated server with enough storage for logs, regular software and rule updates, disk and performance monitoring of the stack itself, tuning to reduce noise, and time every day to read alerts. When something breaks, such as a full disk or a failed update, detection stops silently until someone notices. Document the setup so that it survives the person who built it leaving. Estimate the hours honestly and price them at your internal rate before calling the stack free. If the hours are not there, choose a tool that runs without upkeep and spend the saved time on investigating alerts instead.

Ideally yes, because each sees what the other misses, but a small company can add them one at a time. Host-based detection (HIDS, or today usually EDR) runs on a computer and sees files, processes and logins on that machine. Network-based detection (NIDS, or NDR) watches traffic and sees how devices talk to each other, including devices where no software can be installed. A host tool cannot see a printer calling out; a network tool cannot see a malicious file being opened. Start with protection on every computer, because that is the more basic need, then add network detection when you have a local network with devices beyond laptops. NetSenX is the network side; it does not replace endpoint protection.

Detection-as-code means writing your own detection rules as text files, often in a shared format such as Sigma, keeping them under version control and testing them like software. It suits security teams that hunt for specific threats and want precise control. A small company rarely needs it at the start: writing and maintaining rules takes skill and time, and a badly written rule creates noise or blind spots. You get more from a tool whose built-in detections and explanations already work, and from marking false positives as you go. If you later have a security specialist and specific needs, custom rules become worthwhile. In NetSenX, custom detection policies are available on the Enterprise plan; the core detections run on every plan.

Yes, if the alerts are written for generalists. Every NetSenX alert explains in plain language what happened and lists the network features behind its score, on every plan. Investigating and containing an incident still needs someone: your administrator, your IT provider or an incident-response firm.

Yes, if the tool is built for it. With NetSenX, your administrator installs one agent on a host connected to a SPAN or TAP port, or on the hosts you choose, and every alert is explained in plain language: what happened, on which device and why it looks unusual. What you still need is a person who reads the alerts, ideally each morning, and decides what to do, plus a deputy for holidays and the number of an incident-response firm for the serious cases. NetSenX does not run a managed service, so plan who receives alerts outside office hours: a second mailbox, your IT provider or an on-call arrangement.

A few well-chosen tools that run on their own, with alerts short enough to read each morning in a few minutes. Realistic for one person: endpoint protection with a central console, multi-factor authentication with sign-in alerts, firewall and VPN logs kept for investigation, a tested backup with a monthly restore check, and one network sensor on a mirror port. Unrealistic for one person: a SIEM that needs searches written and tuned, several overlapping consoles, or anything that requires watching dashboards all day. Decide in writing who covers holidays and who decides in an emergency. NetSenX is designed for this situation: one agent on a SPAN or TAP port per segment, plain-language alerts by e-mail on every plan, and no tuning required to start.

For most open-source sensors, yes; for NetSenX, only basic ones. Running a self-hosted sensor usually means installing and updating a Linux server, managing disk space and services, and reading configuration files. With NetSenX, installing the Linux agent is one command copied from the dashboard, pasted into a terminal and run with administrator rights; the installer checks the package signature and sets up the service. On a Mac, you install a signed package. After that, the work happens in the web dashboard: reading alerts, marking false positives, viewing the network map. If even that terminal step is unfamiliar, an IT provider can do it for you, and NetSenX support helps with macOS agents. Reading alerts needs no Linux knowledge at all.

Often yes, if nobody inside has the time or skills, but agree precisely what the MSP does and what stays with you. A managed service provider (MSP) can handle updates, endpoint protection, backups and monitoring for many clients at a cost a small company could not match alone. Ask in writing: which tools they use, who reads alerts and when, what happens at night and at weekends, how quickly they respond, and what evidence you receive each month or quarter. Check how they protect their own remote-access tools, because those reach your network. Keep ownership of your accounts and data. Network detection can be part of the arrangement: an MSP can run NetSenX for you, with each client kept in its own tenant.

A SPAN port (switch port analyser, also called port mirroring) is a switch setting that copies the traffic of other ports to one port, where a sensor can watch it. Most managed switches support it, usually in the web interface under a name such as mirroring or monitor session; unmanaged switches do not. A network TAP is a small device that does the same on a cable, for places without a managed switch or where you want a copy that cannot drop packets under load. Mirror the uplink to your router or the ports of your servers to see the most. With NetSenX, one agent on a SPAN or TAP port watches a whole segment and counts as one device.

For watching a whole segment, yes, one of the two; for watching specific servers, no, because an agent on each server sees its own traffic. A SPAN port is a mirror setting on a managed switch and costs nothing if your switch supports it. A TAP is a small hardware device on a cable, useful when the switch is unmanaged or when you want a copy that never drops packets. Place it where traffic converges, such as the link between your main switch and the router, or the ports of your servers. With NetSenX, one agent on a host connected to a SPAN or TAP port counts as one device for the whole segment, and this is also the way to get packet capture for TLS fingerprinting and the crypto inventory.

Installing one agent takes a few minutes; the longer step is usually setting up a mirror port on your switch, if you have never done it. On Linux, you copy one command from the dashboard, run it on the host, and the device appears in the list within a couple of minutes. On a Mac, you run a signed installer; macOS agents are set up together with NetSenX support. To watch a whole segment, configure a SPAN port in your switch's settings and connect the agent's host to it, or insert a TAP on the uplink cable. Devices then start to appear on the network map as they send traffic, and alerts begin as soon as traffic flows. Plan a few weeks of attention afterwards while you mark what is normal.

Yes. A sensor on a mirror port sees the traffic of every device on the segment, whatever operating system it runs, because it watches the network rather than the computer. That covers office PCs, Macs, Linux servers, phones, printers and machines in one place. The operating system matters only for the device where the sensor itself is installed. For NetSenX, the agent runs on Linux and macOS, so the sensor host should be one of those; the devices it watches can be anything. If you want to watch specific machines directly instead of through a mirror port, those machines need to run Linux or macOS. Endpoint protection on each computer remains a separate need, specific to each operating system.

Passive monitoring on a mirror port does not slow the network, because the sensor only receives a copy of the traffic and is not in the path. The switch makes the copy itself. Two things to check: that the switch can mirror the ports you choose without overloading the monitor port, and that the host running the sensor has enough capacity for the traffic volume. Inline products that sit in the traffic path, such as some intrusion prevention systems, can add delay or become a point of failure; NetSenX is not one of them. If you install the NetSenX agent directly on a busy server instead, watch its resource use for the first days and start with a less critical host.

It depends on the product, and you should ask. Some sensors record full traffic for later analysis; others keep only connection records. NetSenX analyses connection metadata and a few protocol fields: timing, volume, source and destination, ports, DNS answers and, where the agent captures packets, the unencrypted parts of the TLS handshake. It never decrypts traffic, so the content of encrypted sessions, such as e-mails, files or what someone typed into a website, stays unreadable. That is enough to see behaviour like beaconing, scanning, lateral movement and unusual uploads, and it limits how much personal data the tool handles. Network metadata can still relate to people, so check it with your data protection officer and read the vendor's data processing agreement.

Yes, and it is a sensible way to begin, as long as you write down what is not covered yet. Choose the systems whose compromise would hurt most: the file server, the finance and ERP servers, the backup system, the domain controller, and the link to the internet. Mirror the switch ports those systems use, or install the agent directly on them. You will see who connects to them, which is often where an intrusion shows first. Then expand segment by segment. Be honest in any report to management, an insurer or a customer: monitoring the servers is not monitoring the whole network. The NetSenX Free plan covers 3 devices, which is enough to start with your most critical systems.

Baselining means learning what normal looks like for each device: whom it talks to, on which ports, how much data and at what times, so that a deviation stands out. It takes as long as your business takes to show its normal rhythm: daily patterns appear within days, weekly ones within weeks, and monthly jobs such as payroll or reporting only after a month or more. During that time, expect more alerts and confirm what is normal; your decisions speed it up. A baseline is never finished, because networks change: new servers, new software, new suppliers. NetSenX raises alerts on clear patterns from the start and improves its comparisons with each host's own history as it learns your network.

Read it, check it against what you know, and decide within the hour whether it is harmless, needs watching or needs action. First, identify the device and its owner. Second, ask whether there is an innocent explanation: a backup, an update, a new supplier, a colleague's planned work. Third, if not, contain before you investigate: disconnect the device from the network, but do not switch it off, because memory and logs help investigators. Reset passwords the device may have used, from another computer. Call your IT provider or an incident-response firm if you are unsure. Note what you did and when. NetSenX alerts say what happened, on which host and why, and the audit log records your decisions.

Whoever you arrange: software can detect at night, but a person must decide to act. Most small companies choose one of three options. Alerts go to two people by e-mail and phone notifications, with a simple rule of what is urgent enough to act on at night. An IT provider or MSP receives alerts outside office hours under a written agreement. Or a managed detection and response service watches around the clock for a fee. Whichever you choose, write down who can disconnect a device or the internet line, and test the arrangement once. NetSenX detects at every hour and sends alerts by e-mail on every plan, and by webhook from the Pro plan, but nobody at NetSenX watches them for you.

Nobody, unless you arrange it before the holiday starts. Decide who receives alerts while the administrator is away: a colleague, the managing director or your IT provider. Give that person a one-page note: how to read an alert, which ones to escalate, how to disconnect a computer, and whom to call. Make sure they can reach the accounts they need, with multi-factor authentication, and that the administrator's own access is not shared. Check before leaving that backups are working and updates are current. Detection itself does not take holidays: NetSenX keeps watching and sends alerts by e-mail on every plan, so adding the deputy as a recipient is often the only change needed.

Whoever is on the alert list, so check that list before the office closes. Add a second recipient who will actually read e-mail during the break, and agree what counts as urgent: an alert on the file server or the backup system, for example, versus a printer calling an update server. Write the phone number of your IT provider or an incident-response firm on the same note, and check that they are reachable on the dates you close. Confirm backups the week before and keep one copy offline. Long breaks are a known risk because fewer people notice problems. NetSenX keeps detecting while you are away, with alerts by e-mail on every plan and by webhook from the Pro plan.

Because fewer people are watching, so attackers have more time before anyone reacts. Over holidays and long weekends, offices are empty, IT staff are away and responses are slower, which gives an intruder hours or days to spread and encrypt data before discovery. CISA and the FBI warned about this pattern in their joint advisory on ransomware awareness for holidays and weekends, published in August 2021. The defence is preparation rather than staying at work: alerts that reach someone who is on call, a written list of who can disconnect what, recent backups with an offline copy, and multi-factor authentication on remote access. Network detection helps by keeping watch: NetSenX alerts at any hour, but someone still has to read them.

Plan it like any critical period: freeze risky changes, check backups, tighten payment controls and make sure someone watches the finance systems. In the weeks before, apply pending updates and then avoid large changes. Test a restore of the accounting and ERP data. Remind the finance team that any change of bank details, even from a known supplier or the CEO, is confirmed by phone on a known number. Restrict remote access to the finance servers to the people who need it. Agree who receives alerts during the close, including evenings. On the network side, NetSenX shows unusual connections to and from the finance servers, such as new sessions from other workstations or large uploads at night, on every plan.

Put a sensor in each office and send all alerts to the same people and the same dashboard. A second site usually has its own switch and internet line, so traffic there never passes the first office's sensor. One agent on a mirror port at the new site covers its local segment; staff at head office read its alerts alongside the others. Make sure the link between the sites, often a VPN, is also watched, because that is how an infection spreads from one site to the other. Write down who is the local contact at the second site for physical tasks such as unplugging a device. With NetSenX, one agent on a SPAN or TAP port per site counts as one device, and all sites appear in one account.

Usually at least two: one agent on a SPAN or TAP port at each site, because each site has its own local traffic. A device is a host running the NetSenX agent, and one agent on a mirror port counts as one device for the whole segment it watches. If a site has several separated segments, such as office, guest Wi-Fi and production, each segment you want to watch needs its own mirror point or agent. Add any servers you want to watch directly with their own agent. A typical two-site company therefore needs only a few devices, which may fit the Free plan's 3 devices or the Starter plan's 10 devices at €49 per month.

Yes, if the site-to-site VPN lets every device at the branch reach every server at head office, which is common. A permanent VPN between offices joins them into one network, so an infected PC at the branch can scan and log in to head-office servers as if it were on the same floor. Limit what crosses the VPN: allow only the services the branch needs, such as the file server or the ERP, and only from the devices that need them. Use separate administrator accounts for each site. Watch the traffic that crosses the link. NetSenX flags scanning and lateral movement on every plan; with a sensor at each site you see an infection spreading from one to the other.

Yes. Card terminals and tills should sit on their own network segment, with only the connections they need allowed, so that an infected office PC cannot reach them. Separation limits the damage of one compromised computer and is also how the card payment standard (PCI DSS) lets a business reduce the part of its network that falls under its requirements. In practice, use a separate VLAN or a separate router port for the payment devices, block traffic from the office network to that segment, and allow only the connections to the payment provider. Ask your payment provider and installer how they recommend doing it. Then verify that the separation holds, because configurations drift over time.

Test it from an office computer, and then watch the traffic to see whether anything crosses that should not. A simple test: from an office PC, try to reach a till's address, for example with a ping or a connection to its management port, and confirm that it fails. Repeat after any change to the network or the router. Testing shows the rule works at that moment; watching shows whether anything uses a path you did not know about. A network sensor on a mirror port that sees both segments shows every connection between them. NetSenX lists who talks to whom on the network map on every plan and flags scanning or new sessions toward the tills as alerts.

The malware can try to spread to the tills, steal card data or lock them, and the shop may stop taking payments. Attackers who get into an office computer through phishing usually look around the network next. If the tills and payment devices are on the same flat network, they are within reach, often with older software and weak passwords. The consequences range from lost sales while tills are down to a card data breach, with notifications to your payment provider and possibly customers. Prevent it by separating the payment network, keeping tills updated and changing default passwords. NetSenX helps you see it in time: scanning and lateral movement from an office PC toward the tills raise alerts on every plan.

It can be: consumer routers often lack regular updates, separate networks and useful logs, and some are left with default passwords. For a small office, check four things. Is the firmware still updated by the manufacturer, and is it current? Is the administrator password changed and remote administration from the internet switched off? Can it run separate networks, so guests, payment devices and office PCs are kept apart? Does it keep logs you can read? If the answer to two or more is no, a small-business router or firewall is a cheap upgrade. Also look for forgotten equipment, such as a 4G router a supplier left in a cabinet. NetSenX's network map shows devices that appear on the LAN, on every plan.

Find them, decide whether each one is needed, and either update and document it or switch it off and wipe it. Old servers, forgotten NAS boxes, former employees' laptops and test machines are common entry points, because nobody updates them and their passwords are old. Walk through the office and compare what you find with your device list and the router's list of connected devices. For each device, name an owner. If nobody claims it, disconnect it for a few weeks and see whether anyone complains, then wipe it securely. Remove its accounts and firewall rules too. NetSenX's network map, on every plan, shows devices that send traffic, with first and last seen, which helps find the ones nobody remembers.

Expect questions about access control, updates, backups, incident handling and evidence, especially from customers that fall under NIS2, which asks them to manage security in their supply chain. Typical questions: do you use multi-factor authentication, how quickly do you apply updates, do you test backups, who handles incidents and how fast will you tell us, do you monitor your network, where is our data stored, and can you show evidence. Answer truthfully: a clear no with a plan is better than a yes you cannot prove. Keep a short security description and the evidence behind it ready. NetSenX can supply part of that evidence: detection records, the audit log and, from the Starter plan, PDF reports.

Keep a few records consistently rather than many records occasionally: what you have, what you changed, what happened and what you did. A device and account list with owners. A change log for important systems. Backup and restore-test dates. A simple incident log with date, what was seen, decisions and who made them. Store them where an attacker who gets into one computer cannot delete them, and make sure every device has the correct time, because timelines depend on it. These records answer the questions of insurers, auditors, customers and, under NIS2, authorities. NetSenX keeps part of this for you: alerts with timestamps and explanations, alert history per plan, and an audit log of decisions and changes on every plan.