Audyt serwerów — hardening Windows i Linux zgodny z CIS Benchmark, NIS2 i ISO 27001
Serwer fizyczny lub wirtualny jest najczęstszym punktem wejścia w infrastrukturę firmy — typowy atak ransomware zaczyna się od podatnego serwera SMB, niezałatanego Exchange, otwartego portu RDP bez MFA lub źle skonfigurowanego usługi SQL Server z weak password. Audyt serwerów to systematyczna weryfikacja konfiguracji systemu operacyjnego, usług sieciowych, kont użytkowników, polityk haseł, rejestrów audytu i poziomu zabezpieczeń względem branżowych benchmarków (CIS Controls v8, CIS Benchmarks dla Windows Server 2022 i wybranych dystrybucji Linux, DISA STIG, NIST SP 800-53). Nie sprowadza się do uruchomienia jednego skanera podatności — to pełna inspekcja konfiguracji, kontroli dostępu, hardening hypervisora i obrazów referencyjnych, ślad audytowy zmian, plan remediacji z priorytetami i powtórny audyt po wdrożeniu poprawek.
Virtline realizuje audyty serwerów Windows Server 2016/2019/2022/2025 i Linux (RHEL 8/9, Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12, SUSE Linux Enterprise Server, Rocky Linux, AlmaLinux) dla firm od 10 do 1000+ hostów. Posługujemy się otwartymi narzędziami (OpenSCAP z profilami SCAP Security Guide, Lynis, CIS-CAT Lite, chkrootkit, rkhunter, auditd, AIDE) oraz komercyjnymi skanerami klasy enterprise (Tenable Nessus Professional, Qualys VMDR, Rapid7 InsightVM, Microsoft Defender for Servers, Microsoft Defender Vulnerability Management). Wszystkie ustalenia dokumentujemy w raporcie technicznym z mapowaniem na ISO/IEC 27001:2023 Annex A.8 (Technological controls), NIS2 art. 21 ust. 2 lit. e, f, i oraz CIS Controls v8 IG1/IG2/IG3. Posiadamy certyfikat ISO/IEC 27001:2023 wydany przez TÜV NORD — nr AC090 121/2469/6137/2026, ważny do 02.2029.
Co obejmuje audyt serwerów w Virtline
Każdy audyt obejmuje 10 obszarów technicznych — każdy z udokumentowaną listą kontrolną i mapowaniem na CIS Controls v8 oraz ISO 27001 Annex A.8:
Hardening systemu operacyjnego — CIS Benchmark Level 1/2 — weryfikacja konfiguracji względem CIS Microsoft Windows Server 2022 Benchmark v3.0 (Level 1 dla każdego hosta, Level 2 dla DC i hostów w DMZ) lub CIS Red Hat Enterprise Linux 9 Benchmark v2.0, CIS Ubuntu Linux 22.04 LTS Benchmark v2.0. Sprawdzamy ponad 350 kontroli na Windows Server (Account Policies, Local Policies, Event Log, System Services, Registry, File System) i ponad 250 na Linux (Initial Setup, Services, Network Configuration, Logging, Access Control, System Maintenance). Wynik: raport z CIS Compliance Score per host (typowo nowe systemy bez hardening osiągają 30-45%, po remediacji powinny 85-95% Level 1).
Inwentaryzacja oprogramowania i patch level — pełna lista zainstalowanego software (Windows: wmic product, Get-WmiObject Win32_Product, Get-AppxPackage; Linux: rpm -qa, dpkg -l, snap list, pip3 list, npm list -g). Patch level — Windows Update history (wmic qfe, Get-HotFix), Linux package version vs distribution security advisories (yum updateinfo list security, apt list –upgradable, dnf updateinfo info), kernel version i checking dla pending reboot. Aplikacje 3rd party (Java, Adobe, browsers) i ich CVE exposure. Wynik: lista hotfix do zainstalowania, EOL software do migracji (Windows Server 2012/R2 EOL 10/2023, Windows Server 2016 mainstream EOL 1/2022 — extended do 1/2027, CentOS 7 EOL 6/2024, Ubuntu 18.04 EOL 5/2023).
Analiza podatności CVE — skan Nessus / Qualys / OpenVAS — autoryzowany skan z credentialami (root/Administrator) dający 5-10x więcej findings niż unauthenticated scan. Tenable Nessus Professional z plugin set aktualizowanym daily, mapowanie na CVE i CVSS v3.1 (Critical 9.0-10.0, High 7.0-8.9, Medium 4.0-6.9), CISA KEV Catalog (Known Exploited Vulnerabilities — priority dla patch). Identyfikacja end-of-life software, weak crypto (SSLv3, TLS 1.0/1.1, weak ciphers RC4/DES), default credentials, missing security patches dla critical CVE (Log4Shell CVE-2021-44228, ProxyShell CVE-2021-34473, EternalBlue MS17-010, BlueKeep CVE-2019-0708, PrintNightmare CVE-2021-34527). Wynik: lista CVE per host z priorytetami remediation.
Kontrola dostępu — konta lokalne, group membership, RBAC — Windows: Get-LocalUser, Get-LocalGroupMember Administrators, Get-ADUser dla domain-joined hosts, check for stale accounts (lastlogon > 90 dni), service accounts z plain text passwords w skryptach, scheduled tasks running jako SYSTEM lub Domain Admin. Linux: /etc/passwd, /etc/shadow, /etc/sudoers (audyt sudo rules — NOPASSWD entries to red flag), getent passwd, last command history, SSH authorized_keys. Identyfikacja excessive privilege (typowo 30-50% kont produkcyjnych ma więcej praw niż wymagane), shared accounts (zakazane przez ISO 27001 A.8.2), accounts bez password expiry dla interactive logon. Wynik: lista konta do dezaktywacji, role redesign rekomendacje.
Audyt rejestrowania i monitoringu — Event Log, syslog, auditd — Windows: Get-WinEvent dla Security Log, Application Log, System Log, Sysmon (Microsoft Sysinternals), Audit Policy (auditpol /get /category:*) — minimum: Account Logon, Account Management, Logon/Logoff, Object Access dla critical files, Policy Change, Privilege Use, Process Creation (Event ID 4688), Process Termination, PowerShell Script Block Logging (Event ID 4104). Linux: /var/log/auth.log, /var/log/syslog, /var/log/audit/audit.log (audit daemon — auditd z regułami dla syscalls execve, unlinkat, write do /etc, /bin, /sbin), rsyslog forwarding do central SIEM. Retention 90-365 dni lokalnie, indefinitely w SIEM dla regulowanych. Wynik: gaps w audit policy, missing forwarding to SIEM, logs in danger of overwrite.
Bezpieczeństwo sieciowe serwera — porty, firewall, IPSec — Windows: netstat -an, Get-NetTCPConnection, Get-NetFirewallRule (Windows Defender Firewall with Advanced Security), IPsec policies (Get-NetIPsecRule). Linux: ss -tlnp, netstat -tlnp, iptables -L -n -v, nft list ruleset, ufw status verbose, firewalld –list-all. Identyfikacja unnecessary services exposed (typowy serwer ma 8-15 nasłuchujących portów — przy hardening powinno 3-5), default ports dla wrażliwych usług (RDP 3389, SSH 22, WinRM 5985/5986, SQL 1433, MySQL 3306, MongoDB 27017 — często otwarte na internet), SMBv1 enabled (CRITICAL — disable), NTLM authentication permitted (preferowane Kerberos-only). Wynik: lista portów do zamknięcia, firewall rules do dodania, network segmentation rekomendacje.
Konfiguracja kryptograficzna — TLS, IPSec, dyski — TLS version (rejestruj nasłuchujące porty HTTPS i sprawdź wersję — TLS 1.0/1.1 disabled, TLS 1.2 minimum, TLS 1.3 preferred), cipher suites (no RC4, no 3DES, no NULL, no EXPORT), certificate validity (expiry < 30 dni — red flag, self-signed certs dla production — red flag chyba że internal CA). Windows: SChannel registry keys (Get-TlsCipherSuite, IISCrypto), .NET Strong Cryptography. Linux: /etc/ssh/sshd_config (Ciphers, MACs, KexAlgorithms — disable diffie-hellman-group1-sha1, hmac-md5, arcfour), /etc/ssl/openssl.cnf. Disk encryption: Windows BitLocker (Get-BitLockerVolume — preferred AES-XTS-256 z TPM 2.0), Linux LUKS (cryptsetup status). Wynik: TLS hardening commands, cipher whitelist.
Backup i recovery — weryfikacja procedur — czy host jest w scope backup (Veeam Backup & Replication, Veritas NetBackup, Microsoft Azure Backup, Rubrik), kiedy ostatnio udany backup (Veeam SureBackup raporty), kiedy ostatnio test restore (typowo organizacje nie testują 6-12 miesięcy — krytyczny gap), retention zgodny z polityką (typowo daily 30 dni, weekly 12 tygodni, monthly 12 miesięcy, yearly 7 lat), immutable backup dla ransomware protection (Veeam Hardened Repository, S3 Object Lock, Azure Immutable Blob Storage). Snapshot policy dla VM hostów (snapshots NIE są backupem — max 24-72 h). Application-consistent backup dla DB workloads (SQL Server VSS, Oracle RMAN). Wynik: gaps w backup coverage, restore test schedule.
Hardening hypervisora i obrazów — dla hostów wirtualnych: audyt hypervisora (VMware ESXi 8 — lockdown mode, vSphere Security Configuration Guide compliance, ESXi shell access disabled, host certificate not self-signed; Hyper-V Server Core lub Hyper-V w pełnym Windows Server z baseline GPO, Credential Guard enabled, HVCI enabled; Proxmox VE — 2FA dla web UI, dedicated management VLAN, firewall PVE-side). Golden images: czy template VMs są patched (typowo template aktualizowany 2-4x rocznie — Sysprep dla Windows, cloud-init dla Linux), antimalware preinstalled (Microsoft Defender for Servers, Trellix EDR, SentinelOne), monitoring agents (Zabbix Agent 2, Prometheus node_exporter, Wazuh agent), domain join procedure documented. Wynik: hypervisor hardening gaps, template refresh schedule.
Ślad audytowy i compliance mapping — mapowanie ustaleń na ISO/IEC 27001:2023 Annex A.8 (A.8.2 Privileged access rights, A.8.5 Secure authentication, A.8.8 Management of technical vulnerabilities, A.8.9 Configuration management, A.8.16 Monitoring activities, A.8.22 Segregation of networks, A.8.24 Use of cryptography), NIS2 art. 21 ust. 2 lit. e (bezpieczeństwo nabywania, rozwoju i utrzymania), lit. f (polityki dotyczące oceny skuteczności środków zarządzania ryzykiem), lit. i (zasoby ludzkie, polityki kontroli dostępu), CIS Controls v8 (CIS 4 Secure Configuration, CIS 7 Continuous Vulnerability Management, CIS 12 Network Infrastructure Management). Każde finding ma przypisany konkretny kontrol z CIS Controls + odpowiadający annex z ISO + powiązanie z DORA art. 9 (ICT risk management) lub NIS2 dla podmiotów objętych. Wynik: gotowy artefakt audytowy dla audytora KSC / TÜV / KNF / NFZ.
Korzyści z regularnego audytu serwerów
Audyt serwerów to nie czyste compliance — przekłada się na mierzalne ograniczenie ryzyka incydentów, krótszy mean time to recover i niższe stawki ubezpieczenia cyber:
Redukcja powierzchni ataku o 60-80% — typowy serwer bez hardening ma 8-15 nasłuchujących portów (SMB, RPC, WinRM, RDP, IIS, SQL, dodatkowe usługi pozostałe po deinstalacji), 30-60% kont z nadmiernymi uprawnieniami, SMBv1 wciąż enabled na 20-30% serwerów według raportów Microsoft 2024. Po hardening — 3-5 portów otwartych, role-based access z least privilege, SMBv1 disabled, RDP tylko z bastion z MFA. Realny wynik: u jednego z naszych klientów (e-commerce, 80 hostów Windows) po hardening liczba alertów Defender for Servers spadła z 230/miesiąc do 18/miesiąc.
NIS2 art. 21 ust. 2 lit. e, f, i — gotowy artefakt audytowy — dyrektywa NIS2 wymaga: lit. e (bezpieczeństwo procesu nabywania i utrzymania systemów ICT — w tym hardening serwerów), lit. f (polityki oceny skuteczności środków zarządzania ryzykiem — audyty cykliczne), lit. i (kontrola dostępu, MFA). Nasz raport audytu to gotowy dowód compliance dla audytora KSC NIS2 — z konkretnym mapowaniem finding → artykuł NIS2 + ISO 27001 Annex + CIS Control. Bez sformalizowanego audytu trudno wykazać due diligence w przypadku incydentu (obowiązek raportowania w 24h do CSIRT NASK).
Niższe stawki ubezpieczenia cyber 15-30% — ubezpieczyciele cyber (PZU, Warta, AIG, Beazley, Lloyd’s) wymagają w underwriting questionnaire: aktualny audyt bezpieczeństwa < 12 miesięcy, MFA dla privileged access, EDR/XDR na endpoint, regular patching, immutable backup. Polisa wykluczy ransomware coverage dla firm bez tych kontroli. Audyt z planem remediacji jest dowodem dla underwriter — typowa redukcja premium 15-30% per year po wdrożeniu rekomendacji. Realny wynik: u jednego z klientów (50M PLN obrót, 60 hostów) przejście z premium 85k PLN na 60k PLN po roku od wdrożenia rekomendacji audytu.
Krótszy MTTR podczas incydentu — z dni do godzin — audyt dostarcza kompletną inwentaryzację (każdy host z konfiguracją, rolami, software, ostatnim patchem, owner, application dependencies). Podczas incydentu (np. zero-day patch dla Exchange) zespół wie natychmiast: które hosty są podatne, gdzie ich zlokalizować, jakie aplikacje od nich zależą, kogo poinformować o downtime. Bez aktualnej inwentaryzacji incident response traci 4-12 godzin na samą identyfikację scope — krytyczne dla ransomware response (typowo containment trwa 4-12 godzin, każda dodatkowa godzina to GB szyfrowanych danych).
Zgodność z ISO 27001 Annex A.8 — gotowe dowody — audyt mapowany na konkretne kontrole ISO/IEC 27001:2023 Annex A.8: A.8.8 (vulnerability management), A.8.9 (configuration management — CIS Benchmark compliance jako baseline), A.8.16 (monitoring activities — Event Log + Sysmon + SIEM forwarding), A.8.22 (segregation of networks — firewall rules audit), A.8.24 (use of cryptography — TLS audit). Dla firm posiadających ISO 27001 audyt jest dowodem dla audytora certyfikującego (TÜV NORD, BSI, DEKRA, BDO) — bez sformalizowanego audytu ciężko obronić te kontrole na audycie surveillance.
Identyfikacja shadow IT i orphaned servers — w typowej organizacji 10-20% hostów to nieudokumentowane (legacy hosty po byłych pracownikach, test/dev serwery zostawione w produkcji, hosty z byłych projektów). Audyt wykrywa je przez network scan (Nmap z host discovery, port scan), DNS enumeration, Active Directory accounts inactive > 90 dni, vCenter inventory analysis. Wynik: lista hostów do dezaktywacji (zaoszczędzone licencje OS, zwolnione zasoby na hypervisor, zmniejszona powierzchnia ataku). Realnie: u jednego z klientów (200 hostów wirtualnych) audyt wykrył 32 orphaned VMs — dezaktywacja zwolniła 1,2 TB datastore.
Dane do prioritization patch management — audyt z CVSS + CISA KEV mapping pozwala patch managementowi działać priorytetowo: krytyczne CVE z aktywną eksploatacją (KEV) — patch w 48-72h, High z PoC public — 2 tygodnie, Medium/Low — następne maintenance window. Bez priorytyzacji organizacje patchują równomiernie wszystko — w efekcie krytyczne CVE też czekają 30 dni na patch cycle. Realne dane Microsoft Security Response Center: 75% successful breaches w 2024 wykorzystywało CVE z patchem dostępnym > 30 dni.
Baseline dla continuous compliance monitoring — wynik audytu (CIS Compliance Score per host, lista findings, configuration baseline) staje się referencją dla automatycznego monitoringu. Microsoft Defender for Servers z Security Recommendations, Azure Arc dla on-prem hosts, Microsoft Defender Vulnerability Management dla continuous scan. Linux: OpenSCAP scheduled scans + central reporting, Wazuh dla compliance dashboards. Wynik: każde odchylenie od baseline (nowy port otwarty, nowy admin user, missing patch > 30 dni) generuje alert — proactive zamiast reactive.
Modele audytu serwerów — od point-in-time po continuous
Dobieramy zakres i częstotliwość do dojrzałości IT, rozmiaru infrastruktury i wymogów regulacyjnych:
Point-in-time audit jednorazowy — typowo 30-100 hostów, 2-4 tygodnie — pełna inspekcja wszystkich serwerów w jednym oknie (typowo kwartał). Zakres: 10 obszarów z scope, raport techniczny 60-120 stron + executive summary 8-15 stron, plan remediacji z priorytetami P1 (critical, do patch w 30 dni) / P2 (high, 60 dni) / P3 (medium, 90 dni) / P4 (low, 180 dni). Najczęstszy model dla organizacji rozpoczynających compliance journey lub przed certyfikacją ISO 27001. Powtarzalność: raz do roku lub raz na 2 lata, czasem ad-hoc przed M&A due diligence.
Audyt cykliczny kwartalny — recurring scope — co kwartał audyt podzbioru hostów (rotacyjnie wszystkie hosty w cyklu rocznym — 25% kwartalnie) lub audyt każdy kwartał całej critical infrastructure (DC, hosty z DMZ, hosty z PII data). Zakres mniejszy niż point-in-time (focus na zmiany od ostatniego audytu — configuration drift, nowe podatności CVE, nowe hosty), raport 20-40 stron. Wynik: continuous improvement compliance score (typowo 30-45% → 90%+ w 12-18 miesięcy), dane trendowe dla zarządu (KPI: avg time-to-patch dla critical CVE, % hostów z CIS L1 compliance ≥ 85%).
Continuous compliance monitoring — automated baseline check — zamiast okresowych audytów, automated daily/weekly check przeciwko baseline (Microsoft Defender for Cloud Security Recommendations, Tenable Security Center, Wazuh, OpenSCAP z central reporting). Każde odchylenie generuje alert, dashboards real-time. Audyt manualny tylko 1-2x rocznie dla validation i deep dive na obszary nieobsługiwane przez automated tools (procedural controls, documentation review, interviews). Najwyższa dojrzałość — wymagana dla DORA art. 9 (ICT risk management framework), KNF Rekomendacja D dla banków.
Audyt przedwdrożeniowy — nowy serwer / nowa aplikacja — przed dopuszczeniem nowego hosta do produkcji (zgodnie z change management i ISO 27001 A.8.9 Configuration management, A.8.32 Change management): scan hardening przeciwko CIS Benchmark, scan podatności Nessus, validation konfiguracji firewall + IPSec + TLS, weryfikacja włączonego auditingu i forwardingu do SIEM, kompletność dokumentacji (host owner, application owner, business criticality tier, recovery tier). Wynik: GO/NO-GO decision dla production deployment. Eliminuje przypadek deployment niezgodnego z baseline (typowo 30-40% serwerów wdrażanych bez tej kontroli ma compliance score < 60% Level 1).
Audyt poincydentalny — root cause analysis — po incydencie bezpieczeństwa (ransomware, data breach, lateral movement detection) — pełna inspekcja hostów dotkniętych incydentem i hostów sąsiadujących w segmentach sieci. Cel: identyfikacja initial access vector (typowo: phishing → endpoint compromise → privilege escalation → lateral movement → domain takeover), persistence mechanisms (scheduled tasks, services, WMI subscriptions, registry run keys), exfiltration channels. Forensic timeline z artifacts (Event Logs, $MFT, $LogFile, Prefetch, ShimCache, AmCache dla Windows; audit.log, bash_history, last, lastb dla Linux). Wynik: incident report dla zarządu + CSIRT NASK (NIS2 raportowanie 24h), lessons learned dla preventive controls.
Audyt segmentacyjny — hosty w DMZ vs LAN vs management — różny scope dla różnych zone trust: DMZ hosts (web servers, mail gateway, VPN concentrator) — najwyższy poziom hardening (CIS Benchmark Level 2 + Site-Specific dla VMware Security Configuration Guide), Application Layer Gateway, minimum exposed services. Internal LAN production servers — CIS Level 1 obligatory, EDR mandatory. Management network hosts (Domain Controllers, jump boxes, monitoring servers) — Tier 0 / Tier 1 model Microsoft Privileged Access, Credential Guard, PAW (Privileged Access Workstations), no internet access. Każda zone z osobnym raportem i osobnymi priorytetami remediation.
Narzędzia audytu i benchmarki branżowe
Pracujemy z otwartymi i komercyjnymi narzędziami klasy enterprise — dobierając stack do scope audytu, dystrybucji systemów i wymogów raportowych:
CIS Benchmarks — branżowy standard hardening — Center for Internet Security publikuje benchmarki konfiguracji bezpieczeństwa dla każdego major OS i większości aplikacji enterprise: CIS Microsoft Windows Server 2022 Benchmark v3.0.0 (1/2025), CIS Microsoft Windows Server 2019 Benchmark v3.0.1, CIS Red Hat Enterprise Linux 9 Benchmark v2.0.0 (10/2024), CIS Ubuntu Linux 22.04 LTS Benchmark v2.0.0, CIS Debian Linux 12 Benchmark v1.1.0, CIS Microsoft SQL Server 2022 Benchmark, CIS Apache HTTP Server 2.4 Benchmark, CIS PostgreSQL 16 Benchmark, CIS Docker Benchmark, CIS Kubernetes Benchmark. Level 1 (essential, no service disruption) vs Level 2 (advanced, possible compatibility impact). Format: każda kontrola z description, rationale, audit procedure (manual + automated), remediation, references. Darmowe dla download (membership SecureSuite dla automated tooling).
OpenSCAP + SCAP Security Guide — Linux compliance automation — OpenSCAP jako open-source implementation NIST Security Content Automation Protocol. SCAP Security Guide (SSG) z profilami: CIS Level 1/2, DISA STIG, NIST SP 800-171, NIST SP 800-53 baseline, PCI-DSS, HIPAA, ANSSI BP-028 minimal/intermediate/high. Komenda: oscap xccdf eval –profile xccdf_org.ssgproject.content_profile_cis_workstation_l1 –results-arf results.xml –report report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml. Wynik: report HTML z pass/fail per kontrola, ARF (Asset Reporting Format) XML dla central reporting (Foreman/Katello, Red Hat Insights, Wazuh, Anchore Engine). Remediation bash scripts auto-generated (oscap xccdf generate fix). Standard w organizacjach RHEL/Ubuntu/SUSE.
Lynis — security auditing dla Unix-like — Lynis 3.1+ jako lightweight CLI tool dla Linux/macOS/BSD audit (CISOfy company, dual open-source community + commercial Lynis Enterprise). Ponad 300 kontroli pokrywających: authentication, network, file integrity, kernel hardening, logging, software, malware. Wykonanie: sudo lynis audit system –quick (5-10 min) lub –pentest dla głębokiego skanu. Wynik: hardening index 0-100 (typowo nowy system bez hardening 40-55%, po hardening 75-85%), warnings + suggestions z konkretnymi remediation commands, /var/log/lynis.log + lynis-report.dat. Lekki — działa na resource-constrained hosts (kontenery, IoT, embedded), bez external dependencies poza shell + awk + grep.
Tenable Nessus Professional / Tenable Security Center — Tenable Nessus jako gold standard vulnerability scanner (Tenable, Inc., NASDAQ: TENB). Nessus Professional dla single-scanner deployments (~3000 USD/year per scanner), Tenable Security Center dla multi-scanner z central management (enterprise pricing), Tenable.io dla cloud-managed SaaS. Plugin database aktualizowana daily — 200,000+ plugins pokrywających CVE od 1999. Authenticated scan z Domain Admin credentials lub SSH key wykrywa 5-10x więcej findings vs unauthenticated. Compliance scanning (CIS, DISA STIG, PCI-DSS) z built-in policies. Output: HTML/PDF report, CSV export dla SIEM, REST API dla automation. Wymagane dla wielu enterprise audytów (KNF, NFZ, kontrahenci enterprise wymagają Nessus scan jako proof).
Qualys VMDR / Rapid7 InsightVM — alternatywy klasy enterprise — Qualys Vulnerability Management Detection and Response (cloud-native, agent-based scanning agent VMDR + Cloud Agent dla continuous assessment), Rapid7 InsightVM (formerly Nexpose, on-prem + cloud hybrid, integration z Metasploit dla exploit validation), Microsoft Defender Vulnerability Management (included w Microsoft Defender for Servers Plan 2, integration z Microsoft Defender for Endpoint). Wybór: Qualys dla cloud-first organizations (Azure, AWS, GCP infrastructure), Rapid7 dla teams chcących exploit validation (pentest workflow integration), Microsoft DVM dla Microsoft-centric environments z istniejącym Microsoft 365 E5 Security.
Microsoft Defender for Servers Plan 1/2 — built-in compliance — Microsoft Defender for Servers (część Microsoft Defender for Cloud) z Plan 1 (EDR + adaptive application control + JIT VM access, ~5 USD/host/month) i Plan 2 (Plan 1 + Vulnerability Assessment by Qualys lub Microsoft, File Integrity Monitoring, Network Map, Adaptive Network Hardening, ~15 USD/host/month). Security Recommendations z mapowaniem na Azure Security Benchmark v3, CIS Microsoft Azure Foundations Benchmark, NIST SP 800-53, PCI-DSS, FedRAMP. Continuous Assessment — score 0-100 per host, alerts, remediation actions. Azure Arc dla on-prem hosts (Windows Server, RHEL, Ubuntu) — pozwala zarządzać hostami on-prem przez Azure portal jako pełnoprawne Azure resource.
Sysmon + ELK / Wazuh / Splunk — endpoint visibility — Microsoft Sysmon (Sysinternals) jako advanced Windows logging — Event ID 1 (Process Create), 3 (Network Connection), 11 (File Create), 12-14 (Registry), 22 (DNS query), 23 (FileDelete). Konfiguracja przez SwiftOnSecurity Sysmon Config lub Olaf Hartong config (community baseline). Forwarding do central SIEM: Elastic SIEM (Elastic Agent + Fleet), Wazuh (open-source XDR with built-in OpenSCAP, file integrity monitoring, CIS benchmark scanning), Splunk Enterprise Security (commercial), Microsoft Sentinel (cloud-native SIEM/SOAR). Critical dla incident response — bez Sysmon Windows-only Security Log nie wystarczy do forensic timeline (no process create, no network connection details, no registry changes).
auditd + AIDE / Tripwire — Linux file integrity — Linux Audit Daemon (auditd) jako kernel-level audit framework — reguły przez auditctl lub /etc/audit/rules.d/ (audit syscalls execve, unlinkat, open dla /etc/passwd, /etc/shadow, /etc/sudoers; watch file mod for /etc/cron.d/, /var/spool/cron/). Reading: ausearch, aureport dla raportów. AIDE (Advanced Intrusion Detection Environment) jako file integrity monitor — baseline hash database dla critical files, daily check przeciw baseline, alerty na zmiany. Tripwire jako commercial alternative (więcej features, GUI, central management). Wazuh agent włącza auditd compliance + FIM jako natural part configuration. Critical dla NIS2 compliance (art. 21 ust. 2 lit. h — kryptografia i kontrola integralności).
Dla kogo audyt serwerów — segmenty rynkowe
Każdy segment ma inne wymogi regulacyjne, scope hostów i poziom dojrzałości compliance — dostosowujemy zakres i głębokość audytu:
SMB (10-50 hostów) — pierwszy audyt baseline — typowo firma 50-250 pracowników z 10-30 hostami wirtualnymi (Active Directory DC, file server, RDS, SQL Server, aplikacja LOB, monitoring). Audyt baseline raz na rok, focus na 80/20 — top 10 krytycznych findings (otwarte porty na DMZ, brak MFA dla RDP, EOL Windows Server 2012/R2, niezałatane Exchange, SMBv1 enabled). Koszt: 8-25 tys. zł za audyt + plan remediacji. Wynik: krótka droga do podstawowego compliance NIS2 (jeśli firma jest podmiotem ważnym/kluczowym według ustawy KSC) i ISO 27001.
Mid-market (50-200 hostów) — audyt cykliczny + ISO 27001 — typowo firma 250-1000 pracowników z 50-150 hostami wirtualnymi (VMware vSphere lub Hyper-V cluster, kilka aplikacji business-critical, SQL Server Always On, Exchange lub Microsoft 365, kilka aplikacji branchowych). Audyt kwartalny po pierwszym baseline rocznym, mapowanie na ISO 27001 Annex A.8 wszystkie kontrole. Często w trakcie certyfikacji lub recertyfikacji ISO 27001 — audyt jest kluczowym dowodem dla audytora certyfikującego. Koszt: 40-120 tys. zł rocznie (4 audyty kwartalne).
Enterprise (200-2000 hostów) — continuous compliance monitoring — duże organizacje z 200-2000+ hostami fizycznymi i wirtualnymi (multi-DC architecture, kilka tysięcy VMs, hybrid cloud, multiple branch offices). Wdrożenie continuous compliance monitoring (Microsoft Defender for Cloud z Defender for Servers Plan 2, Tenable Security Center, Wazuh dla Linux, Sysmon + Microsoft Sentinel/Splunk dla EDR/XDR). Manualny audyt 1-2x rocznie jako validation. Mapowanie na ISO 27001 + NIS2 + sektorowe regulacje (KNF Rekomendacja D dla banków, NFZ dla zdrowia, MON dla obronności). Koszt: 200-800 tys. zł rocznie.
Podmioty kluczowe NIS2 (banki, energetyka, telco, transport, zdrowie) — dyrektywa NIS2 (transponowana ustawą KSC 2024) wymaga: regularnych audytów bezpieczeństwa (minimum rocznie dla podmiotów kluczowych — art. 21 ust. 2 lit. f), formal incident reporting do CSIRT NASK (24h initial, 72h update, 30 dni final report), MFA wszędzie (art. 21 ust. 2 lit. i), monitorowanie ciągłe (art. 21 ust. 2 lit. h), penetration testing periodically (art. 22 — TLPT-like dla podmiotów kluczowych). Audyt z mapowaniem na każdy ustęp art. 21 to obligatoryjny artefakt dla audytu KSC + audytor certyfikujący ISO 27001 jeśli organizacja posiada. Koszt: 300 tys. – 1.5 mln zł rocznie zależnie od skali.
Banki i instytucje finansowe — DORA + KNF Rekomendacja D — DORA Reg. (EU) 2022/2554 art. 9 (ICT risk management framework) wymaga regularnej oceny ryzyka ICT z hardening jako podstawowa kontrola. KNF Rekomendacja D dla banków: minimum kwartalny review konfiguracji security relevant servers, formal procedures dla each change w produkcji (Change Advisory Board), penetration testing (banki min. rocznie, dla critical systems częściej), Threat-Led Penetration Testing (TLPT) zgodne z DORA art. 26 dla podmiotów objętych testowaniem. Audyt mapowany na DORA + Rekomendacja D + ISO 27001 + NIS2 (banki podlegają wszystkim razem). Najwyższe wymogi w Polsce. Koszt: 500 tys. – 3 mln zł rocznie dla większych banków.
Healthcare (szpitale, NFZ, prywatne sieci medyczne) — sektor objęty NIS2 (rozporządzenie wykonawcze do ustawy KSC obejmuje placówki opieki zdrowotnej > 50 łóżek), Ustawą o Krajowej Sieci Onkologicznej (dla szpitali onkologicznych), MDR dla wytwórców urządzeń medycznych z komponentem ICT. Specyficzne wyzwania: medyczne urządzenia (PACS, RIS, LIS, CR/DR systems) z EOL OS (typowo Windows 7 / Windows Server 2008 — vendor pin), brak możliwości MFA dla niektórych workstation w blokach operacyjnych, integration with HIS (Hospital Information System), high availability requirement (24/7 operacje). Audyt obejmuje hosty IT klasyczne + medical devices network (segmentation, ACL, monitoring), mapowanie na NIS2 + ISO 27001 + ISO 13485 dla wytwórców MDR. Koszt: 150-600 tys. zł rocznie.
Etapy audytu serwerów — od kickoff po retest
Każdy audyt realizujemy w 5 udokumentowanych etapach z punktami akceptacji klienta po każdym etapie:
1. Kickoff + scope definition (3-5 dni) — spotkanie z IT lead + business owner: ustalenie scope (lista hostów do audytu — typowo wszystkie production servers + sample z dev/test), windows time (audit-friendly maintenance windows, nie blokowanie production traffic), credentials (read-only domain admin lub local Administrator + SSH key dla Linux z sudo NOPASSWD dla audit commands), legal coverage (NDA, statement of work, scope of authorization). Identyfikacja sensitive systems wymagających extra care (production database hosts — audit poza godzinami szczytu, healthcare devices — wymagana zgoda specjalisty technicznego vendora medycznego). Wynik: SoW z scope + timing + accountability, signed-off przez klienta.
2. Inwentaryzacja + skan automated (1-2 tygodnie) — automated discovery: network scan Nmap z host enumeration (-sn dla discovery, -sV -sC -O dla service/OS detection — ostrożnie dla legacy hosts które reagują na agressive scan), Active Directory query (Get-ADComputer, Get-ADUser, Get-ADGroupMember Administrators), vCenter inventory query (Get-VM z PowerCLI), Azure Arc inventory dla hybrid. Automated compliance scan: OpenSCAP dla Linux z SCAP Security Guide profili CIS Level 1, PowerShell DSC + Compliance scan dla Windows, Lynis dla Linux quick audit, Nessus authenticated scan z Domain Admin credentials, Microsoft Defender Vulnerability Management report export. Wynik: raw data dla każdego hosta — OS version, patches, services, accounts, configurations, CVE findings.
3. Analiza manualna + ekspercki review (1-2 tygodnie) — manualne potwierdzenie krytycznych findings (false positives elimination — szczególnie ważne dla Nessus, który ma 5-15% false positive rate przy default settings), risk scoring per finding (CVSS + business context = effective risk), priorytyzacja remediation (CISA KEV priority, public PoC available, internet-exposed host vs internal), root cause analysis dla recurring findings (np. brak hardening w golden image template → wszystkie nowe hosty inherit problem). Procedural controls audit (interview z IT lead): change management process, incident response procedures, backup procedures, access review periodicity, training program. Dokumentacja audit (każdy finding z evidence — screenshot, log excerpt, command output).
4. Raportowanie (3-5 dni) — produkt finalny: 1) Executive Summary (8-15 stron) dla zarządu — top 10 ryzyk, current compliance posture (Score per ISO Annex / NIS2 article), recommended budget + timeline, business impact analysis. 2) Technical Report (60-200 stron) dla IT team — każdy finding z description, evidence, risk score (CVSS + business context), remediation steps (konkretne PowerShell / bash commands lub konfigurations), references (CIS Control number, ISO Annex, CVE ID, vendor KB). 3) Remediation Plan (Excel/CSV) — finding ID, priority P1-P4, estimated effort (man-hours), owner assignment, target date, validation criteria. 4) Compliance Mapping Matrix (Excel) — każda kontrola CIS / ISO Annex / NIS2 article z status per host. 5) Presentation deck dla zarządu (PPT, 20-30 slajdów).
5. Retest + validation (typowo 30-90 dni po raporcie) — po wdrożeniu remediation klient zgłasza gotowość — wykonujemy targeted retest na hosts gdzie były P1/P2 findings: rerun automated scan (OpenSCAP, Nessus), verify fix (np. SMBv1 disabled — Get-WindowsFeature FS-SMB1, TLS 1.0 disabled — IISCrypto check, patch applied — Get-HotFix). Validation procedure dokumentowana — każde P1 finding ma signed-off acceptance criteria. Wynik: retest report (10-30 stron) potwierdzający compliance improvement (typowy increase 25-45% Level 1 → 85-95% Level 1 po remediation). Audit certificate dla klienta — może być załączony do compliance evidence dla audytora ISO / NIS2 / DORA. Często prowadzimy też quarterly check-in calls dla continuous improvement.
Dlaczego audyt serwerów z Virtline
Audyt to nie tylko skan podatności — wymaga doświadczenia w hardening produkcyjnych środowisk i znajomości realiów polskich audytów ISO / NIS2 / KNF:
Certyfikat ISO/IEC 27001:2023 — wystawiony przez TÜV NORD, nr AC090 121/2469/6137/2026 (ważny do 02.2029). Sami przeszliśmy certyfikację — znamy z autopsji jakie evidence chce audytor, jakie pytania zadaje w trakcie audit fieldwork, na co patrzy w surveillance audits. Klient dziedziczy naszą certyfikację jako referencyjny ślad — nasz audyt jest akceptowany jako pre-audit evidence przez audytora certyfikującego klienta.
Certyfikowani audytorzy — CISA, CISSP, OSCP, GCIH — zespół posiada certyfikaty: CISA (Certified Information Systems Auditor — ISACA, primary cert dla auditingu), CISSP (Certified Information Systems Security Professional — ISC2, broad coverage 8 domain CBK), OSCP (Offensive Security Certified Professional — hands-on penetration testing), GCIH (GIAC Certified Incident Handler — SANS, incident response). Inżynierowie infrastruktury z VCP-DCV (VMware), MS Windows Server Hybrid Administrator (AZ-800/801), RHCSA (Red Hat) dla głębokiej znajomości technologii.
Znajomość polskich audytów — KNF, NFZ, TÜV NORD, BSI — uczestniczyliśmy w audytach klientów prowadzonych przez wszystkie major polskie i międzynarodowe jednostki certyfikujące: TÜV NORD, BSI Group, DEKRA, BDO, Bureau Veritas, DNV dla ISO 27001 / ISO 22301 / ISO 20000. Audyty KNF dla banków i instytucji finansowych, NFZ dla podmiotów medycznych, KSC NASK dla podmiotów NIS2 ważnych/kluczowych. Wiemy które evidence audytor akceptuje, które kwestionuje, jakie procedury muszą być formalnie udokumentowane vs tylko technicznie wdrożone.
Vendor-neutral — narzędzie pod problem, nie partnership — używamy konkretnego narzędzia (Nessus, Qualys, Wazuh, OpenSCAP, Lynis, Microsoft Defender) zgodnie z potrzebami audytu, nie zgodnie z reseller agreement. Klient ma już Tenable Security Center — używamy go zamiast naszego Nessus Professional. Klient ma Microsoft 365 E5 Security z Defender Vulnerability Management — używamy go i jego raportów. Nie pchamy bezsensownych narzędzi dla zwiększenia revenue partnership.
Plan remediacji wykonalny dla zespołu klienta — raport audytu bez wykonalnego planu jest bezużyteczny. Nasze findings mają konkretne remediation steps (PowerShell command, bash command, konkretna registry key, konkretny GPO setting) — nie generic typu „implement defense in depth”. Owner assignment, estimated effort w godzinach pracy, target date dla każdego P1-P4. Często prowadzimy też hands-on hardening dla zespołów klienta po audycie (training + supervised remediation w testowym środowisku) — finding identification + fix w jednym pakiecie usługowym jeśli klient woli.
FAQ: Audyt serwerów — najczęstsze pytania
CIS Benchmark vs DISA STIG — który stosować?
Wybór zależy od regulatora i sektora. CIS Benchmarks (Center for Internet Security) jest bardziej praktyczny i szeroki — pokrywa większość OS i aplikacji enterprise, ma 2 poziomy (Level 1 essential, no service disruption / Level 2 advanced, possible compatibility impact), zaktualizowany kwartalnie, darmowy do download. DISA STIG (Security Technical Implementation Guides — U.S. Defense Information Systems Agency) jest bardziej rygorystyczny — wymagany dla podmiotów współpracujących z U.S. DoD, kontraktorów obronnych NATO, niektóre wymogi w naszym MON. STIG typowo bardziej restrykcyjny niż CIS Level 2 (np. STIG wymaga TLS 1.2 minimum nawet dla internal-only services, CIS pozwala TLS 1.1 dla legacy), wymaga formal procedure dla każdego wyjątku (POA&M — Plan of Action and Milestones). Pratyczna rekomendacja: dla większości polskich firm bez kontraktów obronnych — CIS Benchmark Level 1 obowiązkowy, Level 2 dla DC i hostów w DMZ. Dla podmiotów objętych KNF Rekomendacja D — CIS Level 1 + dodatkowe specyficzne kontrole z Rekomendacji. Dla podmiotów współpracujących z MON, NATO, U.S. DoD — DISA STIG obligatoryjny. Wiele organizacji łączy oba: CIS jako baseline operacyjny + DISA STIG dla specific systems (np. SECRET classification hosts).
Jak często powinien być wykonywany audyt serwerów?
Częstotliwość zależy od wymogów regulacyjnych i dynamiki zmian w infrastrukturze. Standardowa rekomendacja: pełen audyt point-in-time 1x rocznie (minimum dla ISO 27001 — A.5.36 Compliance with policies, rules and standards for information security), kwartalny review zmian od ostatniego audytu (configuration drift, nowe hosty, patch level), continuous monitoring automated (Microsoft Defender for Cloud, Tenable Security Center, Wazuh) z daily/weekly check. NIS2 art. 21 ust. 2 lit. f wymaga regular assessment skuteczności środków zarządzania ryzykiem — interpretowane jako minimum 1x rocznie dla podmiotów ważnych, 1x w 6 miesięcy dla podmiotów kluczowych. KNF Rekomendacja D dla banków: minimum kwartalny review konfiguracji security-relevant servers, formal procedure dla każdej zmiany, penetration testing minimum rocznie. DORA art. 9 dla finansowych: continuous ICT risk assessment, formal review minimum rocznie. ISO 27001 surveillance audit — co rok, recertyfikacja co 3 lata. Praktycznie: małe firmy 1x rocznie + miesięczny patch scan, mid-market kwartalnie + continuous monitoring, enterprise — continuous monitoring + audit roczny + extra ad-hoc po dużych zmianach (M&A, datacenter migration, nowa aplikacja business-critical). Po incydencie bezpieczeństwa — zawsze audyt poincydentalny niezależnie od harmonogramu.
Windows Server vs Linux audit — różnice w podejściu?
Filozofia podobna (configuration baseline → scan → findings → remediation), ale narzędzia, kontrole i logging są inne. Windows Server: CIS Microsoft Windows Server 2022 Benchmark z ~350 kontrolami, scan przez Microsoft Defender for Servers Plan 2 Security Recommendations, Microsoft Security Compliance Toolkit (LGPO, PolicyAnalyzer, SCT Settings), PowerShell DSC dla configuration drift detection, audit przez Get-WinEvent (Security Log + Application Log + Sysmon), GPO jako primary configuration mechanism. Nessus z Windows compliance audit policies. Specyficzne: Account Lockout Policy, Audit Policy Subcategories, Windows Defender Firewall, BitLocker, AppLocker / WDAC, Credential Guard, HVCI, SmartScreen, ASR rules. Linux: CIS Distribution-specific Benchmark (RHEL/Ubuntu/Debian/SUSE — każdy ma osobny benchmark), scan przez OpenSCAP z SCAP Security Guide, Lynis dla quick audit, Wazuh agent dla compliance + FIM + log forwarding, auditd dla syscall monitoring, AIDE dla file integrity. Specyficzne: /etc/login.defs (password policy), /etc/security/limits.conf, /etc/sudoers + /etc/sudoers.d/, SELinux/AppArmor MAC policy, systemd unit hardening (ProtectSystem, NoNewPrivileges, PrivateNetwork), iptables/nftables rules, SSH config (sshd_config), kernel parameters (sysctl —fs.suid_dumpable, kernel.kptr_restrict, net.ipv4.conf.all.rp_filter). Realna praca: rzadko organizacja jest 100% Windows lub Linux — typowo 60/40 lub 70/30 — audyt obejmuje oba z odpowiednim toolset per platforma.
Czy automated tools (Nessus, OpenSCAP) wystarczą bez manual review?
Nie wystarczą. Automated tools dają 60-80% findings (CVE z patch level, default configurations, known weak ciphers), ale brakuje krytycznych obszarów: 1) Business context risk — Nessus pokazuje CVE-2023-XXXXX z CVSS 9.5 na hoście, ale czy ten host jest production-critical (DC) czy test? Czy internet-exposed czy internal? Efektywne ryzyko może być Critical lub Low w zależności od kontekstu. 2) Privilege escalation paths — Nessus nie znajdzie ścieżki od regular user → Domain Admin przez misconfigured service ACL (BloodHound territory). 3) Application-level security — Nessus skanuje OS, nie znajdzie SQL injection w aplikacji webowej, weak business logic w API, IDOR. 4) Procedural controls — automated tool nie powie czy organizacja ma formal incident response procedure, czy regularnie testuje backup restore, czy training awareness program funkcjonuje. 5) False positives (5-15% w Nessus przy default settings) — automated tool potrzebuje manualnej weryfikacji każdego krytycznego findingu. 6) False negatives — niektóre findings wymagają zrozumienia kontekstu (np. shared service account z Domain Admin — automated tool zobaczy account istnieje, manualne review wykryje że to anti-pattern). 7) Compliance interpretation — mapowanie findings na ISO Annex / NIS2 article wymaga eksperckiej interpretacji. Realnie: automated tools generują dane, audytor je interpretuje, weryfikuje, kontekstualizuje, priorytyzuje. Pure automated audit (np. tylko Nessus report jako finalny artefakt) typowo dostaje qualified opinion przez audytora certyfikującego ISO.
Jak prioritizować remediation gdy mamy 500+ findings?
Priorytyzacja jest kluczowa — naive approach (najpierw wszystkie Critical, potem High) prowadzi do paraliżu (typowo 50-200 Critical findings na 100-host environment bez hardening). Praktyczna metoda 4-warstwowa: 1) CISA KEV (Known Exploited Vulnerabilities) — CVE aktywnie eksploatowane in-the-wild — patch w 48-72h niezależnie od CVSS score, agresywny maintenance window. Lista publiczna kev.cisa.gov, aktualizowana daily. 2) Internet-exposed hosts z High/Critical CVE — DMZ servers, web servers, mail gateway, VPN concentrator — patch w 7-14 dni. Nawet jeśli CVE nie ma znanego exploitu, internet exposure dramatycznie zwiększa likelihood discovery. 3) Active Directory critical infrastructure — Domain Controllers, ADFS, AD CS Issuing CAs, Tier 0 servers — separate timeline (DC patching wymaga careful planning aby uniknąć replication issues, ale każda compromise = whole domain takeover). 4) Business-critical applications — production database hosts, payment processing, customer data hosts — coordinate z business owner, plan downtime window. Pozostałe findings — bulk remediation w sprintach 2-tygodniowych grupowanych po typu (wszystkie SMBv1 disable razem, wszystkie TLS hardening razem, wszystkie GPO baseline deployment razem). Effort optimization: automation jest kluczowa — PowerShell DSC, Ansible playbooks, Chef/Puppet — finding fix raz, deploy do 200 hostów w godziny, nie miesiące. Tracking — Excel/Jira board z status (Open / In Progress / Validated / Closed), weekly status meeting, monthly executive report. Realnie: 500 findings → 90 dni remediation z dedicated FTE.
Czy audyt może wykryć backdoory i APT?
Częściowo. Standardowy audyt configuration + vulnerability scan jest projektowany dla compliance i typowych zagrożeń — może wykryć niektóre objawy ale nie jest threat hunting. Co audit wykryje: 1) Unauthorized accounts z elevated privileges (forensic review accounts z lastlogon vs HR records). 2) Persistence mechanisms — scheduled tasks running as SYSTEM/admin (Get-ScheduledTask, Get-ScheduledTaskInfo), unusual services (Get-Service z Path containing nietypowe lokalizacje typu C:\Users\…, C:\Temp\), WMI subscriptions (Get-WMIObject -Namespace root\subscription -Class __FilterToConsumerBinding), registry Run/RunOnce keys, AutoStart entries. 3) Unusual file integrity — AIDE/Tripwire baseline comparison wykrywa modifications w /etc, /usr/bin, /sbin. 4) Outdated software jako wektor — APT często wykorzystuje znane CVE w niezałatanym software. 5) Configuration deviation — disabled antivirus, disabled audit logging, RDP enabled gdy nie powinno być, firewall rules permitting unusual traffic. Co audit NIE wykryje (wymaga dedicated threat hunting): 1) Fileless malware (in-memory only, no persistence on disk). 2) Living-off-the-land techniques (PowerShell, WMI, BITS używane przez admins legalnie). 3) Long-dormant implants (custom backdoor z minimal footprint, command-and-control over standard HTTPS). 4) Sophisticated rootkits ukrywające pliki/procesy/network connections przed OS API. 5) Supply chain compromise (kompromitowane software vendor’s update channel). Dla podejrzenia APT — separate engagement Threat Hunting / Compromise Assessment z dedicated tools (Velociraptor, KAPE, GRR, EnCase Forensic, FireEye HX), forensic team z GCFA/GREM certificates. Audyt może być pierwszym sygnałem („unusual scheduled task na DC — wymaga deeper investigation”), ale nie zastępuje threat hunting.
Czy audyt powoduje downtime serwerów?
Praktycznie nie — przy poprawnym wykonaniu. Większość audit activities jest read-only: PowerShell query (Get-* commands), bash query (cat /etc, /proc, ls -la), SQL query (read-only views), API calls (vCenter, Active Directory). Brak modyfikacji konfiguracji, brak instalacji software (poza temporary audit agents dla compliance scan — i ten można uninstall po audycie). Authenticated Nessus scan generuje typowo 1-5% CPU/memory overhead i 50-200 Mbps network traffic per scan engine — odczuwalne tylko na bardzo obciążonych hostach (np. mocno wysycony SQL Server podczas peak business hours). Best practice: scheduled scans poza godzinami szczytu (typowo 23:00-05:00 weekday lub weekend), throttling Nessus scan engine (Max simultaneous TCP sessions: 10-20 zamiast default 1500 dla legacy hosts), wykluczenie z aktywnych scanów hostów krytycznych dla real-time operations (trading systems, ICU monitors w szpitalach, SCADA w przemyśle — dla tych dedicated approach poprzez evidence collection manual rather than automated scan). Ryzyko outage: 1) Unauthenticated agressive Nmap scan (-A flag, default 5000 ports) może zawiesić legacy embedded devices (printers, medical devices, OT systems) — STRONG no-no, wymaga authenticated scan tylko. 2) Brute force scanners (Hydra, Patator) — niedopuszczalne w audycie, używane tylko w pentest z explicit authorization. 3) Exploit-validation scanners (Metasploit dla validation) — tylko w pentesting engagement, nie w standard compliance audit. Realistycznie: audyt dobrze zaplanowany powoduje zero downtime, ale wymaga przygotowania i koordynacji ze service owners.
Ile kosztuje audyt serwerów?
Zakres cenowy zależy od liczby hostów, scope (sample vs full), modelu (one-time vs cyclical), poziomu szczegółowości raportu, dodatkowych usług (remediation support, training). Orientacyjne ceny rynek polski 2026: 1) Mini audit (10-25 hostów, sample 5 hostów full scan + reszta automated only, basic report 30-50 stron) — 8-20 tys. zł, 1-2 tygodnie. 2) SMB audit (25-75 hostów, all hosts full scan, technical report + executive summary, basic remediation plan) — 25-60 tys. zł, 3-5 tygodni. 3) Mid-market audit (75-200 hostów, full scope, compliance mapping na ISO 27001 + NIS2, detailed remediation plan z owner assignment, retest po remediation) — 60-150 tys. zł, 6-10 tygodni. 4) Enterprise audit (200-1000+ hostów, full scope, multi-site coordination, compliance mapping na multiple frameworks ISO+NIS2+DORA+sector-specific, dedicated audit project team) — 150-500 tys. zł, 3-6 miesięcy. 5) Continuous compliance monitoring service (audyt automated z monthly review + quarterly deep dive + annual report) — 8-50 tys. zł/miesiąc zależnie od skali. 6) Retest after remediation (typowo 25-40% kosztu początkowego audytu) — kluczowy artefakt dla audytora ISO. Dodatkowe koszty: 1) Hands-on remediation support (typowo 1500-2500 zł/dzień per inżynier), 2) Training dla zespołu klienta (1000-1500 zł/osoba/dzień), 3) Specialized scope (TLPT — Threat-Led Penetration Testing dla DORA — typowo 300 tys. – 1 mln zł, full red team engagement). Free assessment: oferujemy 1-godzinne konsultacje + estymację scope na podstawie discovery call — bez kosztu, bez zobowiązań.
Audyt vs penetration test — różnice?
Audyt i pentest to różne usługi z różnymi celami. Audyt bezpieczeństwa: 1) Cel — assessment compliance z baseline (CIS, ISO Annex, NIS2 article). 2) Approach — read-only inspection configuration, accounts, services, patches, logging. 3) Authorized — read access do hosts (Domain Admin lub local Administrator, SSH key z sudo NOPASSWD dla audit commands). 4) Output — raport z findings mapowanych na compliance framework, plan remediacji z priorytetami. 5) Time — 2-12 tygodni zależnie od scope. 6) Koszt — niższy niż pentest. 7) Risk — minimalny, read-only. 8) Wymagane przez — ISO 27001 surveillance, NIS2 art. 21 lit. f, KNF Rekomendacja D, audyt KSC. Penetration test: 1) Cel — symulacja realistic attack scenario, wykrycie exploitable vulnerabilities w runtime context. 2) Approach — active exploitation — phishing dla initial access, exploitation CVE dla foothold, privilege escalation, lateral movement, exfiltration simulation. 3) Authorized — explicit authorization z signed-off scope of engagement + rules of engagement (jakie techniki dozwolone, jakie out-of-scope, jakie systems excluded). 4) Output — narratywny raport z attack path (jak atakujący doszedł od ext recon do domain compromise), specific exploits used, recommendations z technical depth. 5) Time — 2-8 tygodni dla typical engagement (longer dla red team). 6) Koszt — typowo 50-300 tys. zł zależnie od scope (DORA TLPT — Threat-Led Penetration Testing — 300 tys. – 1 mln zł). 7) Risk — wyższy (możliwa accidental destabilization), wymaga careful planning + monitoring. 8) Wymagane przez — KNF Rekomendacja D (minimum rocznie dla banków), DORA art. 26 (TLPT dla podmiotów objętych), wewnętrzne best practices dla mature security programs. Komplementarne: audyt wykrywa szeroko („breadth”), pentest pogłębia („depth”) — typowa organizacja powinna mieć oba: audyt rocznie (compliance) + pentest rocznie (effectiveness).
Czy raport audytu można pokazać audytorowi ISO 27001 / NIS2?
Tak, raport audytu jest jednym z kluczowych artefaktów dla audytora certyfikującego. Co audytor ISO/NIS2 chce zobaczyć: 1) Aktualny raport audytu < 12 miesięcy (najlepiej < 6 miesięcy przed surveillance). 2) Mapowanie findings na konkretne kontrole ISO Annex A (każdy finding powinien być przypisany do A.8.X / A.5.Y / A.9.Z + opcjonalnie do NIS2 article + CIS Control number). 3) Plan remediacji z przypisanymi ownerami i target dates — pokazuje że organizacja systematycznie adresuje findings, nie tylko zbiera dane. 4) Evidence remediation — dla closed findings: screenshot before/after, command output, retest scan result. 5) Procedural follow-up — wpis w risk register, decyzja kierownictwa o akceptacji / mitigacji / transferu / avoidance dla każdego significant ryzyka. 6) Continuous improvement — dane porównawcze z poprzednich audytów pokazujące trend (CIS Compliance Score per host rok do roku, average time-to-patch dla critical CVE). 7) Methodology documentation — opis approach, narzędzi, scope, limitations — żeby audytor mógł ocenić quality of evidence. Najczęstsze powody że audytor nie akceptuje raportu: 1) Tylko Nessus output bez interpretation — "automated scan output bez expert review nie jest audit". 2) Brak compliance mapping — "findings nie pokazują które ISO Annex są naruszone". 3) Brak remediation evidence — "identyfikacja problemu bez follow-through". 4) Stary raport — "audit > 18 miesięcy nie reflects current state”. 5) Scope mismatch — „audit obejmował 30% hostów, ISMS scope obejmuje 100%”. 6) Conflict of interest — „raport pisany przez ten sam zespół który zarządzał infrastructure”. Dla maksymalnej acceptability: 1) Audyt przez third-party (zewnętrzna firma z odpowiednimi certyfikacjami CISA/CISSP). 2) Pełen scope ISMS. 3) Mapowanie na wszystkie relevant frameworki. 4) Aktualny < 6 miesięcy. 5) Follow-through z remediation evidence.
Certyfikacja ISO/IEC 27001:2023
Audyty serwerów prowadzimy zgodnie z ISO/IEC 27001:2023
Virtline posiada certyfikat PN-EN ISO/IEC 27001:2023-08 wydany przez TÜV NORD. Numer certyfikatu: AC090 121/2469/6137/2026, ważny do 02.2029. Nasze audyty serwerów realizują wymagania Annex A.8.8 (zarządzanie podatnościami technicznymi), A.8.9 (configuration management), A.8.16 (monitorowanie czynności), A.8.22 (segregacja sieci), A.8.24 (użycie kryptografii), wspierają zgodność z dyrektywą NIS2 (art. 21 ust. 2 lit. e, f, i), CIS Controls v8 oraz NIST SP 800-53.
- Bezpieczeństwo IT — kompleksowa ochrona infrastruktury
- Audyt sieci komputerowych — topologia i segmentacja
- Monitoring IT 24/7 — Zabbix, Prometheus, Grafana
- EDR — Endpoint Detection and Response
- Wdrożenie IDS/IPS — wykrywanie włamań
- Dyrektywa NIS2 — zgodność dla podmiotów kluczowych
- ISO 27001 — certyfikacja Virtline TÜV NORD
- Administracja Linux i Windows
- Kopia bezpieczeństwa — backup i disaster recovery
Skontaktuj się z ekspertem Virtline
Zdefiniujemy zakres projektu, zaproponujemy architekturę i przygotujemy stałą wycenę w ciągu 5 dni roboczych. Bez zobowiązań — od pierwszej rozmowy rozmawiasz z inżynierami, nie ze sprzedawcami.