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!
Reduce the risk of targeted manipulation of ICT products in the supply chain. a) Organisations should assess the risk of being exposed to such targeted attacks. b) Ask national resellers/importers to practise discretion and not divulge too much customer information, e.g. names of customers, how the product is used, where the product is being used. c) Protect the integrity of physical products (in consultation with national resellers/importers) at the earliest possible stage in the supplier chain. Products should be checked at every national stage of the chain (including by the customer before deployment) for broken seals and stored so that only a limited number of personnel have physical access. d) Software products should only be downloaded from the provider’s official website (only via https). The organisation should keep all installation software in file folders that only those responsible for software installation have write access to. e) When performing maintenance on ICT products, physical provider access should be regulated and monitored.
Use a secure software development method in order to reduce vulnerabilities in the software. This includes: a) Adequate planning, including the organisation’s needs, legal conditions, ICT security considerations and the need to train personnel. b) Analysis of user needs, including ICT security requirements. c) Design of the software according to requirements. d) Development of the software, including secure coding and testing (see 2.1.6 and 2.1.7). e) Deployment of the software. f) Secure management of the software, including i) planning for performing and distributing security updates, and ii) planning support for newer and more recent security functionality.
Use separate environments for development, test and production so that operational business processes are not affected by errors in development and testing. Also consider zone segmentation as described in measure 2.2.3. Use sensitive production data only in secure development and testing environments.
Implement adequate testing throughout the development process. This will allow one to correct any errors, vulnerabilities and omissions before deployment. a) The measure includes testing to verify that the security functions of the various affected ICT products are interacting seamlessly, cf. principle 2.2 – Establish a secure ICT architecture, as well as unit testing, integration testing, system testing, acceptance testing, pilot testing, Perform penetration tests (principle 3.4) and stress testing. b) Check that only permitted actions are allowed and perform spot checks to ensure that other actions are denied.
Maintain the software code developed/used by the organisation. a) Sustain a development process which includes methodical security assessments of the code. b) Be especially aware of code with particular security significance e.g. code for i) access control, ii) traffic encryption, iii) logging, iv) parsing user input, v) buffer overflow etc. c) When using open-source code and commercial tool kits, the organisation should regularly check for new versions (ideally automatically). d) Security checks of the organisation’s own code should also be automated where appropriate when using DevOps/DevSecOps. Particularly security-relevant code (cf. previous item) should be quality-assured.
Maintain security responsibility during outsourcing. This includes a) staying in control of the entire life cycle of the service(s) being outsourced, b) procurement expertise (e.g. management, administrative and IT architecture expertise) for the duration of the outsourcing, c) conducting adequate risk assessments which includes ICT throughout the entire life cycle, d) a requirement document for every stage of the outsourcing e) contracts on the outsourcing of ICT services, and amendments to such contracts, in accordance with the organisation’s authority hierarchy. See also chapter – Outsourcing and cloud services and it must be stressed that the organisation’s security obligations do not end when one outsources. The organisation remains responsible regardless of who is performing the tasks.
Review the service provider’s security when outsourcing. As a minimum, one should review if the provider: a) has a management system in place for information security along with any certifications in accordance with international standards, e.g. ISO/IEC 27001. b) provides details of the security architecture used to deliver the service.c) has development plans for future security functions for the service in response to technological advances and changes with threats over time. d) maintains a list of who is granted access to the organisation’s information, where and how it will be processed and stored, and the extent of mechanisms to segregate it from other customers. e) has security functions that meet the organisation’s needs. f) carries out security monitoring in order to detect security incidents that could impact the organisation. g) has procedures in place for managing incidents and for non-conformance and security reporting. h) has established incident management plans which works with the organisation’s own plans. i) has procedures for approving subcontractors and their use of subcontractors. j) has specified which activities should be performed when terminating the contract, including returning/moving/deleting the organisation’s information.
Establish and maintain a comprehensive security architecture to ensure a secure and defensible
ICT system. The following functionality in an ICT system should be implemented, made secure and
integrate together in a security perspective:
a) Functionality for managing users and accounts
b) Functionality for staying in control of devices (e.g. clients)
c) Functionality for managing access to resources and services
d) Functionality for controlling software execution and software installation (especially on
clients)
e) Operating systems
f) Tools for operating and virtualising all or parts of the ICT architecture (on-prem and cloud)
g) Network devices (switches, routers, access points) and firewalls
h) Mechanisms for dealing with malware (antivirus)
i) Cryptographic modules
j) Digital certificates and public key infrastructure (PKI)
k) Databases
l) Tools for system monitoring
m) Tools for managing security configurations
n) Intrusion detection (IDS) and protection (IPS) systems
o) Backup and restore
p) Hardware and firmware
Design the ICT system using ICT products which integrate well.
a) The products should be module-based (ability to activate only functionality that is useful to the
organisation).
b) Products should comply with industry standards with respect to security functions such as
access control, logging, operation, code control, resource management and accessibility functions
see 2.2.1. c) Products and security functionality (also from different vendors) should work well
together from a security perspective. In particular, ICT products should reuse identities (of users
and devices) taken from a shared database of the organisation’s identities rather than implement
their own product or application-specific identities.
Segment the organisation’s network in accordance with its risk profile. Segment (divide) the network into zones with different needs for communication, exposure, function and roles. For example, one could consider creating separate zones for system administration, application servers, organisation-operated clients, industrial production (e.g. SCADA and industrial control systems), internet access, wireless networks, guest clients and externally available services (e.g. web servers). In data centres servers can be segmented into security groups such as a data plane (data going through the network), control plane (data going to network devices) and management plane (management data going to network devices). One could also consider creating a network architecture with even more granular zone segmentation, e.g. by department or by group of devices. Please note that one can create zones in many different ways: VLAN zones, virtualised networks, micro segmentation etc. Zones should be managed centrally, not locally on each switch. Use the chosen segmentation model to manage data flow, see principle 2.5 – Control data flow.
Physically isolate the most critical subnets. One should consider whether to physically isolate particularly sensitive subnets from the rest of the organisation’s networks (air gap).
Partition the domain architecture in accordance with the organisation’s needs. As a minimum, separate clients from the organisation’s servers.
Control access to services based on knowledge of users and devices. One example is if a user logs in via an unmanaged device (the organisation trusts the user but does not control the device) and gains access to fewer services than if the user logs in via an organisation-managed device (the organisation knows both the user and the device).
Establish a robust and resilient ICT architecture which maintains access to critical functions and deliverables. a) Perform risk assessments for hardware failure, human operating error, cyberattack, internet access (incl. denial of service attacks), service provider availability, natural damage and geopolitical situation. b) Based on the risk assessments and level of criticality, one can make parts of the IT solution more robust. This could involve measures such as duplicating the internet connection, duplicating the data centre in an alternative location, duplicating domain controllers, partial outsourcing, robust (temporary) power supply, keeping critical spare parts etc.
Establish centrally managed practices for security updates. Install security updates as quickly as possible. a) Create a list of updates according to priority. The operating system and applications on employees’ clients should be given priority. One should also update servers containing standard applications and operating systems, printer software and the devices running the organisation’s network (switches, routers). b) Establish a procedure with clear lines of responsibility for i) how often updates should be carried out (one should be able to automate much of it), and ii) following up on any updates that cannot be performed or have to be postponed. c) Isolate servers and other equipment that are difficult to keep up to date, see 2.5.4. d) Organisations should automate and simplify the process of implementing new security updates.
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.
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.