2.3.2: Configure clients so that only software known to the organisation is able to execute

Oh no! No description found. But not to worry. Read from Tasks below how to advance this topic.

Configure clients so that only software known to the organisation is able to execute. Keep in mind that software can execute even if not installed. a) On employees’ clients one should explicitly allowlist all programmes that will be running on the device, ideally by having permitted source code signed by a trusted party who can also quality-assure the code against the operating system’s application criteria. In practice, the code could be signed by the device provider’s app store, alternatively also in the organisation’s own app store. If required, the selection of applications in a supplier’s app store could be restricted by allowlisting only required applications (e.g. with tools like Mobile Device Management – MDM). b) If an app store is not used, one should use application allowlisting. Use file folder-based allowlisting, as allowlisting individual applications is usually too time-consuming. c) If required, one can also refine the application allowlisting further by setting it to denylist any unwanted provider-signed programmes for defined user groups, e.g. one can explicitly block any built-in script engines (keep in mind that script engines such as powershell*.exe can provide an unnecessarily large attack surface if end users are permitted to execute them) one does not want end users to be able to run (only administrators). d) The software that accompanies some documents (e.g. macros) also provides a large attack surface. To reduce this attack surface, one should i) remove unwanted software from external documents and emails before they reach the users, e.g. in the firewall, ii) deactivate the option to run such software for users who do not need it, and iii) explicitly allowlist software in documents that the users actually need, e.g. by using digital signatures.

This requirement is part of the framework:  
NSM ICT Security Principles (Norway)

Other requirements of the framework

30313
2.3.2: Configure clients so that only software known to the organisation is able to execute
Best practices
How to implement:
2.3.2: Configure clients so that only software known to the organisation is able to execute
This policy on
2.3.2: Configure clients so that only software known to the organisation is able to execute
provides a set concrete tasks you can complete to secure this topic. Follow these best practices to ensure compliance and strengthen your overall security posture.

Configure clients so that only software known to the organisation is able to execute. Keep in mind that software can execute even if not installed. a) On employees’ clients one should explicitly allowlist all programmes that will be running on the device, ideally by having permitted source code signed by a trusted party who can also quality-assure the code against the operating system’s application criteria. In practice, the code could be signed by the device provider’s app store, alternatively also in the organisation’s own app store. If required, the selection of applications in a supplier’s app store could be restricted by allowlisting only required applications (e.g. with tools like Mobile Device Management – MDM). b) If an app store is not used, one should use application allowlisting. Use file folder-based allowlisting, as allowlisting individual applications is usually too time-consuming. c) If required, one can also refine the application allowlisting further by setting it to denylist any unwanted provider-signed programmes for defined user groups, e.g. one can explicitly block any built-in script engines (keep in mind that script engines such as powershell*.exe can provide an unnecessarily large attack surface if end users are permitted to execute them) one does not want end users to be able to run (only administrators). d) The software that accompanies some documents (e.g. macros) also provides a large attack surface. To reduce this attack surface, one should i) remove unwanted software from external documents and emails before they reach the users, e.g. in the firewall, ii) deactivate the option to run such software for users who do not need it, and iii) explicitly allowlist software in documents that the users actually need, e.g. by using digital signatures.

Read below what concrete actions you can take to improve this ->
Frameworks that include requirements for this topic:
No items found.

How to improve security around this topic

In Cyberday, requirements and controls are mapped to universal tasks. A set of tasks in the same topic create a Policy, such as this one.

Here's a list of tasks that help you improve your information and cyber security related to
2.3.2: Configure clients so that only software known to the organisation is able to execute
Task name
Priority
Task completes
Complete these tasks to increase your compliance in this policy.
Critical
No other tasks found.

How to comply with this requirement

In Cyberday, requirements and controls are mapped to universal tasks. Each requirement is fulfilled with one or multiple tasks.

Here's a list of tasks that help you comply with the requirement
2.3.2: Configure clients so that only software known to the organisation is able to execute
of the framework  
NSM ICT Security Principles (Norway)
Task name
Priority
Task completes
Complete these tasks to increase your compliance in this policy.
Critical
Using a mobile device management system
Critical
High
Normal
Low
Minimize the risk posed by the software that accompanies documents
Critical
High
Normal
Low
1
requirements
Technical cyber security
Malware protection

Minimize the risk posed by the software that accompanies documents

This task helps you comply with the following requirements

Automatic blocking and detecting of unauthorized software
Critical
High
Normal
Low
17
requirements
Technical cyber security
Malware protection

Automatic blocking and detecting of unauthorized software

This task helps you comply with the following requirements

The ISMS component hierachy

When building an ISMS, it's important to understand the different levels of information hierarchy. Here's how Cyberday is structured.

Framework

Sets the overall compliance standard or regulation your organization needs to follow.

Requirements

Break down the framework into specific obligations that must be met.

Tasks

Concrete actions and activities your team carries out to satisfy each requirement.

Policies

Documented rules and practices that are created and maintained as a result of completing tasks.

Never duplicate effort. Do it once - improve compliance across frameworks.

Reach multi-framework compliance in the simplest possible way
Security frameworks tend to share the same core requirements - like risk management, backup, malware, personnel awareness or access management.
Cyberday maps all frameworks’ requirements into shared tasks - one single plan that improves all frameworks’ compliance.
Do it once - we automatically apply it to all current and future frameworks.