Oh no! No description found. But not to worry. Read from Tasks below how to advance this topic.
NCM ICT Security Principles is a framework for ICT security published and maintained by the Norwegian National Security Authority (NSM). The security principles advice businesses and organisations on how to protect their information systems from unauthorized access, damage or misuse.
NCM ICT Security Principles is a framework for ICT security published and maintained by the Norwegian National Security Authority (NSM). The security principles advise businesses and organisations on how to protect their information systems from unauthorized access, damage or misuse.
The principles focus on technological and organisational measures. Measures concerning physical security and the human perspective are generally not covered. The measures apply to both unintentional and intentional acts, although the main focus is on intentional acts.
In this framework there are 21 security principles with a total of 118 security measures, distributed across four categories: i) identify, ii) protect and maintain, iii) detect and iv) respond and recover.
Below you'll find all of the requirements of this framework. In Cyberday, we map all requirement to global tasks, making multi-compliance management easy. Do it once, and see the progress across all frameworks!
Identify the organisation's strategy and priorities, as well as regulations, industry standards and contracts which may have an impact on information system security
Identify the organisation’s structures and processes for security management. This would normally include a) management policies, b) management structure with well-defined responsibilities, c) processes for risk management (see 1.1.3), d) established risk tolerances (see 1.1.4), e) ensure sufficient resources and specialist skills to support the management. f) Establish structures and processes for security management if such do not exist. Ensure that they are tailored for the organisation and becomes an integrated part of the governance of the organisation.
Identify the organisation’s processes for ICT risk management. This would normally include a) asset valuation, b) threat assessment, c) identifying existing security measures, d) risk identification, e) risk assessment, f) risk reporting, g) risk management, h) establishing or adjusting security measures to reduce risk, i) verifying that the security measures are working as intended. j) Establish processes for risk management if such do not exist. Ensure that the processes are tailored for the organisation and become an integrated part of the governance and security management of the organisation.
Identify the organisation’s tolerances for ICT risk. The management must determine the organisation’s acceptable risk tolerances, included defining unacceptable risk. This must be communicated across the organisation. It is normal for organisations to determine risk tolerances based on consequences in the event of a loss of confidentiality, integrity and availability of information and information systems. See 4.1.1, 4.1.2.
Identify the organisation’s deliverables, information systems and supporting ICT functions. Identify a) ICT systems, data and services, including ownership, b) critical business roles and c) internal and external ICT dependencies. d) Group items a-c according to the organisation’s risk tolerances (1.1.4) and use the results to establish a secure ICT architecture, see principle 2.2 – Establish a secure ICT architecture.
Identify information processing and data flow. Map the flow of information between work processes, users, devices and services and use the results to establish a secure ICT architecture, see principle 2.2 – Establish a secure ICT architecture.
Establish a process to identify devices and software in use at the organisation. One should ideally use automated and centralised tools to detect and monitor devices and software and to determine which software is running on which devices. The inventory should also include ownership, older unsupported products (should be explicitly identified) as well as devices and software not connected to the organisation’s network (e.g. USB devices). More details in 1.2.3 (devices) and 1.2.4 (software).
Establish organisational guidelines for approved devices and software. a) For example, the organisation should decide i) which types of devices and software the employees need, ii) which devices and software are not required for work purposes but still permitted, iii) which devices and software are unwanted, and iv) how to enforce it. b) Develop and maintain a list of devices and software approved for use at the organisation (including version number if appropriate). Assess needs against recommended measures in principle 2.1-2.3. c) Communicate the guidelines to staff. Describe security targets and permitted use of devices and software.
Identify devices in use at the organisation in accordance with the process described in 1.2.1. a) Identify information such as network addresses, hardware addresses, device names, department affiliation and whether the devices are managed by the organisation. Every device with an IP address on the network should be included on the list, including stationary and portable computers, servers, network equipment (routers, switches, firewalls etc.), printers, storage networks, IP phones, IoT devices etc. b) Create a list of all mobile devices and storage media in use outside the organisation’s network which contain organisation data. c) Create a plan for managing devices not approved for use at the organisation (see 1.2.2). For access control, see 2.4.1.b. d) The organisation should also maintain a list of virtual devices (whether they are running at the organisation’s premises or in a provider’s cloud). Such devices are often temporary (e.g. stateless virtual desktops), so one can simplify this by keeping in the inventory only the templates that the virtual devices are based on. Keeping a list of virtual devices running in a provider's cloud is strictly only necessary when buying IaaS. The process described above can be simplified by being consistent in allowlisting all devices (and/or wired and wireless network connections) on the organisation’s network. See also principle 2.4 – Protect the organisations networks.
Identify the software in use at the organisation in accordance with the process described in 1.2.1. a) Identify firmware, operating system and applications (name, version number, manufacturer, installation date, whether it is still supported) installed on servers, clients and network equipment etc. b) Create a plan for how to approve software for use at the organisation (see 1.2.2). The process described above can be simplified by being consistent in allowlisting all applications (especially clients) (alternatively the use of app stores). Systematic use of application allowlists (or app stores) can make it easier to maintain an inventory of software in use. This is particularly relevant for end user clients.
Identify the users of the information systems, including: a) user identity, b) work location(s), c) required access to ICT systems, services/applications, d) particular privilege requirements, see 1.3.2. See also principles 2.2 – Establish a secure ICT architecture and 2.6 – Stay in control of identities and access rights.
Identify and define the different user categories and define and grant access levels according to user needs. Examples of user categories could be:
• Ordinary users only requiring office support.
• Users with a particular need for extended privileges, e.g. developers.
• Users running the organisation’s systems.
• Suppliers and consultants.
• System users, e.g. system processes such as backup operations and similar running in the
background.
Identify roles and responsibilities linked especially to ICT security. a) This concerns responsibilities internally at the organisation, e.g. security manager, IT manager, applications manager, platform manager etc. b) Clarify who should be notified in the event of an incident. See 4.1.1 and 4.1.3. c) Identify roles and duties maintained by external providers and partners.
Include security in the organisation’s procurement process. Determine ICT security specifications when procuring any type of ICT product or service, see principle 2.2 – Establish a secure ICT architecture. Include life cycle security from procurement to disposal.
Procure modern and up-to-date hardware and software to ensure that the latest security functions are built in. Ensure that the organisation a) only uses ICT products supported by and receiving security updates from the provider, b) only acquire ICT products which contain recent security functions and protocols, and c) phase out older ICT products. d) Where appropriate, one should ask the provider (who knows the ICT product best) to i) disclose any risks and vulnerabilities associated with the product, and ii) specify how the ICT product can be securityhardened and protected.
Prefer ICT products which have been certified and evaluated by a trusted third party. Common Criteria is one example of a certification regime. Common Criteria is an international standard for evaluating the security properties of ICT products and systems.
Explore our comprehensive resources and improve your security with the themes of this framework.
Discover specific ways our platform streamlines your ISO 27001 compliance process, from automated controls to audit preparation.
Explore use caseTake our comprehensive assessment to identify gaps in your current implementation and get personalized recommendations.
Start assessmentDive deeper with our articles, case studies, and expert insights on framework implementation.
Read articleGet a concise overview of all requirements, controls, and implementation steps in our quick guide.
Get the guideSee how the overlap and differences with any other framework to optimize your compliance strategy.
Compare frameworkParticipate in expert-led sessions covering implementation strategies, common pitfalls, and best practices for compliance.
Register for webinarParticipate in expert-led sessions covering implementation strategies, common pitfalls, and best practices for compliance.
Register for webinarUnderstand the basics of cyber security frameworks with our comprehensive guide.
Read the articleWhen 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.