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!
Control the data flow of especially exposed services. a) Exposed services such as web and email with external content for users should be subject to strict controls. b) There should be no direct data flow between such exposed services and the organisation’s most critical services.
Protect particularly critical services with their own data flow. a) Consider which services are particularly critical and should have their own rules for data flow. Backup services are one example. b) Consider validating critical services on the application layer, e.g. with an application firewall.
Maintain control of data flow between the organisation and its partners / service providers. An attack can hit the organisation via the systems of a partner or service provider. Traffic to and from these systems should be directed only to the relevant parts of the organisation’s system.
Direct all data flow (not just internal services) to and from managed mobile clients via the organisation’s network and not directly to the internet. Managed mobile clients should always (regardless of where they are) be subject to the security functions in the organisation’s systems, in order to prevent and detect data leaks from compromised clients.
Create guidelines for access control. a) The guidelines should cover as many of the organisation ’s resources as possible: users, clients, shared folders, server applications, servers, network devices, security devices and databases. b) The guidelines should follow the principle of least privilege: do not give end users, service accounts, developers or system managers any more privileges than necessary. Not everyone needs access to everything. And if someone does need access, it is often sufficient to give them read privileges. Not everyone needs to be able to write, delete and execute everything. c) It should be possible to trace every account to the responsible user (including non-personalised accounts without personal names). d) All accounts, access rights and privileges should be traced to a responsible role and the individual who approved it. e) Accounts, access rights and privileges should be revised regularly. This is especially critical for accounts, access rights and privileges for system management and special users. f) Reuse identities whenever one can across systems, sub-systems and applications (ideally with single sign-on). g) Remind users that it is their responsibility to keep passwords personal and secret and to never share them with anyone, including close colleagues or superiors. Users should also screen-lock their clients when leaving them.
Establish a formal process for administration of accounts, access rights and privileges. a) The process should cover i) accounts for users, devices and system processes, ii) access rights to systems and applications, iii) privileges in relation to operating systems (e.g. admin privileges) and the organisation’s shared user database. b) The process should include the entire life cycle and cover creation, maintenance and deactivation. Deactivate rather than delete accounts and access rights in order that there is an audit trail in accordance with prevailing laws and regulations. c) The guidelines on access control (2.6.1) and the process for administering accounts, access rights and privileges (2.6.2.a) should be documented and communicated across the organisation.
Use a centralised tool to manage accounts, access rights and privileges. a) Ideally, one should manage accounts, access rights and privileges for as many of the organisation’s resources as possible (cf. 2.6.2.a) using just a single tool for the entire organisation. b) Use the tool to keep track of all accounts, access rights and privileges. The tool should be able to perform as many of the tasks described in 2.6.1 as possible. c) When creating individual accounts (e.g. for contractors), one should set preliminary dates for deactivation. d) Deactivate or delete accounts that have not been used for a while (possibly with the exception of supplier maintenance accounts, for example). e) Use a centralised tool to check password quality against the organisation’s security requirements. As a minimum, avoid using common words and names in Norwegian and English as well as years and seasons.
Minimise privileges for end users and special users. a) Do not assign administrator privileges to end users. b) Manage special users (e.g. developers) who may exceptionally need extended system privileges, including administrative privileges. Each special user should have two separate accounts: one for ordinary office use such as email and internet searches, and one for tasks requiring elevated privileges. There should be adequate security barriers between these two accounts and, as an absolute minimum, they must not have the same password.
Minimise privileges for management accounts. a) Create different accounts for different management operations (even though it may be the same person carrying out the operations in practice), so that if one account is compromised, it will still not grant privileges to the entire system. I.e. different management accounts for backup, user administration, managing clients, managing servers etc. b) Limit the use of accounts with domain admin privileges to a minimum of the organisation’s management operations. Accounts with domain admin privileges should never be used interactively on clients and servers (mitigates the consequences of “pass the hash” attacks). c) Avoid non-personalised accounts (“backup_john” is better than just “backup”) to ensure accountability and make it easier to deactivate accounts when someone leaves the organisation. If it is difficult to avoid non-personalised accounts, one should ensure that the user first logs in with a personal user ID to ensure accountability.
Manage access to devices. a) Identify devices securely and uniquely e.g. with certificates. This is especially important on employees’ clients. b) Adopt unambiguous rules on which network zones, resources and services the devices should have access to.
Use multifactor authentication such as smart cards, certificates or one-time passwords to authenticate users. a) As a minimum, use multifactor on user accounts that have access to critical data or systems and system management users. If multifactor authentication is not supported, the user accounts should be compelled to use strong passwords. b) Use biometrics (e.g. fingerprint recognition) on clients frequently used in public areas (users can be observed/filmed when entering passwords). Please note that there may be privacy concerns around biometrics.
Establish crypto strategy in the organisation. The strategy should include which cryptographic tools to use, how to manage certificates, how to ensure secure key generation, how to store keys/passwords, backup copying of keys, renewing of keys, and what to do if keys are compromised. Key management should distinguish between long-term keys and session keys, whereby long-term keys should be given additional protection.
Activate encryption in services which offer such functionality and ensure that only recommended algorithms and key lengths are used.
Encrypt storage media which contain confidential data and which can easily be lost or compromised, e.g. storage in mobile clients. Define how different types of data should be protected, e.g. by encrypting individual files, partitions or entire disc drives.
Use encryption when transferring confidential information or when trust in the information channel is low. For each channel decide what level of encryption to perform, e.g. in the application (TLS), on the network layer (Ipsec) or on the data link layer (MACsec).
Define security levels for different types of information with different needs for confidentiality protection. Define for both information stored on different media and for information being transferred in different information channels.
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.