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 organizations 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 disk? 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 Program Files or Windows directories.

That distinction matters because modern attacks increasingly weaponize legitimate tools in improper contexts. Provenance control neutralizes 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 organizations 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 install 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 categorized 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 organizations 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, organizations 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 behavior your organization 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 emphasize 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 behavior 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 install 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 organizations now discuss cybersecurity at the board level.
81% of organizations have at least one director with cyber expertise.
88% of organizations include the CISO in strategic meetings.

On paper, that’s progress. But, many organizations 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 crystallize the disconnect: the conversation is happening, yet few feel exposure is conveyed in a way executives can act upon. The result is misguided prioritization, 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 defense; and effective governance requires comprehension, communication and follow-through.

Top cybersecurity risks that demand board attention

Ivanti’s research highlights where organizations 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 organizations continue to run end-of-life (EOL) software, and one in three organizations 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 sanitizing 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 organizations 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 organizations.

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

How supervisors judge readiness: Article 21 expects organizations 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 normalize 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 organization’s risk tolerance — that’s a cybersecurity governance red flag. The board cannot challenge, prioritize 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 recognizes:

“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 recognize: the management body needs regular cybersecurity training to discharge its duties.

Effective programs 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.

Prioritize 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 prioritization, 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.

Organizations 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.

Basic Cyber Hygiene: New Definition and Best Practices for the Current World

Thu, 06 Jun 2024 13:00:01 Z

With the latest changes in regulations and laws, and with cyberattacks becoming more sophisticated, costly and frequent, it’s unavoidable: You must rethink basic cyber hygiene for your organization.

Today, effective cyber hygiene requires you to plan and carry out regular and consistent actions to not only meet current challenges but also to keep pace with a threat landscape that is always evolving. The pivot to remote work, cloud computing and mobile devices created new openings for hackers, as will tomorrow’s developments in IoT and other technologies. What constituted basic cyber hygiene not very long ago no longer applies today.

A call for action: The NIS2 directive

The NIS2 (Network and Information System Security) directive of the EU urges every essential or important company to perform basic cyber hygiene, applying to entities in Europe and any businesses in the first tier of the digital supply chain of essential and important EU companies. EU and US authorities say they will work together on cybersecurity frameworks for critical infrastructure, possibly leading to US adoption of parts of the directive.

In recital 89 of the NIS2, Essential entities are asked to adopt a wide array of basic cyber hygiene practices including zero-trust principles, network segmentation, access management training in cyberthreat awareness. They’re also advised to pursue AI and machine learning technologies to bolster their capabilities.

A few years ago, basic cyber hygiene meant creating and updating complex passwords, patching devices regularly, backing up data and deploying firewalls and endpoint virus scanners. People worked in-office, applications were hosted on-premises or on devices, data stayed in on-premises data centers, and vulnerabilities rarely occurred in operating systems and applications.

Today, with hybrid work, there's a proliferation of devices connecting to applications hosted on-premises and in the cloud. Data is saved in multiple clouds and on-premises. More vulnerabilities are being exploited by more attackers.

Therefore, we must understand current basic cyber hygiene best practices all IT administrators should employ and all users should follow – and the technologies that can be deployed to support them.

Passwords: From complexity to simplicity

Creating and remembering complex passwords can be challenging for users, especially for dozens of accounts. This can create “password fatigue,” a tendency to reuse or write down passwords or use easy to remember (and therefore easy to guess) ones. That opens doors for phishing, brute force and credential-stuffing attacks.

IT personnel should recommend users use password phrases instead. These are long, memorable sentences mixing words, numbers and symbols. "I love to eat pizza on Fridays!" is easy to remember but hard to crack, and more resistant to dictionary attacks employing likely words or combinations.

Password phrases do not need to be regularly changed as often as passwords. Changing passwords too often can reduce security, as users tend to make minor and predictable modifications or reuse them across accounts. Strong password phrases must be changed only if a breach or leak is suspected.

IT teams can also introduce a password manager so users can generate, store and autofill their passwords and alert them if passwords are weak, reused or exposed in a data breach.

Device management: From protect most to protect all

Another cyber hygiene must: Keeping track of all devices connected to your network and ensuring security compliance. This way, administrators are not only protecting traditional devices like laptops, mobile devices, desktops and servers but others that might need access: printers, scanners, cameras, smart TVs or IoT devices.

Device management can be complex due to this increasing diversity of devices and the dynamic nature of networks. Some devices might belong to third parties (contractors, vendors, guests) not following your security practices.

A 24/7 asset discovery and inventory tool can automatically collect data about connected devices to help identify and classifying devices by providing information about their hardware, software, applications, databases and dependencies.

This helps administrators understand the relations among devices, data and applications and the potential network impact of a device failure or compromise. It can also help detect unauthorized, unmanaged or unsecured devices that may pose a risk, so you can take appropriate actions to remediate and manage them; these insights are essential to managing risk.

Patching: From delay to priority

Patching is essential to prevent hackers from exploiting software vulnerabilities, but can be daunting and time-consuming, especially for multiple devices and applications. Patches can cause compatibility issues, performance problems or errors, leading IT personnel to delay or ignore patching.

Prioritize and automate patching by enabling automatic updates for system, applications and antivirus software. A patch management tool can scan, download and install patches and help schedule, monitor and report on patching activities and send alerts on missing or failed patches.

Different patches have different installation priorities: Some should be installed in days or weeks; others can wait. Prioritize patches for critical systems that cannot auto-update immediately, or when more control and less disruption is necessary.

Consider the likelihood of a vulnerability being exploited: Some vulnerabilities might have a high severity rating, but hackers may not use them as they are difficult to exploit or require specific conditions or user interaction. Some might have a lower severity rating but are widely exploited as they are easy to exploit or are used in automated attacks or malware campaigns.

Assess compromise indicators and threat intelligence reports to know exploitation status and vulnerability type and frequency, then prioritize patches accordingly. For zero-day vulnerabilities, apply patches as soon as possible. Patch any vulnerabilities used in common attack vectors like phishing, credential stuffing, ransomware or those that affect critical systems or data.

By focusing on the actuality of a vulnerability, you can reduce your exposure to cyber threats and optimize your patching process and resources.

Multi-factor authentication: From optional to mandatory

Multi-factor authentication (MFA) verifies identity using two or more factors, such as something you know (e.g., password), something you have (e.g., phone), or something you are (e.g., fingerprint). This extra layer of online security prevents hackers from accessing accounts and services with just a password.

However, many users still do not use MFA because they are unaware of its benefits or find it inconvenient. It can also cause MFA fatigue among users who must enter multiple codes, tokens or biometrics at login, leading to dissatisfaction, reduced productivity and increased support costs.

Yet you must make MFA mandatory for all user accounts, especially those with access to sensitive or confidential data. To overcome MFA fatigue, IT administrators can also use a single sign-on (SSO) solution, letting users log in to multiple accounts and services with one username and password, reducing how often they need to enter credentials and MFA factors.

Another way to improve security is bringing MFA to the next level and completely remove the password. By using non-password authentication — biometrics and managed mobile devices only— you can eliminate password management and reduce the risk of phishing, brute force and credential-stuffing attacks.

Privilege: From excessive to minimal

Many users and applications have excessive or unnecessary privileges, increasing the attack surface and potential cyberattack damage. Users often have administrator privileges allowing them to install or remove software and change settings on devices, but these privileges are exploitable by malware, phishing or social engineering attacks. Plus, many applications have too many privileges, allowing hackers to access data and resources.

Follow the principle of least privilege: Users and applications should have the minimum required to perform tasks. A privilege management solution can monitor, control and audit these privileges and help you enforce policies, grant or revoke privileges and detect and respond to suspicious or anomalous activities.

One cyber hygiene best practice: Make everyone a standard user — including administrators – with limited privileges, preventing them from installing, changing or removing software and settings on their devices. This reduces risk of malware, phishing or social engineering attacks while improving device performance.

Your admins should only use administrative accounts to perform certain tasks, such as patching, troubleshooting or configuration. These accounts are task-specific, available for a limited period, and are then automatically revoked or deleted.

Also, use a privilege elevation solution to let standard users temporarily gain higher privileges (after approval or verification) for a specific process or application. This avoids granting permanent or excessive privileges as they only have the ones they need when needed. One of the most popular lets you control and monitor device applications and grant or deny privileges based on policies, rules or context.

Zero trust: From assumption to verification

A zero-trust security model assumes no user, device or end user is trustworthy. Everything and everyone must be verified before getting access, as trust is a vulnerability and traditional security models are no longer effective in the era of cloud computing, mobile devices and remote work.

Many users and organizations still rely on outdated or security models – for example, virtual private networks. VPNs can also create security risks, such as exposing the entire network to a compromised device or allowing unauthorized access to network resources. Moreover, many users and organizations use software-as-a-service applications hosted and accessed online. SaaS applications can also create security risks, such as exposing sensitive data to third-party providers or allowing unauthorized access to application data.

To support a zero-trust approach, you can deploy a zero-trust access solution to enforce policies, authenticate and authorize users and devices, encrypt and isolate data and traffic, and monitor and audit activities.

On managed devices, an application control solution is usually set up to allow only known applications to run in your infrastructure. Unknown applications, like any downloaded by users or launched from USB drives or sticks, are blocked.

Another practice of Zero Trust is restricting the use of external devices, such as USB drives, printers, cameras or other external devices by using a software-based device control. This helps prevent data leakage, malware infections or unauthorized access by auditing outside devices connected to endpoints and servers and either blocking or allowing access and encrypting data being saved on external devices.

Security training: From awareness to action

Many users and organizations still fail to identify or avoid phishing, or report or escalate cyberincidents.

Fortunately, it is easier than ever to address these deficiencies with regular and interactive security training. With security awareness software, IT teams can deliver and measure training programs that can cover the latest cyberthreats, trends and techniques, as well as the best cyber hygiene best practices and policies.

A security awareness solution can help administrators create, customize and deliver engaging and relevant content to all users in the company, such as videos, quizzes, games or simulations, and track and evaluate organizational progress and performance.

Encryption: From optional to standard

Many organizations still should use encryption but are unaware of its benefits or find it complex or costly. Encryption can cause performance issues, compatibility problems or data loss if not correctly implemented or appropriately managed.

By using encryption as a standard practice for your data and communication and by using a good, properly implemented and well-managed encryption solution, you will avoid the issues we’ve just mentioned while being able to choose, apply and manage the best encryption method for data and communication to ensure only authorized parties can access them.

Cyber hygiene is attainable with the right tools

Many of the established practices of cyber hygiene still apply, but we need to embrace new tools to keep pace with evolving challenges.

For instance, virus scanners are still necessary, but AI is enriching their capabilities by quickly assessing data from multiple sources to drive action. We still need to make backups, but they should be saved in secure, non-connected places, immune from modification.

Optimal cyber hygiene is within our grasp as long as we stay apprised of the latest tools and the best practices for using them well.

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 cyber hygiene’ 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 cyber hygiene.
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.

How to Use the New Ivanti Security Controls (ISeC) Connector for Automation

Mon, 12 Aug 2019 21:54:41 Z

Ivanti released the new Ivanti Security Controls (ISeC) connector for Automation in the beginning of July. This makes it possible to use Automation to create advanced tasks for patching.

Think about patching a cluster of machines, where you first want to disconnect a machine from the cluster, patch it, reboot and test the machine and put it back into the cluster before going to the next machine. If patching goes bad, the machine should stay out of the cluster and an administrator should be notified.

Or using Identity to give the power to patch a system to application administrators, so they can scan, patch and reboot their server when they are ready without giving them administrative rights on the server. In this blog we will bring you up to speed with this new connector.

In this blog we assume you already have installed and configured Ivanti Automation and Ivanti Security Controls and that you have a basic understanding how these products work as we are not doing a step-by-step walkthrough. You first have to download the connector from the Ivanti Marketplace and install it in your Automation Environment. After this, create an Active Directory user account that Automation will be using to connect to the ISeC REST API.

Next step is setting up Ivanti Security Controls so we can successfully run tasks by leveraging the REST API. Configure the following requirements in the ISeC Console:

Create a new credential for use by Automation at Tools -> Credentials. Those are needed for the REST API to start the scan and deployment and are being used to connect to the systems being patched. Notice the name, as you need it later.
If you run the Automation tasks on another Automation agent than the one where the ISeC console is installed on, you need to run the PowerShell script that is provided at Tools -> Options -> API on the server with the Automation agent installed, so it can connect to the ISeC REST API.
If you use User Role Assignment, you need to give the ‘create Active Directory user access’ to the ISeC console.

After setting up ISeC, we can create an Automation module to Scan a device. Open the Ivanti Automation console and create a new module. Add the task ‘Ivanti Security Controls – Patch Scan’-Start (it can be found in the Security-node). The first time you add an ISeC task it will ask you for some information to set the global variables. Use the Active Directory user account you created earlier as ISeC Serviceaccount. Set the ISeC server name (the machine with the ISeC console installed) and use port number 3121.

Next step is setting the Task settings. The required settings are:

Scan Type: Set this to device
Device name: right click in the value field and choose Insert Parameters -> AutoCreate parameter [Device name]
PatchTemplate name: WUScan (this is a builtin template. You can use another Patch Scan Template name)
Credentials Name: set this to the credentials created earlier.

The rest of the Task settings can be left default.

Last part is setting the result of the task into parameters.

Exitcode is being used to return a Finished without Errors (0) or Finished with Errors (1 or higher number) back to Automation.
PatchScanID will have the value of the internal ID for the Patch Scan given by ISeC. As it is needed in the other tasks we will add, this one is required to set. This can be done by selecting AutoCreate parameter [PatchScanID]

After this, click OK to go back to the module you are creating. The Start Patch Scan task will only start the agentless scan of a device and returns only the ID. It will not wait till the scan is ready or report anything else back. For this we need to add some other tasks.

Add the ‘Ivanti Security Controls – Patch Scan’-Wait task. In the Task Settings-tab add the earlier created PatchScanID-parameter as input. You can leave the rest of the settings to their defaults. This task lets Automation wait till the scan of the device is finished before going any further. You can put the result of the task into parameters, but this is not required.

The last step is to get the results of the scan, so we know if and how many patches are missing on the machine. Add the task ‘Ivanti Security Controls – Patch Scan’-Result to the module. Insert the PatchScanID-parameter to the task settings. The rest can be left to the default settings. Set the task result ‘ResultPatchScan’ to a new parameter by using the AutoCreate parameter function.

You have now created a module with 3 tasks in it, that will scan a device and put the report about missing patches in a parameter. Right click on the module to schedule it. Select the machine with the Automation agent that will communicate with the ISeC API and in the Job Parameters set the name of the device you want to scan. Hit the OK-button to run the tasks in the module.After the module has run, you can find the results in the module parameter that you created to capture the results in. To extend the module, you could parse the results into a task that creates a ticket in your ITSM solution or mail the results to a person. You can also find the results in the ISeC console. It will show the name that you can set in the Patch Scan – Start task settings (default set to Ivanti Automation) with the results.

Deployment of Patches

After a scan, you probably want to deploy the missing patches. This works the same way as the Patch Scan tasks. The deploy task is broken into several smaller tasks (start, wait, report). The ‘Ivanti Security Controls – Patch Deploy’-Download task can pre-download the patches in the cache of the server, distribution server and clients. The Deploy-Start task starts the deployment. As input it needs the PatchScanID that you also used in the earlier tasks. Other required task settings are the Deployment Template Name and the Credentials Name. This will result in a PatchDeployID that can be used for the -Wait command to wait till the task is finished (keep in mind that when missing a lot of patches, you might have to set a higher Deploy time-out for this task). The -Results task will show a summary of the deployment while the Report function results in a detailed report as output.

When combining Ivanti Security Controls with Ivanti Identity Director, it is possible for non-administratorsand users without access to the ISeC console to scan their systems upon request. They can scan, deploy and reboot the system when they are ready. See the video above for an example how this can work.