About Implementation

To guarantee an adequate level of security in the systems, it is necessary to act before an incident occurs or, at least, to be able to detect it at an early stage to reduce its impact and scope.

The implementation of the SOC is not an easy task, and it requires a continuous improvement process, in other words, it requires economic and human resources which will not always be available so that, at different stages, and depending on the resources available at any given time, its implementation must be gradually improved. This approximation through iterations must address the most important vulnerabilities in a prioritised order, progressively increasing the organisation's level of cybersecurity maturity.

The SOCs must stand out for their proactivity, being able to detect a multitude of types of attacks, prevent their expansion, respond quickly to the incident detected and generate action procedures which prevent future incidents. The storage of an increasing number of events will provide a complete, truthful overview of the situation of the systems of the Spanish public administrations which will enable preventive action against the threats looming over them. Use cases must be applied to establish which records need to be stored and processed. These records must help and be consistent to raise security alerts and thus be efficient. And most importantly, they must exchange information about the threats and notify their incidents so that collective intelligence helps protect society as a whole.

Capabilities of a SOC

The SOC provides the Body with the following capabilities:


Expanding the knowledge regarding its vulnerabilities, both technical and human, to reduce the exposure surface.


Applying blocking measures at different points of the infrastructure, to prevent or limit cyberattacks.


Observing everything that happens in the organisation to look for existing threats.


Acting in the event of cyber incidents, to minimise the impact on the Organisation.

Security management

Establishing the course of the rest of the capabilities to carry out proper Governance

At CCN level, it is understood that the scope of the SOC will depend on the Organisation to which it provides service and cases may be encountered, in which the SOC only provides a subset of these capabilities.

On the other hand, and based on the knowledge or experience of the people who are part of the SOC, its actions can be classified into the following areas:


where the emphasis is placed on the actions that require knowledge regarding the security technology implemented in the Body for its exploitation.

Public entities

where the emphasis is placed on the actions that require knowledge about the existing actors and threats; their tactics, techniques and procedures (TTP); as well as regarding the entire incident management process.

Public entities

AUDITS area:
where the emphasis is placed on actions that require knowledge about vulnerabilities for their analysis and subsequent mitigation.

Public entities

which groups together those actions which do not require specific knowledge in a specific field.

Implementation graphics
Relationship between the areas of knowledge that participate in each capability.
Implementation graphics
Relationship between the areas of knowledge that participate in each capability.

These areas can help, especially at the beginning, to structure the SOC work teams. So that you can start with three differentiated work teams (Operations, Incidents and Audits), although later and as the SOC grows, they are structured more by competencies.

Cybersecurity competencies

In order to achieve the capabilities previously identified, the SOC must develop a series of competencies which, subsequently and in line with the catalogue of services of the Body, may form part of a specific service or be grouped under a higher level service.


  • Technical Security Inspections: which may be carried out on the infrastructure under production, and/or previously integrated into the software development life cycle, and/or in the start-up of new infrastructures (purchases of printers, projectors, thermostats...); they may be “black box”, “white box” or “grey box”; they may be source code (not running) or running code;...
  • Automated vulnerability scans.
  • Follow-up on the publication of technological vulnerabilities that could affect the Body.
  • Vulnerability management: which may be carried out with specific tools (e.g. ANA), and which would include both the registration and monitoring of the vulnerabilities identified as well as support for the rectification of said vulnerabilities.
  • Training of staff of the Body in security techniques.
  • Raising awareness of the Body's staff about the existing risks.
  • Cyber-surveillance or Digital Surveillance, both on the Internet and on the dark web


  • Protection of traffic, whether peripheral or internal, through the management of firewalls, intruder detection and/or prevention systems...
  • Browsing protection through the management of the proxies, sinkholes (DNS),...
  • Protection of e-mail through the management of antispam systems.
  • Protection of web applications through WAF management or TLS inspection.
  • Protection of remote access through the management of VPNs or access to virtual desktops (VDI).
  • Protection of endpoints and servers through the management of antivirus solutions, EPP, EDR...
  • Protection from data leaks through the management of DLP, IRM solutions...


  • Event logs through centralised servers.
  • Correlation of events through SIEM systems. With the possibility of proactively generating detection rules.
  • Monitoring of alerts deriving from multiple sources such as SAT, SIEM, AntiDDoS...
  • Threat hunting through solutions such as CARMEN, CLAUDIA, EDRs... and making use of shared information such as IoC or TTP (Mitre ATT&CK).


  • Centralised IoC blocking.
  • Incident management, including evidence management, forensic analysis, containment, mitigation and recovery.
  • Malware reversing with laboratories or solutions such as ADA.
  • Exchange of information through MISP, REYES, RNS...
  • Analysis and confirmation of vulnerabilities under attack


  • Advice: Both internally within the SOC as well as with the rest of the Body regarding different aspects of cybersecurity: security architectures, planning and the implementation thereof.
  • Implementation of the ENS.
  • Regulatory development.
  • Risk analysis.
  • Legal and regulatory compliance.
  • Information about Security Status (Dashboards).

Summary table:

Summary table
Summary table

Start-up of a SOC

Not all SOCs have to have the same services, covering all capacities and areas, nor have all the competencies. Multiple factors, including maturity and available resources, will require a decision to be made one way or the other. The rule for the small entity, small SOC (or even not a SOC, when covered by a higher entity), large entity, large SOC, should be the rule to follow.

The steps required to start up a SOC with the support of the CCN-CERT would be the following:

  1. Evaluate the systems to be protected and the security status to determine the exposure surface of the body. With this in mind, ideally a system audit will be carried out. The more complete the audit, the more information you will have about the vulnerabilities and needs of the body. In exceptional cases, the audit may be replaced by interviews that provide the information necessary for the initial assessment. The results of the audit will be reset in the ANA tool to promote the monitoring of the vulnerabilities detected and their correction, in addition to obtaining a systems inventory to speed up notification in the event of the appearance of new vulnerabilities. In terms of another facet, the information obtained about the security status of the organisation will be recorded in the INES tool to contribute to an overview of cybersecurity status at a national level. As an upshot of this initial work, the body can be provided with an initial vision of the security status of the body, an initial risk analysis approach and a first outline of the adaptation plan to the ENS.
  2. Define surveillance objectives. Depending on the results of the audits and interviews, it will be determined what needs to be monitored and with what type of tools.
  3. Define which use case applies to the entity and which alerts can generate value.
  4. Have available metrics of the body's exposure surface. To this end, specific tools must be deployed. This information is very important to ascertain what vulnerabilities the organisation has, being able to determine and prioritise the services and equipment that need attention.
  5. Support the establishment of an EDR in all the organisation's equipment to have a common defence base and source of telemetry for the other SOC services
  6. Provide training on the operation of a SOC.
  7. Support to the drafting of specifications for the contracting of cybersecurity services

Contribution of the CCN

Collaboration requests with the CCN for the deployment of a SOC by a public body can be made by e-mail to the account This email address is being protected from spambots. You need JavaScript enabled to view it., or in the contact section of this website. If necessary for the requesting body, a partnership agreement may be signed. However, in view of the multitude of existing public bodies, this option will be restricted to exceptional cases.


In addition, the CCN-CERT can provide a subset of the total number of tools most commonly used in cybersecurity.

  • Monitoring Tools: these are tools endowed with different levels of complexity which are used by specialised staff to identify events and alerts that require attention.
    • Security equipment administration tools. This group includes centralised administration tools for firewalls, proxies, gateways, antispam etc. They may be at any level of SOCs, being desirable at the lowest level possible.
    • Antivirus (EPP) or Endpoint Detection and Response (EDR):This is the first line of defence and it is installed on all the body's devices (computers, servers, mobile phones etc.). It must be addressed by the lowest level SOC. In addition, it is highly recommended to install the CCN-CERT anti ransomware tool, microCLAUDIA.
    • Intrusion Detection System (IDS) and Intrusion Prevention System (IPS). These are systems that are used to detect or prevent intrusions. They are usually associated with an SIEM system. Due to its cost and complexity, its deployment is only justified in Internet accesses for a large number of users and systems and it should thus be deployed in medium-high level SOCs. Example: SAT-INET probe.
    • Security Information Event Management (SIEM). These are systems which are complicated to install, manage and operate and which require highly specialised, qualified technical staff. Due to the optimisation of resources, it would tend to be used in high-medium level SOCs, centralising low level SOC events where its deployment is not feasible owing to the economising of resources. There is no point in escalating events to multiple SIEMs as this would double the work. The SIEM can serve various bodies if they are grouped in a common SOC. Finally, it is very important to take into account that there is a danger of the overflowing of the logs of said SIEM, so storage based on use cases is very important. Examples: Any SIEM included in the CPSTIC 105 catalogue.
    • Advanced Persistent Threat (APT) detection systems: These are very sophisticated tools that require specialised staff and they must be installed in systems with sensitive information. They are only recommended in very large entities, susceptible to state-sponsored attacks. Example CARMEN
  • Audit tools: they are used to analyse the vulnerabilities of equipment and systems and to be aware of the exposure surface. In the event of any new threat, it can be ascertained which systems and services may be affected. All bodies should conduct audits in the period leading up to the implementation of the SOC. Example: ANA as a repository of audit results
  • SOC's own management tool: ticketing tool for day-to-day security system incidents.
  • Tools for the communication of Security Incidents. LUCIA for the communication and escalation of cybersecurity incidents. It shall be deployed at all levels. In the final analysis, CCN-CERT may intervene to resolve the incident.
  • Cyber intelligence and threat analysis tools, such as REYES.
  • Specific tools for participation in the RNS: As detailed in the Technological Technological Infrastructure section.