Ivanti Blog: Posts by

Trusted Ownership: How Ivanti Application Control scales beyond allowlisting

Wed, 25 Feb 2026 14:25:15 Z

Application control is one of those security topics where many people carry old assumptions. Traditional allowlisting feels safe but quickly becomes a maintenance burden. Blocklisting feels reactive and incomplete. And while tools like Microsoft AppLocker led many to believe that strict allowlisting is the gold standard, modern attacks have proven otherwise. Attackers increasingly rely on legitimate, signed tools — used in the wrong context — to bypass list-based controls entirely.

So when organisations evaluate Ivanti Application Control or Ivanti Neurons for App Control and encounter Trusted Ownership, it may initially resemble blocklisting because explicit blocks are possible. In reality, Trusted Ownership is a far broader and far lighter operationally inspired‑ enforcement model that controls execution based on origin, not just identity.

Instead of managing expanding lists, it enforces security on who has placed software on the system, aligning cleanly with modern software distribution practices and zero trust principles. It’s best understood not as another list mechanism, but as a provenance inspired enforcement model that controls execution based on origin, not just identity.

That shift in thinking leads to a better question for modern application control: not only what a file is, but how it got there.

Beyond lists: why provenance control now matters

The question of how a file arrived on the system is at the core of provenance control. Instead of trusting files based on publisher, path or hash alone, provenance control evaluates the origin and process that introduced them. Who wrote the file to disc? Through which mechanism? Did the installation follow a controlled IT workflow? This evaluation shifts application control from object trust to process trust, creating a far stronger security boundary.

In Ivanti Application Control, provenance control is implemented as Trusted Ownership. Any file placed by a trusted owner is allowed; anything introduced by a user is denied by default. This applies consistently across executables, DLLs, installers and scripts. Because identities like SYSTEM, TrustedInstaller and Administrators are trusted by default, software delivered through standard deployment channels such as MS Intune, MECM, Ivanti Endpoint Manager (EPM)or other enterprise tools runs immediately without rule maintenance or exceptions.

This marks a fundamental break from classic allowlisting. AppLocker rules live or die based on exact publisher, path or hash definitions. It doesn't evaluate installation origin and doesn't automatically trust your deployment mechanisms. Software delivered by Intune still requires a preexisting allow rule, often relying on broad defaults that permit the Programme Files or Windows directories.

That distinction matters because modern attacks increasingly weaponize legitimate tools in improper contexts. Provenance control neutralises much of that risk by enforcing trust in how software arrives, not just what it is. It aligns with zero trust principles, reduces supply chain exposure, and dramatically narrows opportunities for Living off the Land (LotL) abuse by default.

Once you understand the importance of origin, the next question becomes: how do you enforce it at scale?

The answer: apply provenance consistently across all the ways software executes and all the ways it is delivered.

Beyond Blocklists: Broad coverage built for modern software deployment

Provenance control shifts application security away from managing endless lists and toward validating the process by which software arrives on the system. Once you adopt this perspective, it becomes clear that Trusted Ownership is not a blocklist approach. It's an origin-based trust boundary that behaves very differently from traditional allowlisting.

A common misconception is that Trusted Ownership resembles blocklisting because administrators sometimes add targeted deny rules for well-known Windows tools. In practice, these deny rules are defensive hardening measures against Living off the Land techniques. Every serious application control method uses such targeted restrictions. The core of Trusted Ownership is the opposite of blocklisting. Software delivered through a controlled and trusted process is permitted by default, while user-introduced content is denied by default.

A more important differentiator is coverage. Many organisations that rely on classic allowlists end up focusing almost entirely on executable files. They often avoid applying the same enforcement to DLLs, scripts and MSI packages because these file types make rule maintenance far more complex. This creates gaps that modern attackers frequently exploit.

Trusted Ownership avoids these gaps by applying the same origin-based enforcement to the full execution chain. Executables, DLLs, scripts, MSI installers and related components are evaluated through the same trust model. Because trust is determined by who introduced the file, you do not need separate policies for each file type. A script in the Downloads folder, a DLL created in a temporary build directory or an EXE executed from a user profile all receive the same default deny treatment when they originate outside a controlled installation process.

This trust model also aligns naturally with how modern endpoint management platforms deliver software. Solutions such as Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager and similar systems typically instal applications using the SYSTEM identity or another trusted service account.

Since these identities are already Trusted Owners, software deployed through these channels runs immediately without creating allow rules, maintaining file paths or updating policies. Only when you intentionally use alternative installation accounts, such as custom DevOps agents or scripted installations in user context, do you need to identify that identity as a Trusted Owner.

The result is a model with broad and consistent coverage across all relevant file types. It works seamlessly with modern software distributions and avoids the operational overhead associated with classic allowlists that focus mainly on executable files.

Trusted Ownership places trust not in individual objects but in the controlled processes through which software is delivered, creating a more scalable and more secure approach to application control.

Where WDAC (App Control for Business) fits in

Microsoft maintains two application control technologies: AppLocker and App Control for Business (formerly WDAC). Although both still exist, Microsoft is clear about their roles. AppLocker helps prevent users from running unapproved applications, but it does not meet the servicing criteria for modern security features and is therefore categorised as a defense-in-depth mechanism rather than a strategic security control.

Microsoft’s forward path for application control is App Control for Business and explicitly states that AppLocker is feature-complete and no longer under active development, beyond essential security updates. This means all new capabilities are delivered only in WDAC and not in AppLocker.

App Control for Business introduces the Managed Installer concept. This allows Windows to automatically trust applications installed through designated deployment platforms such as Intune or MECM. Trust is derived from the distribution channel rather than individual files, reducing rule maintenance significantly.

This aligns closely with Ivanti Application Control’s Trusted Ownership model. Both approaches trust software based on the controlled process that installed it rather than on discrete file attributes. However, Trusted Ownership applies this concept in a simpler and more operationally accessible way. Ivanti trusts identities such as SYSTEM and designated service accounts without requiring complex policy layers, XML definitions or deep WDAC expertise.

Ivanti hears from many organisations that they struggle to operationalize WDAC. WDAC policies require careful design, lengthy testing in audit mode, driver and kernel exception management and ongoing maintenance of multiple policy sets. This often leads organizations to combine WDAC with AppLocker to cover both low-level enforcement and day-to-day user space control and end up with administrative overhead.

Ivanti Application Control offers a unified alternative. Through Trusted Ownership, Trusted Vendors and digital signature validation, it delivers a provenance-based default deny model with consistent coverage across executables, DLLs, scripts and MSI packages.

Instead of maintaining two MS control planes with different scopes, organisations manage a single, streamlined policy that enforces trust based on how software is introduced into the system. This provides many of the practical goals customers attempt to achieve with a combined WDAC and AppLocker deployment, but with lower operational complexity and one cohesive trust model.

LOLBins and argument-level control

With broad coverage established, the issue then becomes how to handle the legitimate tools already on every machine that attackers like to abuse.

Modern attackers often avoid using traditional malware and instead rely on the tools already present on every Windows device. These Living off the Land tools (LOLBins) are legitimate and necessary for normal operations, which makes them difficult to block without affecting productivity. Traditional allowlisting struggles here because broad blocking breaks workflows, while broad allowing leaves dangerous gaps.

A provenance-based model such as Trusted Ownership changes this dynamic. Even if an attacker attempts to use a built-in tool, the content they try to run usually does not come from a trusted installation process. Since Ivanti evaluates the origin of that content, most misuse attempts fail automatically. The tool may be legitimate, but the content it is asked to run is not, and Trusted Ownership stops it before it executes.

It is also important to understand not only which tools run but what they are being asked to do. Many interpreters and runtimes, such as PowerShell, Python, or Java, can be perfectly safe in one context and risky in another. A business application may rely on Java to start a specific, approved process, while a user downloaded JAR file is an entirely different scenario.

Ivanti handles this through a layered approach. A JAR file is first evaluated using Trusted Ownership, which blocks it immediately if it was introduced by a user rather than through a controlled deployment process. Beyond that, administrators can create simple allow rules that specify exactly which Java commands are permitted, ensuring that only legitimate Java based applications run while attempts to launch unapproved JAR files are quietly denied.

The same principle applies across other tools as well. Policies can approve the exact behaviour your organisation needs while blocking activities that fall outside those boundaries. This avoids broad, brittle rules and keeps daily work running smoothly.

The result is a balanced and modern approach. Trusted Ownership stops untrusted content by default. Focused hardening aligns with government and community best practices for reducing living off the land abuse and intent aware controls ensure that legitimate processes continue to function without opening doors for attackers.

This approach closely aligns with current community and government guidance on mitigating living off the land techniques. Agencies such as CISA, NSA, FBI and the Australian Cyber Security Centre emphasise reducing opportunities for attackers to use built-in tools by controlling how they are used and restricting the untrusted content they act upon. Their joint guidance highlights that LOTL attacks depend on abusing native tools and stresses the need for controls that limit this misuse without blocking legitimate system processes.

Ivanti’s model reflects this guidance. Trusted Ownership automatically blocks the untrusted content that attackers rely on, while a small number of focused restrictions address the small set of tools that require extra care.

Trusted Ownership in action: Real-world scenarios

Here are a few operational examples of how Ivanti Application Control and Trusted Ownership work in practice.

A portable application is copied into the user profile. Ivanti blocks it because it is user-owned. AppLocker only blocks if there are matching rules. Without the right path or publisher rules, the behaviour can differ.
An email attachment launches a PowerShell script from Downloads. Ivanti denies it because of user ownership. AppLocker depends on script rules and, on block events, forces PowerShell into Constrained Language Mode, which will still run the script.
Abuse of OS tools such as rundll32 or mshta. Both models need targeted deny hardening. Ivanti combines this with provenance control which generally reduces the number of exceptions you need. AppLocker relies on curated deny sets and requires periodic tuning.
A vendor update ships new signed files. Ivanti allows the update when it arrives via the trusted deployment channel due to Trusted Ownership. AppLocker can accommodate this with publisher rules, but signature reuse across multiple products or unusual instal paths often leads to extra maintenance and broader trust than intended.
A user downloads a JAR and tries to run it with Java. Ivanti blocks the attempt because the JAR is user-introduced and fails Trusted Ownership. If needed, admins can allow only the exact approved invocation by matching the full command line. AppLocker cannot match arguments and relies on publisher, path or hash rules.

Conclusion

Provenance control shifts application control from a management problem to a trust model. Instead of trusting individual files, it trusts the process by which software arrives on a system, making security both scalable and workable.

Trusted Ownership fits squarely into this approach. It is neither a blocklist nor a classic allowlist, but a model where software that arrives through a controlled IT process is allowed by default, while everything outside that process is denied by default. By enforcing on origin and ownership rather than on ad hoc files, Ivanti Application Control and Ivanti Neurons for App Control align far better with modern attack techniques and today’s software distribution.

If you keep treating application control as a list management exercise, you will feel the administrative burden. If you treat it as a trust boundary, you gain scalability, security, and operational workability.

Boards Talk Cybersecurity — but NIS2 Directive Says They Must Own It

Mon, 29 Sep 2025 20:05:33 Z

Cybersecurity finally has a seat in the boardroom. Ivanti’s 2025 State of Cybersecurity research shows that:

89% of organisations now discuss cybersecurity at the board level.
81% of organisations have at least one director with cyber expertise.
88% of organisations include the CISO in strategic meetings.

On paper, that’s progress. But, many organisations struggle to convert board-level attention into sustained, measurable risk reduction.

Ivanti’s data exposes the crux of the problem: only 40% of security teams say risk exposure is communicated to executives “very effectively” — a governance gap with legal and financial consequences under the EU’s NIS2 Directive.

Let’s take a deeper look at the data from Ivanti’s 2025 State of Cybersecurity Report to see what it tells us — and how to turn those insights into NIS2-ready governance.

Why NIS2 changes everything about cybersecurity risk management

NIS2 broadens the EU’s cybersecurity regime to 18 sectors, tightens supervision and — most consequentially — assigns direct accountability to the management body. Boards and senior leaders must approve, oversee and ensure that measures are proper to the risks and effective in practice.

Failure carries consequences: audits, binding instructions and administrative fines up to €10 million or 2% of global turnover. In serious cases, leaders face temporary bans or personal liability.

Rather than a one-size-fits-all checklist, NIS2 expects organizations to prove they manage risk across the lifecycle (analysis, incident handling and continuity, secure development and supply chain assurance, vulnerability management, training and safeguarded communications) in a manner that’s aligned with the state of the art and proportionate to business impact (per Article 21).

Why boards struggle — and what’s at stake

When you translate risk into dashboards of CVE counts, patch rates and tool inventories that obscure business impact, your board of directors misses the CISO’s key points.

Ivanti’s findings crystallise the disconnect: the conversation is happening, yet few feel exposure is conveyed in a way executives can act upon. The result is misguided prioritisation, diffuse budgets and latent exposures that go unaddressed — precisely the scenario NIS2 seeks to prevent.

When things go wrong, costs mount fast. Operational disruption from ransomware, reputational damage, escalating legal exposure and recovery bills often dwarf any administrative fine. With NIS2, ignorance is not a defence; and effective governance requires comprehension, communication and follow-through.

Top cybersecurity risks that demand board attention

Ivanti’s research highlights where organisations are least prepared and most exposed:

Ransomware and AI
End-of-life technology
Supply chain security
Blind spots (e.g., shadow IT)

Each risk below maps to NIS2’s governance expectations. Read on to learn about the threat they pose and how to do better in practice.

1. Ransomware + AI: The perfect storm

The reality from Ivanti’s research: Ransomware still dominates the 2025 threat landscape — and the stakes are rising. Over a third of security professionals (38%) believe AI will make attacks more dangerous, yet only 29% feel very prepared to respond.

This gap reflects a familiar pattern: adversaries accelerate with automation while defenders wrestle with fragmented telemetry, manual processes and untested response playbooks.

How supervisors judge readiness: Under NIS2, resilience cannot be theoretical. Regulators expect response and crisis plans that have been exercised, continuity and recovery targets that are met in practice and preventive controls aligned to business impact (especially identity and patching for critical systems).

When a significant incident hits, the standard is clear: prompt early warnings, coherent follow-ups within mandated windows and visible command of the situation from containment through recovery.

Raise your security posture: Treat ransomware as a recurring business risk, not a rare IT event. Rehearse the first 24–72 hours with top leadership, legal and communications so you can make fast, defensible decisions and produce the evidence a supervisor will ask for.

Don’t just cycle backups — prove restorability of priority services under realistic constraints; tie RTO/RPO directly to revenue and safety. For prevention, orient around exposure: harden and patch critical assets and reduce blast radius with strong authentication, segmentation and least privilege.

When the board asks for assurance, answer in outcomes: “order-to-cash restored in X hours, confirmed quarterly; stakeholder comms aligned to NIS2’s staged reporting.”

2. End-of-life technology: A compliance time bomb

The reality from Ivanti’s research: Over half (51%) of organisations continue to run end-of-life (EOL) software, and one in three organisations say their security is seriously compromised by legacy tech. These legacy blind spots create systemic risk and undermine any claim to state-of-the-art security.

How supervisors judge readiness: NIS2 does not dictate versions, but it does hold you to the principles of appropriateness and state of the art. That means:

You know where EOL sits.
You have a plan to retire it.
You mitigate risk while it stays and you decommission securely — including sanitising data — when it exits service.

Under Article 21, keeping unsupported tech in production without timeboxed, documented mitigations is hard to defend as proportionate risk management.

Raise your security posture: Move EOL from backlog item to board-owned exposure.

Maintain a live inventory that flags support status a year ahead.
Align the retirement path with business owners.
Where delay is unavoidable, approve temporary isolation on the network, restricted access and enhanced monitoring — with clear end dates.
Close the loop with verifiable data sanitization and auditable records at disposal.

Most importantly, price the risk: “This legacy platform drives X% of revenue; extending nine months adds €Y expected loss unless we isolate and monitor it as follows...”

3. Supply chain security: Your weakest link

The reality from Ivanti’s research: Nearly half (48%) of organisations have not identified the third-party systems or components that are most vulnerable in their software supply chains. Many still rely on static questionnaires — time consuming, self-reported and poor at surfacing live risk — particularly for software components and managed providers.

How supervisors judge readiness: Accountability doesn’t stop at the perimeter. Supervisors will look for a defensible method to judge supplier security (including secure development and vulnerability disclosure), contractual duties that mirror that method, ongoing visibility into partner risk (not just annual forms) and the ability to detect and respond when an originating exposure sits with a vendor.

Article 21 makes this explicit: Supply chain security must be risk-based and proportionate. Software security in the supply chain should be a shared responsibility.

Raise your security posture: Start by matching the depth of your security requirements to the risk the supplier introduces to your environment.

A cloud provider hosting critical workloads requires far more stringent controls than a low-impact SaaS tool. For high-risk vendors, demand tangible evidence — SBOM availability, patch and disclosure cadence, participation in coordinated vulnerability disclosure — and make these obligations enforceable in contracts.

Replace one-off surveys with near-real-time indicators, such as exploit telemetry, remediation timeliness and changes in the supplier’s attack surface. Finally, rehearse a supplier-originating incident together: confirm contacts, evidence sharing and public communications that satisfy NIS2’s staged notifications.

4. Blind spots: The hidden risk you can’t manage

The reality from Ivanti’s research: Shadow IT, legacy systems, unmanaged devices and third-party dependencies are persistent blind spots for many organisations.

These gaps slow response, obscure risk and leave organisations exposed to breaches and compliance failures.

How supervisors judge readiness: Article 21 expects organisations to manage risk across the lifecycle — including asset inventory, vulnerability management and supply chain assurance.

Blind spots undermine that mandate. Supervisors will ask: can you prove you know what is in your environment, what’s vulnerable and what is being done about it?

Raise your security posture: Treat visibility as a governance priority, not a technical detail.

Conduct regular attack surface assessments.
Integrate IT and security data.
Use automation to correlate and normalise asset information.
Flag shadow IT, BYOD and legacy systems for board-level review.

Most importantly, tie visibility gaps to business impact: “We lack patch compliance data for X% of endpoints, which affects SLA delivery and regulatory posture.”

Closing the communication gap: What CISOs and boards must do

Forty percent of security teams say IT doesn’t understand their organisation’s risk tolerance — that’s a cybersecurity governance red flag. The board cannot challenge, prioritise or allocate resources without clarity on business impact.

Under NIS2 regulations, the management body needs to exercise informed oversight. The remedy starts with the CISO translating exposures into scenarios the board recognises:

“If we do not update those systems within 48 hours, there’s a very high probability of breach, and the health data of all our clients will be easy to extract. This will hurt our brand, create claims in court and stop our services for days.”

Strong briefings provide a time frame and tie investments to reductions in the top exposures (the exploits that would materially hurt revenue, safety or compliance).

Boards should insist on a compact list of priorities, agree on risk appetite in economic terms and revisit progress quarterly. Over time, that discipline replaces tool-centric updates with a shared narrative of how the attack surface is shrinking and resilience is improving.

Every board deck should answer these three simple questions:

What could go wrong that truly matters?
What are we doing about it?
How will we know it worked?

Anchor measurement to outcomes — time to isolate, time to recover and changes in the top-ten exposures — rather than raw patch or alert counts. When discussing technical debt, attach a price tag: “Keeping this EOL cluster another quarter preserves functionality but adds €X expected loss unless we isolate and monitor it.” That is the language of governance NIS2 expects to see in minutes and in decisions.

Training the board: A NIS2 imperative

The board can only close the communications gap when they really know the subject. NIS2 codifies what many already recognise: the management body needs regular cybersecurity training to discharge its duties.

Effective programmes are pragmatic: They brief directors on evolving threats (such as AI-enabled ransomware and compromised software supply chains), clarify staged reporting and potential liabilities and practice decisions through realistic table-top exercises.

Prioritise sessions that teach directors to read cyber metrics in business terms (e.g., what the exposure picture implies for continuity, customers and compliance) and how to interrogate the plan until it is credible.

Turn training into capability. Make board education a continuous competency, not a one-off seminar. Use short, focused modules that build fluency (e.g., one quarter on exposure prioritisation, the next on supplier oversight and CVD, then one on incident reporting mechanics).

Base each session on a real scenario, like AI-assisted ransomware or a malicious vendor update and capture the specific decisions directors must make. Convert those decisions into concrete governance improvements (updated policies, contract clauses or metrics) so training shows traceable uplift rather than box-ticking.

Close the gap between intent and impact for NIS2-readiness

Ivanti’s research shows encouraging intent — boards talk about cybersecurity, budgets are growing and CISOs have a seat at the table. But, intent does not equal impact.

That same data reveals preparedness gaps for ransomware, stubborn silos that slow response and weaken posture, a long tail of end-of-life technology and opaque supply chain risk that keeps material exposure on the books.

NIS2 raises the bar from conversation to accountability: management bodies must ensure measures are proportionate, state of the art and effective — and they must prove it when incidents occur.

Organisations that close the communication gap, retire or isolate legacy systems on a schedule and replace questionnaire-only oversight with evidence and rehearsal will find they are not only compliant, but resilient.

5 Reasons Why NIS2 Directive Preparation Should Start Now, Part Two: Implementation Takes Time

Mon, 28 Aug 2023 17:43:02 Z

In a previous blog post, I discussed the two main areas to audit before the European Union’s updated Network and Information Security Directive (NIS2) becomes ratified law in October 2024. Specifically, these audits would:

Identify your gaps with the NIS2 directive’s requirements now.

Review your current supply chain security flaws.

Now that we’ve discovered these security flaws, we must fix them — before time runs out in October 2024.

So, in this post, I’ll walk you through how to resolve your weakest security issues before the NIS2 Directive deadline hits by addressing these three key areas:

Inform management about your cybersecurity gaps
Correctly implementing new organisation and technical security measures
Find time to train all of your employees

1. Inform management about your gaps – and get budget to remediate them

The NIS2 Directive imposes significant obligations on organisations that fall under its scope, which may entail substantial costs and resources. The Directive also introduces hefty fines and sanctions for non-compliance, up to a maximum of €10 million or 2% of an organisation's global annual revenue (Article 34).

On top of this, the new directive can extend liability from entities to their individual representatives in certain situations. Moreover, when certain conditions are met, persons in management positions could be temporarily suspended (Article 32-5b).

Therefore, following the NIS2 Directive is a legal necessity and a strategic priority.

To be in compliance, you must:

Inform your management about its implications and benefits and convince them to allocate sufficient budget and resources for implementing compliance.
Present a clear business case that outlines the risks of non-compliance, the opportunities of compliance and the return on investment.
Demonstrate how compliance will enhance your organisation's reputation, trustworthiness, competitiveness and resilience.

Informing management and getting a budget is a challenging task, requiring a persuasive and evidence-based argument that showcases the value of cybersecurity for your organisation.

The sooner you start this process, the more time you’ll have to secure buy-in and support from management.

Possible business case benefits for NIS2 compliance

Some possible benefits that you can highlight in your business case are:

Reducing operational costs by preventing or minimising cyberattack losses, such as downtime, data breaches, ransom payments, lawsuits and so on.
Increasing revenue by attracting or retaining customers who value security, privacy, quality, et cetera.
Improving efficiency by streamlining processes, enhancing performance, reducing errors, etc.
Innovating by adopting new technologies, developing new products or services, creating new markets and more.
Following other cybersecurity regulations or standards beyond NIS2 – such as GDPR, ISO 27001, PCI DSS and others – since global frameworks often have a high overlap with the compliance requirements of NIS2.

Potential information sources for justifying your NIS2 compliance business case

Some sources you can use to support your business case are:

Statistics or facts showing the prevalence, impact or cost of cyberattacks in your sector or region.
Case studies or examples illustrating how other organisations have benefited from complying with the NIS2 Directive or similar regulations. For example, the Enisa NIS Investments 2022 report shows that for 62% of the organisations implementing the older NIS directive, such implementations helped them detect security incidents; for 21%, implementations helped during security incident recovery.
Testimonials or feedback from customers, partners, regulators or experts who endorse or recommend complying with the NIS2 Directive or similar regulations.
Benchmarks or indicators revealing your current or projected cybersecurity performance or progress in relation to the NIS2 Directive or your competitors.
Ivanti’s 2023 Cyberstrategy Tool Kit for Internal Buy-In is also a great resource that explains time-to-functionality and cost, how a solution helps defend against certain types of cyberattacks, and how to react to and overcome common objections.

General business benefits of NIS2 Directive compliance

Some of the benefits of complying with the NIS2 Directive include:

Reducing operational costs by preventing or minimising cyberattack losses, such as downtime, data breaches, ransom payments, lawsuits, et cetera. According to a report by IBM, the average cost of a data breach in 2022 was US$4.82 million for critical infrastructure organisations and the average time to identify and contain a breach was 277 days. If you are taking measures to comply with the NIS2 Directive, the average time spent identifying and containing a breach will be much shorter, and costs of the attack will be lower.
Increasing revenue by attracting or retaining customers who value security, privacy, quality and similar factors. According to a survey by PwC, 87% of consumers say they will take their business elsewhere if they don't trust a company's data practices, and 71% of consumers say they would stop using a company's products or services if they found out it was sharing their data without their permission, which could happen with a data leak.
Improving efficiency by streamlining processes, enhancing performance, reducing errors and so on. Accenture has found that companies that adopt advanced security technologies can reduce the cost of cybercrime by up to 48%.
Complying with other regulations or standards that require cybersecurity, such as GDPR, ISO 27001, PCI DSS or others. Cisco points out that 97% of organisations that follow GDPR see benefits such as gaining competitive advantage, achieving operational efficiency and reducing sales delays. Similar results are probably achievable by following NIS2.

When it comes to budgeting, the proposal for a directive by the European Commission (Anex 7 - 1.4.3) mentions that for companies falling under the scope of the NIS2 framework, it’s estimated they would need an increase of a maximum 22% of their current ICT security spending for the first years following the introduction of the NIS2 framework.

However, the proposal also mentions that this average increase of ICT security spending would lead to a proportionate benefit from such investments, notably due to a considerable reduction in cost of cybersecurity incidents.

2. Correctly implement new organisational and technical security measures

After researching the gaps and obtaining a budget, it’s time to close those gaps. The NIS2 Directive requires companies to implement appropriate organisational and technical measures to manage their cybersecurity risks and ensure a high level of security across their networks and information systems.

These measures include:

Adopting policies and procedures for risk management, incident response, business continuity, data protection, et cetera.
Establishing roles and responsibilities for cybersecurity governance, oversight, coordination and other areas.
Providing training and awareness programs for staff, management, customers, etc.
Implementing basic cyber hygiene such as encryption, authentication (MFA), firewalls, antivirus software, patching, zero trust access and so on.
Conducting regular testing, monitoring, auditing and other measures.

Implementing those organisational and technical measures isn't a one-off or static task. It requires establishing a continuous and dynamic process that adapts to changing threats, technologies, regulations and business needs.

So, the same advice applies for this process as for the other points we’ve already covered: the sooner you start, the more time you'll have to implement the necessary measures and ensure their effectiveness and efficiency.

I would advise starting implementation at least in January 2024, so you’re ready before the summer holidays.

Next steps for NIS2 Directive implementations

Some possible steps that you can take to implement organisational and technical measures are:

Developing and implementing a risk-based management process that defines your objectives, scope, roles, responsibilities, resources, timelines and metrics for managing your cybersecurity risks.
Implementing a security policy that establishes your principles, guidelines, standards and procedures for ensuring the security of your network and information systems.
Conducting risk assessments to identify your assets, threats, vulnerabilities, impacts and likelihoods of cyberattacks; and prioritising your actions based on your risk appetite and tolerance.
Implementing security controls that protect your network and information systems from unauthorised access, use, disclosure, modification or destruction. These controls can be classified into three categories: preventive (e.g., encryption); detective, detective (e.g., monitoring), and corrective (e.g., backup).
Implementing an incident response plan that defines your processes, roles, responsibilities, resources, tools and communication channels for responding to cyberincidents effectively and efficiently.
Implementing a business continuity plan that defines your processes, roles, responsibilities, resources, tools and communication channels for maintaining or restoring your critical business processes during a cyber-related disruption or disaster.
Implementing a review and improvement plan that defines your processes, roles, responsibilities, resources, tools and communication channels for regularly evaluating, reporting and enhancing your cybersecurity measures.
Implementing the technical controls for asset management and basic cyber hygiene.

The Directive’s reference to ‘basic cyberhygiene’ is a bit vague in Article 21, so we’ll dive into this in another blog post. For now, think about basic security measures such as:

MFA.
Patching your OS and applications as quickly as possible.
Securing network connections on public networks.
Encryption of all drives (especially removable ones.)
Privilege management and education of all employees.
Subscribing to channels that give you information about the latest patches and priorities, like Ivanti’s Patch Tuesday webinars.

3. Fix the weakest link: find time to train every employee

The NIS2 Directive recognises that human factors are crucial for cybersecurity and that employees are often the weakest link — as well as the first line of defense – in preventing or detecting cyberattacks.

The Directive requires organisations to provide adequate training and awareness programs for their employees, users of digital services and other stakeholders on cybersecurity issues.

Training all your employees is not a sporadic or optional task. It requires a regular and comprehensive program that covers topics such as:

Basic cybersecurity concepts and terminology.
Common cyberthreats and attack vectors.
Best practices and tips for cyberhygiene.
Cybersecurity policies and procedures, made relevant and simplified for end users.
Every user’s role and responsibilities for organisational cybersecurity.
How to report and respond to incidents.

It is important to note that this training should be received by everyone within the company, not only by IT employees. Even management should undergo this training.

A survey conducted for Ivanti shows that a lot of employees are not even aware of mandatory cybersecurity training. Just 27% of them feel “very prepared” to recognise and report threats like malware and phishing at work. 6% of them feel “very prepared” to recognize and report threats like malware and phishing at work.

In Enisa’s NIS Investments 2022 report, Enisa mentions that 40% of the surveyed OES (Operators of Essential Services) have no security awareness program for non-IT staff.

It is important to monitor who has not been trained yet and act on it. Training all your employees is not only beneficial for compliance but also for productivity, quality, innovation and customer satisfaction.

The best NIS2 advice we can give

The NIS2 Directive is landmark legislation that aims to enhance the cybersecurity of critical sectors in the EU. It imposes significant obligations on organisations that fall under its scope, along with hefty fines and sanctions for non-compliance.

Following the NIS2 Directive is a complex task. It demands a proactive and comprehensive approach involving multiple steps, stakeholders and resources.

The sooner you start preparing for it, the better prepared you will be when it becomes effective in October 2024.

The best advice we can offer? Do not wait till then: start preparing for the NIS2 Directive now!

5 Reasons Why NIS2 Directive Preparation Should Start Now, Part One: Audits Take Time

Mon, 28 Aug 2023 17:14:55 Z

You probably heard about the European Union’s updated Network and Information Security Directive (NIS2). This directive will translate into active law in October 2024. You should be ready for it, as there are high fines and sanctions for non-compliance.

But you might be tempted to think that October 2024 is far away, right? Think twice.

After all, how can you know if you have plenty of time to prepare if you don’t know how well you currently comply with the projected regulations?

So, between now and October 2024, you must audit your current cybersecurity status. Specifically:

Identify gaps in meeting the NIS2 directive’s requirements, starting now
Review your current supply chain security flaws

In the second part of this series, I’ll review the three areas you’ll need to address to fix the gaps your audits uncover — including how to:

Inform management about your cybersecurity gaps.
Implement new organizational and technical security measures correctly.
Find time to train all of your employees.

1. Identify gaps in meeting the NIS2 Directive's requirements, starting now

The NIS2 Directive is the EU-wide legislation on cybersecurity that provides legal measures to boost the overall level of cybersecurity in the EU. It modernises the existing legal framework to keep up with increased digitization and an evolving cybersecurity threat landscape.

The directive expands the scope of the cybersecurity rules to new sectors and entities, improving the resilience and incident response capacities of public and private entities, competent authorities and the entire EU.

The NIS2 directive outlines increased measures for resilience against cyberattacks to minimize vulnerabilities and improve cyberdefense.

To comply with the NIS2 Directive, you must:

Assess your cybersecurity posture and identify any gaps or weaknesses that may expose you to cyber risks.
Map your existing policies, procedures and controls to the directive's requirements and see where to improve or update them.
Evaluate your incident response capabilities and reporting mechanisms and ensure they align with the directive's standards.

A big problem with the NIS2 is that it tells you what you should do, but not how you should do it. Luckily, multiple frameworks can help you with the how, including:

In Belgium, the CCB has created a Cyberfundamentals Framework based on multiple frameworks with references to how the different parts of the frameworks relate to the GDPR and NIS2.

After selecting the framework, you must identify gaps in relation to the chosen framework and the directive's requirements. Identifying gaps is not a simple or quick task; it requires a thorough and systematic analysis of your organization's cybersecurity maturity and readiness.

You not only need to check your cybersecurity strategy and policies, but you also need to do a risk analysis to find the most critical assets and the cybersecurity risks they present, then consider security controls to bring down the risk score of those vital assets.

The sooner you start this process, the more time you’ll have to obtain the budget needed to address any issues and implement any necessary changes.

Possible NIS2 environment gaps

Some possible gaps that you may encounter in your environment are:

Lack of a comprehensive cybersecurity strategy or policy that covers all aspects of risk management, incident response, business continuity, data protection, etc.
Lack of a dedicated cybersecurity team or function that oversees, coordinates and monitors all cybersecurity activities and initiatives across the organization.
Lack of adequate security controls or measures for protecting your network and information systems from unauthorized access, use, disclosure, modification or destruction.
Lack of regular testing or auditing of your security controls or measures to ensure their effectiveness and compliance with the directive's requirements.
Lack of proper training or awareness programs for your staff, management, other employees or other stakeholders on cybersecurity issues and best practices.
Lack of clear communication or reporting channels for notifying relevant authorities or parties of any incidents or breaches that affect your services.

Potential security solutions for your environment to comply with NIS2

To identify and fix these security gaps, you can:

Run gap analysis frameworks or models that help you compare your current state with your desired state and identify areas for improvement.
Implement cybersecurity maturity models or standards that help you measure your level of cybersecurity performance and progress.
Conduct a risk assessment to identify your assets, threats, vulnerabilities, impacts and likelihoods of cyberattacks.
Request external audits or assessments that help you validate your compliance status and identify any weaknesses or deficiencies.

2. Review current supply chain security flaws with enough time to coordinate action with suppliers

The NIS2 Directive also introduces new provisions on supply chain security (chapter 0, point 54, 56), recognizing that cyber threats can originate from third-party providers or subcontractors.

The directive requires organizations to ensure that their suppliers follow appropriate security standards and practices (article 21-2d) and regularly monitor their performance and compliance (article 21–3).

This isn't without reason. Supply chain attacks are on the rise:

In BlackBerry research with over 1500 IT decision-makers in 2022, four-fifths of respondents said they had been notified of an attack or vulnerability in their supply chain within the year. Seventy-seven percent said they uncovered hidden participants in their software supply chain that they weren't previously aware of.

Accenture research also reveals 40% of security breaches are indirect, occurring through the supply chain.

Therefore, securing your supply chain is essential for ensuring business continuity, resilience, reputation and trust.

But in Ivanti’s Press Reset: A 2023 Cybersecurity Status Report, we found that only 42% of the over 1,300 executive leaders and security professionals surveyed said they're prepared to safeguard against supply chain threats, even though 46% call it a high-level threat.

Supply chain threats not only come via attacks on solution providers like Okta, Kaseya or SolarWinds, but also through partners either directly connected to your IT infrastructure or who can log into it.

And don’t forget about attacks on your resource suppliers that may cripple them so they're unable to deliver certain resources you need for your own operations. You have to be prepared and have backup vendors available who can supply those resources if your primary supplier is out of action due to a cyberattack or other cause.

Supply chain security is a complex and challenging issue involving multiple actors, dependencies and interconnections — and cannot be achieved overnight.

You need to:

Establish clear and transparent communication channels with your suppliers and define your expectations and obligations regarding cybersecurity.
Conduct regular audits and assessments of your suppliers' security practices and verify that they meet the directive's requirements.
Establish contingency plans and backup solutions in case of a disruption or compromise of your supply chain.

Furthermore, you must start engaging with your suppliers as soon as possible and work together with them to ensure your supply chain is secure and resilient.

Supply chain security challenges for NIS2

Some possible challenges that you may face in securing your supply chain are:

Lack of visibility or transparency into your suppliers' security practices, policies, or incidents.
Lack of trust or cooperation among your suppliers or between you and your suppliers.
Lack of consistency or alignment in security standards, requirements, or expectations across your supply chain.
Lack of resources or capabilities to monitor, audit or verify your suppliers' security performance or compliance.
Lack of contingency plans or backup solutions to mitigate or recover from any disruptions or compromises of your supply chain.
Lack of information as to what you expect from your supplier’s security practices.

Supply chain security solutions for NIS2

To overcome these supply chain security challenges, you can:

Establish clear contracts or agreements with your suppliers that specify their security obligations, responsibilities and liabilities.
Develop common security criteria, guidelines or frameworks that apply to all suppliers in your supply chain and align with the directive's requirements.
Implement security controls, measures or tools that enable you to track, monitor or verify your suppliers' security activities, incidents or compliance status.
Create joint security teams, committees or forums that facilitate information sharing, collaboration and coordination among your suppliers or between you and your suppliers.
Build trust and mutual understanding with your suppliers through regular communication, feedback and recognition.

When your NIS2 Directive audits are complete, now what?

Now that you’ve determined where you currently stand in relation to the NIS2 Directive, it’s time to implement critical changes to ensure compliance by October 2024. I’m certain that addressing the gaps that your audits identified will require all the time you have — and then some! – before the regulations are officially implemented in your country.

But how can you systematically address these gaps in a timely fashion? We discuss the three areas of security changes you’ll need for NIS2 in our next blog post, as we examine how to:

Inform management about your cybersecurity gaps.
Correctly implement new organization and technical security measures.
Find time to train all of your employees.

Patching within 14 days – Insight, Prioritization and Management

Mon, 09 Nov 2020 16:03:38 Z

In recent months the number of phishing emails has increased by 30,000%. Most of the time, those phishing attacks make use of exploits within systems. Very often a patch is already available for these exploits. In an average of 22 days after a patch is released, cybercriminals create an exploit that takes advantage of the vulnerabilities that the patch solves. This means it is important to patch as soon as possible, preferably around 14 days after the release of a patch. That way you have a few days left in case you hit problems when deploying the patch. But how do you get insight of your patch status and SLA compliancy and perhaps more importantly, how do you make sure that your systems are actually patched within that timeframe??

SLA time-to-patch

In June, the Cybersecurity Image Netherlands 2020 was released. It states that less than half of vulnerabilities are patched at companies within 90 days. This means that you as a company, are vulnerable to a problem for more than 2 months. A problem that could easily have been patched already. The first thing is to understand whether you get that 21-day SLA and which systems are in danger of falling outside this window. Ivanti Neurons for Patch Intelligence connects to Ivanti’s patch solutions to give you this insight. The first thing you see after going to Ivanti Neurons for Patch Intelligence is the status of your environment, how many machines are compliant and how many are on the edge to exceed the SLA. The SLA can be set to patch type, such as critical or important security patches or critical non-security patches. In the example below, the SLA is set to 21 days and warns when systems only have 7 days or less left. This way you get a warning 14 days after the release of a patch that you need to implement in your environment.

Patch Change Ticket priorization

There are a view stages within Continuous Vulnerability Management where Ivanti Patch Intelligence provides the necessary insights.

After the Patch Assessments by one of Ivanti’s patch solutions, the outcome is uploaded to Ivanti Neurons for Patch Intelligence, so you get an overview of all the patchesmissing in your environment. With this data, Change Requests can be made in your Service Management solution. When using Ivanti Security Controls and Ivanti Automation, it is possible to have Change Requests automatically created directly from the Patch Assessment step.

To assess Change Requests regarding patches, it is important that you and the CAB (Change Advisory Board) gain insight on how reliable a patch is – both in deployment and how they operate after installation. With that data you can select which patch process applies to the Change Request and whether a patch needs an additional test cycle or first needs to be rolled out to a pilot group. Ivanti Neurons receives anonymous information from Ivanti Neurons customers and other sources about how often a patch installation fails and whether a patch causes problems in the operation of applications. This data is used by Ivanti Neurons for Patch Intelligence to give insight in reliability of a patch and help you understand expected deployment issues. You will also receive tips on how to prevent or work around some issues. This information is collected through Ivanti customers, Microsoft and forums.

To determine the priority of a Patch Change Request, you need to understand the importance of the problem that the patch is solving. Ivanti Neuron's for Patch Intelligence indicates a threat score, the CVSS score, that runs from 0 to 10. The higher the number, the more important it becomes to install the patch as quickly as possible. In addition, Ivanti Neurons for Patch Intelligence indicates whether a problem solved by a patch, is already used in cyberattacks. Together with a trend analysis of social media, this data can be used to determine priority of patches and which systems need to be patched first. After all, a high threat score, the fact that a problem is already used in attacks and that it is widely discussed on social media, gives a huge chance that the exploit will also be used to attack your systems and the patch should be immediately rolled out over your environment.

More information can be found at Ivanti Neurons for Patch Intelligence | Ivanti or make an appointment for a demo through your account manager.

Ditch Manual Patching in the Datacenter

Wed, 01 Apr 2020 09:09:00 Z

Patching in the datacenter is still a lot of manual work. That is the conclusion I could make after talking to several of our customers, partners, and service providers. Ivanti can help streamline the patch process of your backend servers using automation and integrating with your service management solution.

In the talks I have had with the different administrators in the last half year, I heard a lot of the same manual tasks being mentioned for the patch process:

You have to get an overview of all missing patches on at the different systems. Mostly this is a manual task and it is difficult to find out if a patch is applied. It’s even worse for systems that are under control of a different administrator. It is difficult for security officers to get the big picture of the patch status of all systems.
After creating the reports of missing patches, you must create different change requests for all the systems that need updates. The change requests have to reflect which patches need to be applied and which underlying systems are going under maintenance in that process to determine the maintenance window.
At the time of the maintenance window, an administrator has to logon to the server and install the patches, reboot the server and close the change request reflecting the status of the patches. Most of the time those maintenance windows are in off hours, making it work late in the evening at the office.
It is difficult to find out if a patch is applied rightly on the systems and to get an overview of the status of all systems after installing the patches.

On top of this, there are also “forgotten” applications on servers. Applications that are installed on systems with other software, like Adobe Acrobat. Or applications that where installed on a system to quickly do some tasks, such as Google Chrome to download a piece of software needed on the server. Those application are mostly forgotten in the process to check which patches are needed. But most attacks happen by targeting such 3rd party software on servers.

Ivanti Security Controls delivers agentless patching in the datacenter. Scanning for patches for the OS as well as a lot of third party software, such as Adobe Acrobat, Flash, Java, Google Chrome and Firefox. By combining it with Automation, it enables you to automate a lot of the patching process. It can scan the systems automatically in off hours, creating reports of the hole environment for administrators and the security officer.

Ivanti Automation also integrates with your service management solution. We have a direct integration between Ivanti Automation and Ivanti Service Manager, but we can also connect to other solutions using API’s. With this integration it is possible to automatically create a change request when a scan with Ivanti Security Controls shows that there are patches missing. CI’s are linked to the change request to show what system is going down and with that information Ivanti Service Manager can also show which other systems are going to be affected by the patch deployment. The only thing that is left for the administrator is approving the change and set a maintenance window.

At the time of the maintenance window, Ivanti Service Manager can start the patch deployment. An administrator does not have to spend its evening at the office and just have to be standby at home.

First the servers being patched are set to ‘Under Maintenance’ in the Service Management solution. This give other users, like the support desk, insight in which systems are down at that moment. Ivanti Security Controls installs all the patches and reboots the server if necessary. At the end of the deployment the server is scanned again for missing patches, to check if all patches are rightly deployed and results are sent back to Automation. If all patches installed without problems, the change request is closed and the CI is put back into production within Ivanti Service Manager. If one of the patches failed, Ivanti Automation will keep the change request open, the CI is kept under maintenance and the administrator is notified by email or SMS that something is wrong and needs manual intervention.

Because Ivanti Security Controls scans the system after patch deployment, the status is immediately changed in all reports for administrators and the security officer, reflecting the change in installed and missing patching.

Using Ivanti solutions automates a lot of manual work from the patching process but keeps you into control. It gives better insight in the patching status of your environment at any time. Using Ivanti Security Controls, Automation, and Service Manager gives you the power of true Unified IT and makes your live as administrator, IT manager or security officer a lot easier.

The video below shows this Unified IT power in action. For more information how we can help you, please contact your account manager.