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!
Perform regular penetration testing (at least annually) to identify vulnerabilities. Penetration tests should be carried out a) from outside the organisation’s network barriers (e.g. from the internet or via wireless communication near the organisation’s premises) in order to simulate an external attack, and b) from inside the barriers (e.g. in the internal network) in order to simulate internal attacks from a compromised client/server or disloyal employee.
Test the organisation´s routines for detection and preparedness e.g. when performing penetration tests. Testing frequency will depend on the organisation’s needs, but tests should be performed at least every two years to maintain adequate skill levels amongst the personnel involved.
Communicate the results of penetration tests to relevant stakeholders. a) Reports on penetration tests and ICT preparedness exercises should meet the organisation’s needs. b) The tests should be documented with a summary (management summary) and a list of findings and suggested improvements.
Establish plans for incident management which meet the need for business continuity at times of preparedness and crisis. This should include a) a set of requirements for restoring ICT functions, ICT services and ICT systems based on an analysis of the consequences for the organisation (BIA – business impact analysis), b) a description of roles and responsibilities for relevant personnel, c) required training of relevant personnel, d) categorization regime for incidents and threshold values for activating the crisis management team, e) requirements for testing and exercising plans and personnel. f) Revise and update plans regularly, at least once a year and after an exercise, major incident or attack.
Perform a business impact analysis. This should include: a) prioritising vital business functions and their required security levels, b) identified dependencies of ICT functions, ICT services, ICT systems etc., c) criteria for restoration time, loss of data and service levels.
Describe roles and responsibilities for personnel involved in incident management. This includes: a) personnel with important responsibilities, e.g. IT manager, application manager, platform manager etc., b) managers with decision-making responsibilities at various levels, and c) emergency personnel available outside ordinary working hours and during holidays. d) Ensure sufficient training and exercising for personnel according to plans.
Establish agreements with relevant third parties in order to provide support if required during an incident. Third parties could be sector-specific computer emergency response teams, IT specialists in various fields, equipment and software providers etc.
Determine which communication channels to use in the event of an incident. a) Distribute contact information on relevant personnel. b) Create a plan for alternative communication channels. c) Create an internal and external communication plan for incidents.
Test and rehearse the plans regularly so that they are established. a) Exercises should include relevant subcontractors. b) Exercises should include testing of procedures for detection and preparedness, see 3.4.5.
Review log data and collect relevant data on the incident to create a good basis for making decisions. This could involve obtaining and collating data from multiple sources, performing tests or taking measurements in order to verify or disprove an incident. The method and scope will depend on the type of incident.
Determine the severity level of the incident in accordance with adopted plans, see 4.1.1. a) Determine whether the incident is a potential or confirmed security incident or a false alarm. b) Categorize the incident in accordance with the organisation’s categorization regime (4.1.1.d). c) Involve relevant roles (4.1.3). d) Activate response plans if the nature of the incident requires it.
Inform relevant stakeholders. This could be sector-specific computer emergency response teams, IT specialists in various fields, equipment and software providers, the management, end users, the media etc. See 4.1.3–4.1.4.
Identify extent and impact on business processes. Identify the impact of the incident on underlying ICT functions, ICT services and ICT systems. See 4.1.2.
Determine whether the incident is under control and take the necessary reactive measures. If the extent increases and appears to be having serious consequences for the organisation’s business processes, one should implement crisis response activities by escalating to the crisis management team. Examples of reactive measures are:
• Allocating internal and external personnel to manage the incident.
• Encapsulating and blocking the intruder to prevent spreading.
• Terminating threatening or compromised activities in the system, e.g. by shutting down
compromised internal servers which can be used for further attacks.
Log all activities, results and relevant decisions for subsequent analysis. a) Establish a timeline of the organisation’s own and the threat actor’s activities. b) Update event data and situational awareness continuously in order to manage the incident in the best possible way. c) Secure electronic evidence for malware analysis and potential legal processes, see also principle 3.2 – Establish security monitoring.
Launch recovery plan during or after the incident. Measures will depend on the type of incident, but could include:
• Reactivating redundant resources lost or damaged during the incident.
• Reinstalling hardware and software on affected components.
• Restoring configuration settings, to include any necessary adjustments.
• Restoring services halted during the incident.
The ICT systems should be rebuilt to a better state than they were in before the incident occurred (“build back better”).
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.