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.
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.
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.
In Cyberday, requirements and controls are mapped to universal tasks. Each requirement is fulfilled with one or multiple tasks.
When building an ISMS, it's important to understand the different levels of information hierarchy. Here's how Cyberday is structured.
Sets the overall compliance standard or regulation your organization needs to follow.
Break down the framework into specific obligations that must be met.
Concrete actions and activities your team carries out to satisfy each requirement.
Documented rules and practices that are created and maintained as a result of completing tasks.