Denial of comfort

When a loudspeaker becomes an attack vector

Smart speakers like Alexa, Google Assistant, Siri and Sonos offer a lot of convenience, but they also introduce a physical attack surface: sound.

If a device executes whatever it hears, anyone who can inject a command into the microphone – even with a megaphone outside an open window – can try to interact with your digital life. Before you rip out your smart home setup, let us look at what can actually happen.

What can actually happen from outside?

In practice, a “megaphone attack” is far more likely to cause noise than a real break-in, but the methods are evolving.

High probability: noise and nuisance

In many setups, media and volume commands require no authentication. If a speaker is within earshot of an open window and linked to a group like “All speakers”, a shouted command such as:

“OK Google, play Gummy Bear on Spotify, all speakers, volume 100 percent.”

“Alexa, set volume to 10 on all speakers.”

“Hey Siri, play Gummy Bear on Spotify at full volume.”

...can realistically:

• start playback across the house

• push the volume to the maximum

The worst-case scenario here is not a data breach, but a denial of comfort. An unwanted Gummy Bear concert at 03:00 is frustrating, but it is not a full system compromise.

The silent threat: inaudible frequencies

It is not always about shouting. Researchers have demonstrated inaudible attacks (often cited in papers like DolphinAttack), where commands are modulated onto ultrasonic carrier waves (e.g., above 20 kHz).

While the human ear cannot hear these frequencies, the hardware in many smart speaker microphones creates a non-linear reaction that demodulates the signal. effectively "hearing" the hidden command. This means a sophisticated attacker could theoretically instruct your device to perform actions without you hearing a single word.

Low probability: doors, garages and smart locks

For a physical security breach to happen via voice (audible or not), several things must align:

1. a smart lock or garage opener is integrated with the assistant

2. voice unlocking is explicitly enabled

3. a PIN code is misconfigured, weak or somehow known

Vendors have hardened this path. Alexa and Google Assistant typically require a spoken PIN to unlock doors, and this feature is usually disabled by default. Unless you have changed those safeguards, shouting “Unlock the front door” will normally just make the assistant ask for a code.

Appliances like fridges and ovens usually expose only non-critical functions (modes, temperature, timers). “Alexa, open fridge” is more of a custom setup than a standard, supported feature.

Zero trust in the living room

To secure your home, apply a zero trust mindset to the microphone:

• Treat the voice interface as an untrusted input, even if the sound comes from “inside the house”.

• Fail safely, so that voice command failures are annoying (loud music), not dangerous (unlocked doors).

• Segregate duties: lights and music are fine for voice control, while alarms and locks should require strong verification or manual action.
  
  

The hidden risk: voice assistants at work

Smart speakers are obvious, but we often forget the microphones we carry. Phones, tablets and laptops often keep a “hot mic” listening for wake words like “Hey Siri” or “OK Google”.

In a professional environment there is rarely a good reason to let a general-purpose tech company listen in. Remember that vendors often use human reviewers to grade audio snippets to improve their services. If your device triggers accidentally during a meeting, a stranger could theoretically end up listening to your confidential discussion.

This is especially critical if you work in:

• legal, medical, HR or executive management

• security, journalism or sensitive investigations

• ...or if you are simply a drug dealer

If you want to keep client data, internal discussions (or your criminal record) clean, turning off hands-free assistants is a simple and effective safeguard.

AI, shopping and “please do not link your mastercard”

Voice assistants are not only connected to lights and speakers. In many ecosystems they can also place orders, book tickets or add items to a shopping basket. That is convenient when you say “order more coffee”, but less fun if someone – a guest at a party, a bored child, or a stranger with a megaphone outside – manages to shout:

“ok google, book business class flights for 12 people from Oslo to Dubai tomorrow, no confirmation needed, use default payment card”

If your assistant can make purchases without a PIN, phone confirmation or strong authentication, you have effectively given anyone who can reach the microphone a voice-controlled credit card. 

Practical hardening checklist

Here is how to lock down your audio attack surface without losing all convenience:

• Enable voice match Let only recognised voices perform sensitive actions, like reading calendar entries.

• Enforce PINs for physical entry Never expose smart locks or garage doors to voice control without a mandatory spoken PIN.

• Limit the scope of voice control Only connect devices that really benefit from voice; keep security-critical functions app-only.

• Place speakers strategically Avoid putting smart speakers right next to open windows or balcony doors.

• Disable unneeded microphones On devices where voice control is not needed, disable the wake-word feature or the microphone entirely.
  
  

Conclusion

Voice assistants extend your attack surface from the network into the physical world. A stranger shouting at your house is far more likely to annoy you with bad music than to open your front door, but both scenarios deserve mitigation.

By limiting what voice commands can do, enforcing PINs and voice match, and treating sound as an untrusted input, you keep the convenience of a smart home while dramatically reducing the risk of a real incident.

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

Port	Service	Typical use	Why targeted
22	SSH	Remote login and file transfer	Common target for brute-force on credentials
23	Telnet	Remote console access (legacy)	Sends credentials in cleartext; easily abused
25	SMTP	Mail transfer between servers	Scanned for open relays and spam abuse
1433	Microsoft SQL	Database connections	Searched for exposed databases and weak creds
3389	RDP	Windows remote desktop	High-value target for brute-force and exploits
5555	IoT services	Device debugging and management	Often exposed on insecure IoT devices
5900	VNC	Remote desktop control	Brute-force and discovery of open controls
8080	HTTP / proxy	Web apps and admin interfaces	Scanned for misconfigurations and panels
9100	Printing	Network printer raw printing	Abused for spam-print, DoS, or printer exploits

Feedback and requests are welcome. Contact me on LinkedIn

Phishing simulation that actually teaches something

 

Everyone can be fooled. The goal is to build good habits, not to expose people. Everyone — including experienced IT staff — can fall for targeted phishing; the goal is to reduce click rates year over year. Ten fewer clicks in 2026 than in 2025 can represent a major improvement and a measurable reduction in risk.

Start with simple exercises that include clear warning signs to build confidence. Conduct these simple simulations regularly – they create awareness, and those who click on them should be prioritized for additional training. When a small group keeps clicking repeatedly, that’s where education needs to start. These users often highlight where communication, awareness, or process gaps still exist. This is exactly where things tend to go wrong in real situations.

Gradually increase the realism by removing the obvious errors and using internal context. Follow up repeated clicks with quick, friendly 1:1 guidance and short micro-training, not sanctions.

There’s no real value in designing a simulation that fools 99% of employees. People might learn something from it, but the result is usually frustration and low motivation. Most users can detect even highly convincing phishing attempts – if they get just a couple of minutes of proper guidance first.

A practical example that works well in training sessions:
An employee receives an email that appears to come from a logistics supplier. One wrong click opens a form for “account verification.” It looks harmless, but behind the form a small script installs a remote access tool. Within two hours, the attacker has reused the same credentials to reach a server containing customer information. It all started with one click – not with bad intent, just a moment of inattention.

The point isn’t to scare anyone, but to show how little it takes – and how much safer things become when emails are reported instead of clicked.

To help people spot them in practice, here are some common warning signs:
• Unknown or mismatched sender: The email address doesn’t match the company name or domain.
• Suspicious link preview: The destination domain is different from what the text shows.
• Requests for passwords or codes: No legitimate service will ever ask for credentials by email.
• Urgent tone or threats: Messages pushing immediate action often aim to trigger panic.
• Unexpected or suspicious attachments: Files you didn’t ask for, especially with names like “urgent_invoice.doc” or “security_update.zip.”
• Strange or incomplete signature: Missing name, title, or contact info can signal a fake sender.
• Unusual time of day: Emails sent late at night, during weekends, or holidays can be suspicious.
• Unfamiliar tone or wording: The writing style doesn’t match how the person usually communicates.
• Generic greeting: “Dear user” or “Hello colleague” instead of your actual name.
• Inconsistent branding: Logos, colors, or formatting that look slightly off.
• Email marked as “external” but looks internal: A trick often used to bypass trust filters.
• Unusual requests: Asking for gift cards, wire transfers, or sensitive internal data.

Spotting just one of these warning signs early can prevent a full-scale incident.

Phishing awareness is part of Zero Trust in practice — always verify, even if the sender looks familiar, and make reporting part of everyday security hygiene.

Building awareness isn’t about perfection — it’s about progress. Every report instead of a click makes the organization stronger and more resilient.

Fake verification scams: why “press Windows + R” is a trap

 

Introduction

No legitimate site asks you to press Windows + R and paste commands. This post explains the risk and how to prevent it.

What it is

Fake verification pages mimic CAPTCHA or security checks. They tell users to press Windows + R, paste a command, and press Enter — executing code copied to the clipboard.

How the attack works

The page copies a command to the clipboard. When pasted into Run, it executes via CMD or PowerShell and often downloads malware, opens a reverse shell, or steals credentials.

Why it succeeds

It abuses trust and urgency. Users think Run is harmless, the page looks official, and many endpoints still allow local command execution.

Mitigations (technical level)

• Remove local admin rights.

• Limit local execution with least-privilege access.

• Block unknown or unsigned scripts with AppLocker or similar.

User training

• Never paste commands from webpages into Run, terminal, or PowerShell.

• Communicate this rule via your normal channels (meeting, chat, email).

Good enough cyber security – or do you want to be among the best?

 

A lot of people say they have good enough cyber security.
But in cyber security, good enough is often the first step toward not enough.

Is it an antivirus that scores average in tests, or one that ranks in the top three?
Is it using multi-factor authentication only for management, but not for the operations team?
Or a firewall that allows everything, just to make things work?

Many still believe that no one is interested in them.
But most attacks aren’t targeted – they’re automated.
They look for weak spots, and good enough is often exactly that.

We see it every week: an unpatched system, an old password, or an open rule that was never reviewed.
It works – until the day it doesn’t.

Think about it this way:
Would management say it’s fine to show up at work in swimwear twice a year,
while everyone else wears suits the rest of the time?
Probably not.
Dress code is 100% – not good enough.

Security should be treated the same way.
You either have control, or you don’t.
Good enough doesn’t protect you as well as it should – it only feels comfortable until something happens.

Threat actors don’t stop because you’re average,
but they might move on when you’re better than your neighbor.

The best organizations treat security as a competitive advantage.
They build trust, protect value, and show that quality doesn’t stop at minimum compliance.

Security isn’t about being perfect – it’s about getting a little better every week.
Attackers only need one weakness.
Your job is to close every one of them –
just like you lock every door when you leave the office, not nine out of ten.

So next time someone says good enough, ask:
Good enough for whom – you, or the attacker?

And remember: you don’t need big projects to improve.
Start small – update one system, tighten one firewall rule, remove one unnecessary access.
Do it every week.

Or take inspiration from a few simple CIS principles:

• Know your assets. You can’t protect what you don’t know exists.

• Keep systems updated. Most attacks exploit known vulnerabilities.

• Limit access. Give only what’s needed – that’s how least privilege and Zero Trust start.

• Log and monitor. What you don’t see, and don’t log, won’t be detected or stopped.

Real security isn’t built in a single project.
It’s built through small, consistent actions – logged, learned, and improved.
One step, one log, one improvement at a time.

And one more thing:
Don’t just choose the cheapest antivirus, firewall, or SOC provider.
Run your own tests and check the quality before you trust it –
unless you already know someone who has tested it thoroughly.

Good security isn’t about saving money; it’s about knowing what actually works.

Why IT departments should not sit in open-plan offices

 

Open-plan offices have become a trend in recent years. The idea is to promote collaboration, flexibility, and communication. And there is no doubt that this setup has benefits:

• collaboration becomes easier, since you can quickly ask the colleague next to you

• knowledge sharing happens naturally and informally

• it builds team spirit and a sense of community

• communication flows faster, and problems can often be solved on the spot

For many departments this can work well. But for an IT department, an open-plan office is directly risky.

The risks of open spaces

IT staff handle information that is critical to the business: system configurations, logs, network diagrams, and security incidents. When these tasks are carried out in an open office environment, the risk of unauthorized access increases significantly.

This is particularly important for functions such as the CISO or the Security Operations Center (SOC), where staff may be dealing with ongoing incidents, threat intelligence, or forensic data. Such information should never be visible or overheard in an environment where guests, contractors, or even other employees without clearance can pass by.

The classic example is “shoulder surfing” – someone glancing at sensitive content on a screen. Equally problematic is the risk that confidential conversations are overheard. 

Another often overlooked risk is sound leakage: in open-plan offices, a customer on the phone may also hear conversations from nearby desks, unless very advanced headsets with strong noise isolation are used. This means sensitive discussions between colleagues can unintentionally be shared with external parties.

ISO 27001:2022 – why open-plan is a problem

ISO 27001:2022 highlights several controls that all point to the same issue: sensitive information must be protected from unauthorized access. Open-plan offices make this nearly impossible.

• Physical security perimeters

• Physical entry controls

• Clear desk and clear screen

• Information security in supplier relationships

Real-life scenarios show how quickly security can fail in relation to these controls:

• a visitor waiting for a meeting can easily photograph notes, diagrams, or printouts left on a desk

• a contractor or job candidate passing by may glimpse a screen just as someone opens an attachment, without realizing the first page contains confidential information

• when an IT employee locks their computer to get a coffee or use the restroom, they may leave documents on their desk – one quick smartphone photo is enough to capture that information permanently

• suppliers or service providers moving through the office may unintentionally gain visibility into data they should never have access to

It is also worth noting that other standards and frameworks – such as GDPR, NIS2, NIST, CIS Controls, and NSM grunnprinsipper (Norway) – point in the same direction, emphasizing the need for physical protection of sensitive information and controlled access to workplaces.

Other departments should also reconsider

It is not only IT that should think twice about open-plan setups. Departments handling sensitive information face similar risks, for example:

• HR – managing personal data, employment contracts, and health-related information

• Legal/Compliance – working with confidential documents and internal investigations

• Finance – handling accounting, banking, and budget data

• Executive/Strategy – discussing mergers, strategic plans, or other confidential information

• Research & Development – working on products, designs, or innovations that may be patented or involve intellectual property

• Customer support – handling customer records, tickets, and sometimes payment details

• Project teams for mergers & acquisitions – where leaks can have major financial consequences

All these functions risk exposing information if their workspaces are too open and accessible.

Real-world observations

When walking the streets of Oslo or Bergen, I often see offices on the ground floor with large windows facing the street. It is surprising how easy it is to see what people are working on. With today’s smartphone cameras, it takes no effort to take pictures or record video from the sidewalk – or even from a hotel room across the street.

The question is: do these companies think about security at all? It is frighteningly easy for outsiders to gain insight into customer data, accounting systems, or even online banking screens.

Conclusion

Open-plan offices can bring real benefits such as collaboration, flexibility, and stronger team dynamics. But for departments dealing with sensitive information – especially IT – the risks outweigh the benefits.

An IT department should therefore never sit in an open-plan office if guests, contractors, or even passersby can gain visibility. The same applies to HR, Legal, Finance, R&D, Customer Support, and Executive functions.

Physical segregation is not only common sense – it is a requirement for ISO 27001 compliance and a cornerstone of a strong security culture.

When documentation becomes the breach

 

I love documentation—and I recommend documenting a lot. It creates memory, clarity, and resilience. But attackers love it too. Over time, spaces like confluence and sharepoint collect shortcuts, “temporary” exceptions, and helpful screenshots. Alone they look harmless. Together, they can map how to step around controls.

👀 What attackers actually use

• Notes that describe how to “temporarily” bypass checks

• Mentions of shared or test accounts used “for convenience”

• Hints about remote access, allow-lists, or quick openings “for support”

• Screenshots that reveal settings, approval flows, or who to ask

• Exported lists of users, systems, or internal locations

• Attachments with no owner, no classification, and no review date

• Links set to “anyone with the link,” often without an expiry

• Scripts, runbooks, and “how-to” guides that include sensitive internal details

🧩 Why this keeps happening

• Helpful people share broadly so others aren’t blocked

• “Just for now” files never get cleaned up

• MFA is not enforced

• Shared users survive because they’re easy

🔐 Simple habits that help (zero trust)

• Put things where they belong: secrets in a password vault, code in source control, configs in the right system—not in the wiki

• Use SSO and MFA for confluence and similar tools; limit or disable local passwords where the platform supports it (especially for admins)

• Grant access to named groups, not “anyone with the link,” and give links an expiry

• Require an owner, purpose, and review date for sensitive pages and attachments

• Avoid screenshots of sensitive settings; document outcomes instead

• Review sharing regularly and close what’s no longer needed

✅ Bottom line: Wikis should explain how we work—not how to work around controls. Keep them clean, and zero trust becomes a daily habit, not a slogan.

Without IT asset management, cyber security becomes guesswork

 

🙏 Begin your IT security journey at the beginning, not in the middle.
Too many organizations jump straight into firefighting—patching vulnerabilities, responding to incidents, and buying new tools—without ever laying the foundation. The foundation is always IT asset management (ITAM). Without it, everything else is largely built on assumptions.

💾 Think about it: you wouldn’t order a backup server without knowing how much or what data you need to protect. And you wouldn’t buy a firewall without knowing what it is supposed to defend, or how much traffic it must be able to handle. The same logic applies to cyber security as a whole—you must start with ITAM, or everything else becomes guesswork.

👀 You cannot protect what you cannot see.
Without updated and reliable ITAM, risk assessments quickly turn into theory detached from reality. Many organizations say they have X critical systems, and that sounds reassuring. The problem is the Y systems they don’t know about—the ones set up by someone years ago, without documentation, still running in the background, and still connected to the network. X represents the assets you know and track, while Y represents the shadow IT: the forgotten, hidden, or undocumented systems that pose just as much risk, if not more.

⚽ It is a bit like football: to build a strong team, the coach must know exactly which players are on the field, their positions, and their strengths. Only then can he create a winning strategy. ITAM works the same way—without a complete view of all systems, you cannot build a secure IT environment that functions as a well-organized team.

🌐 Whether the environment is on-premises or in the cloud makes little difference; the challenge is the same.
You must know what you have before you can assess whether it is secure or not.

⚠️ At minimum, every device with an IP address must be accounted for.
But the real goal must be to cover all assets—including OT equipment and sensors that may not have their own IP address yet still impact operations and security. Without this broader view, the inventory remains incomplete and the risk picture distorted.

🔑 Frameworks agree:

• Norway’s NSM grunnprinsipper call for complete and updated asset overviews.

• ISO 27001 requires organizations to identify, classify, and manage assets throughout their lifecycle.

• The CIS framework starts with Inventory and Control of Enterprise Assets as Control 01—the very first step toward building a secure baseline.

🚢 Maritime regulations agree too:

• IMO 2021 requires cyber risk management to be integrated into the ship’s Safety Management System (SMS). A key part of this is maintaining an up-to-date inventory of all systems and assets as the basis for risk assessment.

• IACS UR E26 (mandatory for newbuilds contracted from July 2024) demands a complete inventory of hardware and software, along with network diagrams and lifecycle documentation, to ensure cyber resilience of ships.

✅ The message is clear: without ITAM, cyber security is reactive and based on assumptions. With ITAM, zero trust becomes possible, measurable, and sustainable.

PANOS 12.1 ORION installation on PA-440 and Panorama

PANOS 12.1 ORION installation on PA-440 and Panorama

Bad start on the Panorama for me:
Failed to create required free space. Free space: 2778 MB, Required space: 3717 MB


Found a guide for cloning Panorama disk to a new and larger disk. Only used 15 minutes to clone and remove the old disk.
https://docs.paloaltonetworks.com/panorama/10-2/panorama-admin/set-up-panorama/set-up-the-panorama-virtual-appliance/increase-the-system-disk-on-the-panorama-virtual-appliance/increase-the-system-disk-for-panorama-on-an-esxi-server#id27229f7c-6701-4fef-9ad7-cb630ea5cbcb

 

Guide worked perfect and I booted up Panorama with free space available.




PA-440:

Reboot take about 15 minutes.
....and some more waiting time before login is up and running.

Welcome to PAN-OS 12.1!

With this release, Palo Alto Networks extends and improves your security posture with our innovative approach. PAN-OS 12.1 provides passwordless authentication capabilities, additional quantum protections, expanded Device-ID capabilities, decryption enhancements, and more. Highlights include:

Passwordless Authentication for Kerberos Protected Applications—Enables your Palo Alto Networks firewall to act as a Kerberos Constrained Delegation (KCD) agent. This feature allows seamless access to enterprise applications using Kerberos authentication, eliminating the need for users to repeatedly enter credentials. Enhances security by reducing password-related vulnerabilities and improves productivity by streamlining access to multiple Kerberos-protected applications.

Quantum Key Distribution (QKD)—Provides protection for VPN key exchanges by using the ETSI GS QKD 014 standard, QKD, to provide a set of standardized API calls that enable a PAN-OS firewall to communicate with and request symmetric encryption keys from a QKD Device. The PAN-OS firewall acts as the secure application entity (SAE) device and makes API calls to the QKD device, called the key management entity (KME). Depending on the QKD vendor’s implementation, you can use TLSv1.3 to secure the key generation process.

Advanced Device-ID—Enables more granular and precise device-based policy recommendations by enhancing the existing Device-ID functionality. Advanced Device-ID enables the creation of least-privilege access policies by creating device object groupings based on device attributes. With Advanced Device-ID, you can now create more complex Device-ID objects by matching grouping criteria using multiple asset categories and attributes (10x more than before) such as asset type, device profiles, operating systems, site, location, subnet, risk, internet access, and user tag to match assets and enforce security policies based on changing security posture.

Post-Quantum Cryptography (PQC) SSL Support for PAN-OS Management—Supports PQC in TLSv1.3 for administrative access to firewalls and Panorama and facilitates a smooth adoption of PQCs as a proactive defense against PQC threats. This feature prioritizes maximum interoperability and adaptability to future PQC updates. You can also generate self-signed certificates with the NIST-approved digital signatures, ML-DSA and SLH-DSA (based on SPHINCS+), for experimental use as the industry works toward a standard approach for PKI certificates.

Post-Quantum Cryptography (PQC) Cipher Support for TLSv1.3 Inline Decryption—Enables PQC cipher support in TLSv1.3 for SSL Forward Proxy and SSL Inbound Inspection, as well as the decryption mirror and Network Packet Broker features. You can now use PQC preferred ciphers in the decryption profile either for client session, server session, or both. This flexibility allows for post-quantum migration as either the client or server side could be first to adopt PQCs and this feature supports cipher translations across the client and server sessions of the decryption proxy. You can also elect to negotiate Standard (ML-KEM) and/or Experimental (BIKE, Frodo, HQC) ciphers to support NIST and EU requirements allowing for Crypto Agility of ciphers as required.

Decryption Simplification—New options have been added to decryption functionality to simplify certificate verification and log analysis. For example:

Use the new Bypass Server Certificate Verification option in decryption profiles to disable the verification of server certificates, so that the firewall can decrypt outbound SSL traffic from an internal client to the web. This ensures the availability of websites and applications without compromising deep packet inspection for threats during SSL Forward Proxy sessions when servers present incomplete or invalid SSL certificates.

More easily analyze log entries and troubleshoot decryption issues using the new columns provided. For example, Decryption Status lists the reason a session was or was not decrypted, whether by failure or design. In addition, new and existing columns that concern one side of a decrypted session are labeled with client or server if conditions apply to only one or the other.

Zero Touch Provisioning (ZTP) for Cellular—Enables automated deployment and configuration of NGFW in remote locations with limited connectivity or lacking traditional wired connections using cellular interfaces. With the expanded support for cellular connections, ZTP now supports multiple connectivity scenarios, including cellular-only, ethernet-only, or both to provide the flexibility to adapt to various network environments. The feature is designed to work with current and future 5G-enabled platforms, ensuring long-term value and adaptability as your network evolves.

For descriptions of the new features, associated software and content releases, changes in default behavior, and other release information, refer to the PAN-OS 12.1 Release Notes.

HA/failover with one NGFW in PANOS 12.1.2 and one NGFW in 11.1.10-h1 worked in my test.

I really like the new report, telling me what I need to fix, and how!

Certificates seems to have an update, great news, maybe SSL decrypt works better now.

New AI Security profile, this can be fun.

 

Was hoping for more SD-WAN updated, didn't find anything so far.

CVE-2024-3400 - IP list

I recommend blocking incoming traffic from this EDL IP list to all your public IPs, not just to your GlobalProtect portal.

My EDL IP update:
https://edl.nyggen.com/EDL-Bad-IP-CVE-2024-3400.txt

IP list from https://unit42.paloaltonetworks.com/cve-2024-3400/
110.47.250[.]103

126.227.76[.]24

38.207.148[.]123

147.45.70[.]100

199.119.206[.]28

38.181.70[.]3

149.28.194[.]95

78.141.232[.]174

38.180.128[.]159

64.176.226[.]203

38.180.106[.]167

173.255.223[.]159

38.60.218[.]153

185.108.105[.]110

146.70.192[.]174

149.88.27[.]212

154.223.16[.]34

38.180.41[.]251 

203.160.86[.]91

45.121.51[.]2

IP list from my finding at 20.04.24 at 19.30 CEST

185[.]174[.]137[.]26

34[.]78[.]95[.]130

88[.]119[.]169[.]230

34[.]22[.]176[.]97

188[.]166[.]87[.]88

159[.]65[.]33[.]252

207[.]246[.]68[.]214

151[.]236[.]29[.]58

94[.]156[.]65[.]141

104[.]248[.]129[.]202

138[.]68[.]44[.]59

158[.]247[.]247[.]86

104[.]248[.]29[.]170

185[.]104[.]194[.]47

193[.]32[.]126[.]136

45[.]89[.]55[.]162

139[.]59[.]241[.]148

146[.]70[.]105[.]138

68[.]183[.]230[.]252

128[.]199[.]166[.]165

143[.]198[.]59[.]79

IP list from my finding at 20.04.24 at 20.30 CEST

189[.]206[.]227[.]226

5[.]42[.]92[.]152

168[.]100[.]8[.]13

165[.]227[.]44[.]48

189[.]206[.]227[.]150

18[.]143[.]129[.]154

170[.]64[.]230[.]1

37[.]19[.]218[.]176

1[.]53[.]51[.]174

23[.]227[.]194[.]230

198[.]13[.]35[.]229

202[.]44[.]54[.]13

103[.]113[.]8[.]101

192[.]46[.]208[.]206

34[.]118[.]89[.]45

34[.]77[.]8[.]21

34[.]118[.]19[.]13

104[.]28[.]215[.]70

178[.]128[.]212[.]140

139[.]180[.]210[.]69

207[.]180[.]246[.]67

94[.]156[.]68[.]4

38[.]60[.]212[.]206

101[.]99[.]91[.]107

154[.]88[.]26[.]223

111[.]185[.]242[.]156

144[.]91[.]66[.]213

172[.]232[.]148[.]32

154[.]90[.]49[.]108

103[.]15[.]29[.]171

202[.]182[.]105[.]189

45[.]76[.]163[.]154

78[.]141[.]241[.]7

42[.]114[.]205[.]128

104[.]46[.]193[.]46

106[.]104[.]162[.]35

146[.]70[.]116[.]201

193[.]56[.]113[.]69

45[.]32[.]156[.]173

167[.]99[.]96[.]133

140[.]120[.]136[.]11

23[.]158[.]104[.]193

193[.]56[.]113[.]9

206[.]166[.]251[.]43

185[.]246[.]189[.]97

104[.]168[.]145[.]244

123[.]192[.]168[.]60

58[.]69[.]38[.]83

85[.]66[.]8[.]187

45[.]11[.]59[.]136

23[.]94[.]158[.]73

58[.]69[.]38[.]126

203[.]160[.]72[.]245

154[.]16[.]192[.]50

165[.]22[.]111[.]168

185[.]239[.]69[.]159

140[.]82[.]63[.]209

42[.]119[.]60[.]242

146[.]70[.]143[.]142

193[.]43[.]104[.]199

5[.]182[.]211[.]148

107[.]155[.]55[.]118

8[.]208[.]45[.]145

8[.]208[.]112[.]87

45[.]61[.]150[.]2

66[.]42[.]55[.]167

115[.]78[.]224[.]54

Rethinking digital security beyond just Telegram

Telegram har lenge vært i søkelyset for sikkerhetsbekymringer, noe som har ledet mange bedrifter til å blokkere appen. Men dette langvarige fokuset mangler en viktigere innsikt: Vi må være bevisste på sikkerheten til alle digitale verktøy vi bruker, ikke bare Telegram.

Mange apper, som Facebook, Instagram, TikTok, og Snapchat, samler inn store mengder brukerdata. Dette inkluderer ikke bare grunnleggende personlige detaljer som navn og e-postadresse, men også lokasjonsdata, søkehistorikk, kjøpshistorikk, kontaktlister, SMS-innhold, samt detaljer om hvem du kommuniserer med og hvordan du interagerer med innhold på nettet. Denne omfattende datainnsamlingen kan ikke bare avsløre dine personlige preferanser og vaner, men også potensielt sensitive informasjoner som kan utnyttes for målrettet reklame, sosial manipulasjon, eller mer alvorlige former for cyberkriminalitet.

For de som arbeider med sensitiv informasjon innen helsevesenet, juridiske tjenester, journalistikk, IT-sikkerhet, finansanalyse, og HR, er risikoen spesielt høy. En utilsiktet lekkasje av informasjon i disse yrkene kan føre til identitetstyveri, økonomisk tap, eller skade på personers liv og karrierer.

For å beskytte sensitiv informasjon effektivt, bør de i sensitive roller begrense bruken av potensielt risikofylte apper til et minimum, og kun bruke apper som er godkjent av IT-avdelingen. Dette, kombinert med regelmessig opplæring i digital bevissthet og oppdatering av sikkerhetspraksiser, vil styrke forsvar mot digitale trusler.

Security in layers

Sikkerhet legges i lag!

Å stole utelukkende på et antivirusprogram er ikke (og har aldri vært) tilstrekkelig.

For å effektivt beskytte våre digitale eiendeler, må vi utnytte et bredt spekter av sikkerhetstiltak. Ved å integrere brannmurer, kryptering, nettverkssegmentering, endepunktbeskyttelse, Group Policy Objects, e-postfiltrering, adferdsanalyse, tilgangskontroll, og dekryptering for inspeksjon av trafikk, kan vi bygge en mer omfattende forsvarslinje. 

I tillegg er sikkerhetsbevissthetstrening for ansatte avgjørende for å styrke det menneskelige leddet i sikkerhetskjeden. 

Disse lagene av sikkerhetstiltak arbeider sammen for å forme en robust sikkerhetsarkitektur som er i stand til å stå imot og tilpasse seg det stadig skiftende landskapet av cybersikkerhetstrusler.

Det er viktig å merke seg at dette er eksempler på sikkerhetstiltak; ulike organisasjoner kan ha tilgang til forskjellige "lag" av sikkerhet basert på deres spesifikke behov og ressurser, eller de kan implementere andre sikkerhetsstrategier som også er effektive. Tilpassing og fleksibilitet i sikkerhetsstrategien er nøkkel til å møte din organisasjons unike utfordringer.

Nothing is free (part 2)

 

Jeg har skrevet om at "ingenting er gratis" før,

her på https://www.mrlogg.no/2022/12/nothing-is-free.html

Grunnen til at jeg tar det opp igjen er at dette er viktig, har du f.eks. Virustotal.com åpen og en ansatt laster opp et viktig dokument for virus sjekk der så ligger dokumentet tilgjengelig for alle som vil laste det ned.

En noe uoffisielt test viser at en fil som ble lastet opp på virustotal ble lastet ned igjen fra forskjellige verdensdeler hele 9 ganger på de første 3 timene filen lå tilgjengelig.

Hva om en ansatt laster opp dokumenter som inneholder sensitiv informasjon om en av dine kunder?
Eller informasjon om et nytt produkt din bedrift jobber med? 

Risikoen for at denne informasjonen kommer på avveie er høy. 

Det er derfor essensielt å forstå at selv om tjenester som Virustotal tilbyr en verdifull ressurs for å sjekke filer for skadelig programvare,
må man være ekstremt forsiktig med hvilke dokumenter man velger å laste opp.

For bedrifter er det viktig å implementere strenge retningslinjer for bruk av slike tjenester og 

ansatte bør opplæres i sikkerhetsrisikoer knyttet til deling av filer og informasjon på Internett.

Palo Alto Networks sin brannmur kan også hjelpe deg litt på vei men å ha et Block eller Continue varsel på slike sider. 

PaloAltoNetworks - IoT

Gjør nettverket ditt sikrere med mikro-segmentering.

Mange virksomheter undervurderer mangfoldet av enheter som kjører på deres nettverk, ofte plassert innenfor samme VLAN, noe som kan føre til unødvendige sikkerhetsrisikoer og nettverks-belastning. Mikro-segmentering, prosessen med å dele opp nettverket i mindre, sikrere VLAN er basert på utstyrets funksjon, er nøkkelen til å forbedre både sikkerheten og ytelsen.

For de som ønsker å få en rask oversikt over nettverkets sammensetning og identifisere potensielle forbedringsområder, anbefales en IoT-lisens fra Palo Alto Networks. Denne lisensen kan aktiveres som en prøveperiode på brannmurene deres, og tilbyr en fantastisk kartlegging av tilkoblede enheter i løpet av få dager. Ved å utnytte denne innsikten kan virksomheter ta informerte steg mot en mer segmentert og sikker nettverkstruktur.

Her er et eksempel på hvordan du kan dele opp nettverket ditt for optimal sikkerhet og effektivitet, inspirert av faktiske behov og beste praksiser.

1. Alarmsystemer VLAN: Normalt har tilgang til overvåkningssentraler og sikkerhetsadministrasjonssystemer for å sende alarmer og statusoppdateringer.

2. Applikasjonsserver VLAN (per unik enhetstype): Gir tilgang til databaser og andre back-end systemer nødvendige for applikasjonens funksjonalitet, samt utviklings- og testmiljøer for oppdateringer.

3. Backup VLAN: Har tilgang til lagringsnettverk og administrasjonssystemer for sikkerhetskopiering og gjenoppretting av data.

4. Betalingsenheter VLAN: Kobles til transaksjonsbehandlere og banknettverk, med streng tilgangskontroll for å oppfylle betalingsindustriens sikkerhetsstandarder.

5. Brukerdatamaskin VLAN: Har tilgang til internett, interne applikasjoner, e-posttjenester, og delte ressurser som filservere og skrivere.

6. Domene Kontroller VLAN: Interagerer med servere og endepunkter innen organisasjonen for autentisering, autorisering og policyhåndheving.

7. E-postserver VLAN: Kobles til internett for inn- og utgående e-post, samt interne brukere for e-posttilgang.

8. Gjestenettverk VLAN: Begrenset tilgang til internett og eventuelt noen offentlige tjenester tilbudt av organisasjonen, uten tilgang til interne systemer.

9. HVAC VLAN: Har tilgang til bygningsadministrasjonssystemer og eventuelt eksterne vedlikeholdstjenester for overvåking og styring.

10. Microsoft SQL Server VLAN: Gir tilgang til applikasjonsservere som krever databasetjenester, samt  administrasjonssystemer.

11. Møteromsteknologi VLAN: Kobles til presentasjonsutstyr, konferansesystemer, og utvalgte eksterne videokonferansetjenester.

12. MySQL Server VLAN: Tilbyr databasetjenester til web- og applikasjonsservere, samt tilgang til utviklingsverktøy.

13. NAS/SAN VLAN: Tilgjengelig for servere som krever lagringstjenester, backup-systemer, og administrasjonsverktøy.

14. Oracle Server VLAN: Gir databasetjenester til applikasjonsservere som trenger høy ytelse og pålitelig datalagring, med tilgang til databaseadministrasjonsverktøy.

15. Partner VLAN: Tilgang begrenset til spesifikke tjenester og systemer som kreves for samarbeid eller integrasjon med partnerorganisasjoner.

16. PostgreSQL Server VLAN: Serverer databasetjenester til applikasjoner, med tilgang til utviklings- og test-verktøy.

17. Printer VLAN: Gir utskriftstjenester til brukerdatamaskiner og møterom, med administrativ tilgang for vedlikehold og overvåking.

18. Sikkerhetskamera VLAN: Har tilgang til videoovervåkingsstasjoner og sikkerhetsadministrasjonssystemer for opptak og overvåking.

19. Smart Lighting Systems VLAN: Kobles til bygningsadministrasjonssystemer for styring og overvåking av belysning, med potensiell ekstern tilgang for vedlikehold.

20. Smartbygg/IoT-enhet VLAN (per unik enhetstype): Isolert tilgang til spesifikke styringssystemer og vedlikeholdstjenester dedikert for hver enhetstype.

21. Testmiljø VLAN: Gir tilgang til utviklings- og applikasjonsservere for testing av nye applikasjoner og oppdateringer under kontrollerte forhold.

22. Trådløse Tilgangspunkt (AP) VLAN: Serverer trådløs tilkobling for enheter, med tilgang til internett og interne nettverksressurser basert på brukerrettigheter.

23. Utviklingsmiljø VLAN: Tilgang til utviklingsverktøy, kodearkiver, og interne testservere for applikasjonsutvikling og -testing.

24. VoIP VLAN: Kobles til VoIP-servere og telefonsystemer for intern og ekstern talekommunikasjon, med kvalitetssikring for taletrafikk.

25. Webserver VLAN (per unik enhetstype): Gir webtjenester til interne og eksterne brukere, med tilgang til relevante backend-systemer og internett for utvalgte nettsteder.

Trust Through Verification

Fra Zero Trust til Trust Through Verification:

"Zero Trust" er et begrep som ofte misforstås som en sikkerhetsstrategi som indikerer en grunnleggende mistillit til alle. I virkeligheten fokuserer det på kontinuerlig verifisering for å sikre nettverk, enheter, og tilgang til skytjenester. For å fremme en bedre forståelse, kan det være nyttig å vurdere en endring til begrepet "Trust Through Verification". 

Vanlige mistolkning av Zero Trust:

Feiltolkningen her er at Zero Trust-prinsippet innebærer en grunnleggende mistillit til ansatte eller medlemmer av en organisasjon. I virkeligheten fokuserer Zero Trust på nødvendigheten av å verifisere tilgang til systemer og data for å beskytte mot sikkerhetstrusler. Det handler ikke om personlig mistillit, men om å anerkjenne at trusler kan komme fra hvor som helst.

Kritikere mener at Zero Trust-strategier er uforenlige med en kultur av gjensidig tillit, og at det skaper en 'militærstruktur' hvor hierarki dominerer over gjensidighet. Dette perspektivet overser at Zero Trust primært er et teknisk sikkerhetskonsept som sikter mot å minimere risiko for datalekkasjer og angrep. Det er designet for å styrke, ikke svekke, den organisatoriske tilliten ved å etablere klare og rettferdige sikkerhetsprotokoller som beskytter alle i organisasjonen.

En annen vanlig misforståelse er at implementering av Zero Trust automatisk fører til en overvåkingsintensiv tilnærming som kompromitterer personvernet. Selv om Zero Trust krever detaljert logging og overvåking av nettverksaktivitet, er målet å sikre datatilgang basert på nødvendighet og minste privilegiums prinsipp, ikke å overvåke ansatte unødvendig.

PaloAltoNetworks - GlobalProtect

 

Det kan være utfordrende å sette opp GlobalProtect og det kan gjøre på forskjellige måter så her viser jeg litt hvordan det er satt opp hos meg.

Her er noen av feilmeldingene jeg har hatt og som er løst med mitt nåværende oppsett:
PanHttpsClient: 1738, found exception
The network connection is unreachable
Gateway does not exist

Har også hatt noen tilfeller at noen Android enheter får koblet opp på GlobalProtect, andre ikke.

Sertifikater laget på brannmuren har noen ganger gitt meg problemer så jeg laget et gratis (90dagers) via https://app.zerossl.com/certificate/new 

Jeg har importert 350 sertifikater fra før så om du mangler de 3 andre så legg inn dem også.

Så må en ha en SSL / TLS Service Profil. Hos meg ser den slik ut:

Jeg har laget meg en Auth Sequence slik at om jeg logger på med noen utvalgte brukere så får jeg MFA via Jumpcloud, men på andre bruker (mobil til ungene) så er det ikke MFA krav. 

GlobalProtect Gateway

GlobalProtect Portal

I tillegg har jeg selvfølgelig en sikkerhets regel som sier at bare noen utvalgte land/Regions kan koble opp mot min GlobalProtect.