Search This Blog

NIS2 is not a product

As NIS2 takes effect across Europe, many still believe compliance can be achieved by buying more tools.

But NIS2 isn’t about technology — it’s about how you lead, govern and prove control.


NIS2 is not something you can install, configure or subscribe to.

Reality is fairly brutal: NIS2 is not a product, but a set of requirements for how your organisation is governed, organised and held accountable for cyber security over time.

NIS2 clearly defines what every organisation must include in its cyber security risk management.


The directive spells out these seven areas as the foundation for compliance:

(a) policies on risk analysis and information system security;
(b) incident handling;
(c) business continuity, such as backup management and disaster recovery, and crisis management;
(d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;
(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
(f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures;
(g) basic cyber hygiene practices and cybersecurity training;

You cannot “buy” policies, risk analysis or governance – you have to decide how you work.
You cannot outsource responsibility for incident handling, continuity or supply-chain risk – only execution.
You cannot claim NIS2 compliance if you never assess whether your measures are effective or if you skip basic cyber hygiene and training.

However, technology and products can absolutely help you achieve these requirements – if used the right way.
Firewalls, XDR, SOC services, vulnerability management, identity platforms and backup solutions are all powerful tools, but they only make sense when mapped to clear governance, roles and processes.

Don’t see NIS2 as a burden — use it as leverage.

For once, the law puts accountability where it belongs — with top management.
That means IT has a clearer mandate to demand the resources, structure and time required to meet these obligations.

NIS2 isn’t a problem. It’s your chance to get security taken seriously.

If someone tries to sell a “complete NIS2 solution” in a single product, this A–G list is the reality check:
NIS2 is a governance and accountability framework first — technology only adds value when it supports these obligations.

Use NIS2 as the push to build stronger governance, better processes and a culture where security is part of how you operate.

7-layer filtering


If you still believe your port-based firewall is enough, you probably already have unwanted guests on the inside.
Firewalls that only look at IP and port stopped being “secure” more than a decade ago.

CIS control 13.10 is about inspecting and controlling traffic at all layers, not just by ip and port. A modern NGFW is expected to understand which app and port are in use, which source user is behind the session, and which url is being accessed.

Example of 7-layer visibility: decrypted HTTPS session identified as netflix-base, full URL, user, and rule context logged.

Classic firewalls ask “source, destination, port – allow or deny?”. That mindset belongs to 2010. If your firewall still works that way, it is not protecting you — it is only routing with a false sense of security.

Attackers hide perfectly inside HTTPS and “normal” traffic. Everything looks fine on TCP 443 until you look deeper and realize what is actually happening. You cannot defend what you do not inspect.

Way too many network admins still choose not to log internal traffic, disable application inspection, and leave url filtering turned off between trusted zones. The usual excuses are performance, “too much noise,” or the illusion that internal traffic can be trusted — but the cost of missing what happens inside your own network is far higher. Modern firewalls have long been capable of full visibility — yet many are still configured like it’s 2010.

And yes — some even buy a brand-new NGFW and simply import the old configuration straight into it. That solves nothing. Shit in, shit out.

Internal traffic is where misuse, misconfigurations, and lateral movement begin. Without logs, you lose your early warning system. You cannot claim zero trust if your internal traffic is invisible.

If a workstation suddenly calls an internal url like /admin/export-users, /admin/backup/download, or /api/v2/internal/payments, that is not noise. That is a clear signal that something is wrong – and you need to see it, alert on it, and react.

Application visibility has been available for more than 15 years. There is no reason to still run a firewall that only understands ports.

Log everything — especially inside your own walls. Today’s threats live there.

Footnote with attitude:
The application field should never be “any.”
The port field should never be “any.”
If the app is, for example, ssl or web-browsing, a URL category must be applied.
If you leave Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering, and WildFire profiles empty, you are not demonstrating a Next-Generation Firewall.

Example from https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClWZCA0

And honestly — come on Palo Alto Networks.
You build one of the best firewalls on the planet, but your own documentation screenshots still show “any” on port and app, with no security profiles applied.
How about showing examples that reflect how an NGFW should actually be configured?

New EDL lists from my honeypot

edl.mrlogg.no/

A simple honeypot runs on a public IP that is not listed in DNS and not associated with any domain/FQDN.
Traffic to ports 22 (SSH) and 3389 (RDP) is logged, deduplicated, and published as external dynamic lists once per day.
If you think like me—that sources probing SSH/RDP on such an unadvertised IP are “bad” by default—you may want to block them for all inbound traffic.

I see no reason they should reach vpn.company.com, portal.company.com, mail.company.com, api.company.com, or *.company.com.


Links

  • edl.mrlogg.no/port22.txt

  • edl.mrlogg.no/port1433.txt

  • edl.mrlogg.no/port3389.txt

  • more to come..

Format

  • One IPv4 per line, no CIDR, no comments

  • Lists are overwritten on each daily run

Disclaimer

  • Use at your own risk. False positives are possible (e.g., research scanners)

  • Treat this as a signal, not a verdict

Goal

  • Reduce brute-force attempts and malicious port scanning

  • Reduce alert noise and log volume

Updates

  • More lists may be added; check edl.mrlogg.no for new .txt files


Port info

PortServiceTypical useWhy targeted
22SSHRemote login and file transferCommon target for brute-force on credentials
23TelnetRemote console access (legacy)Sends credentials in cleartext; easily abused
25SMTPMail transfer between serversScanned for open relays and spam abuse
1433Microsoft SQLDatabase connectionsSearched for exposed databases and weak creds
3389RDPWindows remote desktopHigh-value target for brute-force and exploits
5555IoT servicesDevice debugging and managementOften exposed on insecure IoT devices
5900VNCRemote desktop controlBrute-force and discovery of open controls
8080HTTP / proxyWeb apps and admin interfacesScanned for misconfigurations and panels
9100PrintingNetwork printer raw printingAbused for spam-print, DoS, or printer exploits



Feedback and requests are welcome. Contact me on LinkedIn