=Paper= {{Paper |id=Vol-2940/paper11 |storemode=property |title=Security Testing Reuse Enhancing Active Cyber Defence in Public Administration |pdfUrl=https://ceur-ws.org/Vol-2940/paper11.pdf |volume=Vol-2940 |authors=Christian Catalano,Paolo Afrune,Mario Angelelli,Giovanni Maglio,Fabrizio Striani,Francesco Tommasi,Marco Zuppelli,Luca Caviglione,Matteo Repetto,Marco Bozzetti,Luca Olivieri,Fausto Spoto,Axel De Nardin,Marino Miculan,Claudio Piciarelli,Gian Luca Foresti,Alessandro Bocci,Stefano Forti,Gian-Luigi Ferrari,Antonio Brogi,Tobia Fiorese,Pietro Montino,Roberto De Prisco,Alfredo De Santis,Rocco Zaccagnino,Daniele Granata,Massimiliano Rak,Giovanni Salzillo,Umberto Barbato,Giuseppe Mario Malandrone,Giovanni Virdis,Giorgio Giacinto,Davide Maiorca,Dario Stabili,Francesco Pollicino,Alessio Rota,Shaharyar Khan,Alberto Volpatto,Geet Kalra,Jonathan Esteban,Tommaso Pescanoce,Sabino Caporusso,Michael Siegel,Alessia Boi,Carmelo Ardito,Tommaso Di Noia,Eugenio Di Sciascio,Domenico Lofù,Andrea Pazienza,Felice Vitulano,Giulio Berra,Gaspare Ferraro,Matteo Fornero,Nicolò Maunero,Paolo Prinetto,Gianluca Roascio,Luigi Coppolino,Salvatore D'Antonio,Giovanni Mazzeo,Luigi Romano,Paolo Campegiani,Vincenzo Dentamaro,Vito Nicola Convertini,Stefano Galantucci,Paolo Giglio,Tonino Palmisano,Giuseppe Pirlo,Massimiliano Masi,Tanja Pavleska,Simone Pezzoli,Massimiliano Calani,Giovanni Denaro,Alberto Leporati,Manuel Cheminod,Luca Durante,Lucia Seno,Adriano Valenzano,Mario Ciampi,Fabrizio Marangio,Giovanni Schmid,Mario Sicuranza,Marco Zuppelli,Giuseppe Manco,Luca Caviglione,Massimo Guarascio,Marzio Di Feo,Simone Raponi,Maurantonio Caprolu,Roberto Di Pietro,Paolo Spagnoletti,Federica Ceci,Andrea Salvi,Vincenzo Carletti,Antonio Greco,Alessia Saggese,Mario Vento,Gabriele Costa,Enrico Russo,Andrea Valenza,Giuseppe Amato,Simone Ciccarone,Pasquale Digregorio,Giuseppe Natalucci,Giovanni Lagorio,Marina Ribaudo,Alessandro Armando,Francesco Benvenuto,Francesco Palmarini,Riccardo Focardi,Flaminia Luccio,Edoardo Di Paolo,Enrico Bassetti,Angelo Spognardi,Anna Pagnacco,Vita Santa Barletta,Paolo Buono,Danilo Caivano,Giovanni Dimauro,Antonio Pontrelli,Chinmay Siwach,Gabriele Costa,Rocco De Nicola,Carmelo Ardito,Yashar Deldjoo,Eugenio Di Sciascio,Fatemeh Nazary,Vishnu Ramesh,Sara Abraham,Vinod P,Isham Mohamed,Corrado A. Visaggio,Sonia Laudanna |dblpUrl=https://dblp.org/rec/conf/itasec/CatalanoAAMST21 }} ==Security Testing Reuse Enhancing Active Cyber Defence in Public Administration== https://ceur-ws.org/Vol-2940/paper11.pdf
Security Testing Reuse enhancing active cyber
defence in Public Administration
Christian Catalano1,2 , Paolo Afrune1,2 , Mario Angelelli1,3 , Giovanni Maglio2 ,
Fabrizio Striani1,3 and Franco Tommasi1,3
1
  Department of Innovation Engineering, University of Salento, Lecce (IT)
2
  Cybersecurity Research Lab (CRlab), University of Salento
3
  Centre of Applied Mathematics and Physics for Innovation (CAMPI), University of Salento


                                         Abstract
                                         The pervasive use of new technologies in sensitive contexts (e.g. management of critical infrastructures)
                                         is leading nation states to protect the cyber domain through the creation of governmental bodies with
                                         this specific responsibility. This requires the definition of specific protocols to manage different attack
                                         scenarios, rules, guidelines, and behaviors. Public administrations must follow such protocols to develop
                                         an appropriate cyber defence capability.
                                              The aim of this paper is to introduce a new high-level framework to improve proactive cyber defence
                                         in the current Italian Public Administration. The general objective is to promote the reuse of information
                                         coming from security tests in order to optimise local resources while meeting global (national level)
                                         normative requirements and cybersecurity good practices. Protocols for different scenarios are described
                                         and expected micro-/macro-economic effects are discussed.

                                         Keywords
                                         Security management and governance, Proactive cyber defence, Security testing, Information reuse




1. Introduction
The use of ICTs in sensitive public contexts (e.g. public health care, management of power plants,
etc.), in combination with private citizens’ communication, is leading Public Organizations to
consider compliance with law and defence against malicious cyber attacks as a matter of vital
importance.
   Due to the level of connectivity entailed by digital transformation, information management,
which has always been an important but cross-sectoral factor related to specific domains, is
now an asset with its own characteristics. In this framework we now refer to cyberwarfare [1, 2]
as the use of ICTs to support military attacks against a country. We also mention the fifth
dimension of warfare, which includes “information” among the domains to be protected, in
addition to the classic ones (air, ground, space, and sea).
   As a consequence, nation states are actively protecting this new domain through the creation
of governmental bodies with such specific responsibility, defining specific protocols for given
circumstances and attack scenarios, rules, guidelines [3, 4, 5, 6, 7], and behaviors [8] that Public

ITASEC – Italian Conference on CyberSecurity, April 7-9, 2021
" mario.angelelli@unisalento.it (M. Angelelli)
                                       © 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
    CEUR
    Workshop
    Proceedings
                  http://ceur-ws.org
                  ISSN 1613-0073       CEUR Workshop Proceedings (CEUR-WS.org)
Administrations must follow. In addition to internal rules defined by individual states for their
own protection, members of the European Union also follow European regulations, such as
NIS Dir. Ue n. 1148/16, Cybersecurity Act Reg. Ue n. 881/19, and Reg. UE n. 679/16, so
called GDPR [9]. The defence of this new domain is neither simple nor straightforward, even
following the recommendation of the nation states or the European Union: in fact, several factors
contribute to the discrepancy between the rate of technological evolution and the adaptation
time needed by public organizational structures or internal bodies.
   In this contribution, we present a new proposal to improve proactive cyber defence in a
specific scenario, that is the current Italian Public Administration (hereafter PA). This objec-
tive relies on operational and organisational adaption of processes in PA to already existing
technologies, which motivates us in focusing on high-level, non-technical descriptions of the
phases characterising proactive defence through security test reuse.
   We start with a brief introduction to the current Italian context, highlighting the strengths
as well as organizational challenges related to cyber defence in the PA. Then, we provide a
description of our proposal, which aims at improving the resilience of the country system and
developing an “active” (i.e. proactively defensive) cyber defence capability.
   Specifically, we propose a variation of code reuse, namely, the reuse of results of Security
Testing performed locally (e.g. Penetration Testing performed by local PA nodes present on the
national territory) through a nation-level centralization. The main goal of this new framework
is to enhance the protection of the most vulnerable links (local PAs) of a complex system (the
National PA) while optimizing public resources.


2. Scenario Specification
2.1. Current situation in Italian PA
The context where the present proposal has been conceived is the current state of cybersecurity
in Italian PA. Starting from the need to protect the Information domain, the notion of Information
defence has been recently defined by the Italian law (2013, subsequently revised and adapted in
2017) with the aim of defining protocols to manage critical situations.
   The current definition of the national cyber defence system involves several actors, among
which the Prime Minister, the Interministerial Committee for the Security of the Republic
(CISR), the Department of Information for Security (DIS), the External Information and Security
Agency (AISE), and the Internal Information and Security Agency (AISI). More recently (2019)
regulators have provided a clearer definition of national cyber security standards with regard
to prevention and response to cyber events, with the aim of ensuring a high level of security
of the networks, ICTs and IT services for PAs and public or private entities operating in the
national territory.

2.2. Software development and Public Administrations
Beside the reaction to ongoing attacks, a fundamental approach to avoid damages in the
Information domain is to prevent cyber attacks (“Prevention for Mitigation”). With regard to
proactive defence, AgID defined the guidelines for the acquisition and reuse of software for
public administrations (May 9, 2019) with the aim of reducing costs of PAs. These guidelines
require that the source code of the software produced by PAs (either on commission or through
internal resources) be released as an open source project, so that other PAs can reuse the
software. However, a PA node is not forced to use the software produced by other PAs. In fact,
the guidelines describe the selection process in three steps [10]:
   1. first phase: identification of needs;
   2. second phase: analysis of the solutions available in the catalog of reusable code and open
      source solutions;
   3. third phase: analysis of other solutions.
   Each phase is preliminary and mandatory for the following ones. The third phase is divided
into two sub-phases, where both the feasibility of the implementation of a new solution and the
adoption of current proprietary ones are studied; the administrations are required to carry out
both analyses, which will be compared during the choice phase (“make or buy” evaluation).
   In particular, the solutions taken into consideration during the research phase must meet
a series of constraints and criteria; in any case, if even one of the constraints is not met, the
solution cannot be eligible. However, external constraints (time constraints, specificity of the
issue raised by the PA node, etc.) may lead PAs to find and adopt proprietary software meeting
all the constraints more likely than software-reusing solutions.
   It is also stressed that proprietary software is often designed for a specific context, therefore
its characteristics and configuration strongly depend on the laws and organization of the state
(Italy in the present discussion). This also leads to consider such proprietary solutions as “niche
products” since software produced for Italian PA is often not under the eye of the ethical hacker
community and software houses rarely organize bug bounty programs[11].

2.3. Strengths and limitations of the current system
The development of national cybersecurity strategies has received interest because they have
the potential to align the needs of national security with those of economic growth: the latter
promote proactive security for the design of all digital policies. Indeed, proactive defence can
increase the ability to prevent, deter, and detect cyber attacks response in a coordinated manner,
including the different institutions involved in the cybersecurity framework.
  There are different approaches regarding the countermeasures that a private company or
a public body can adopt to prevent possible attacks to its infrastructures. Among them we
mention:
   1. Vulnerability assessment (VA) and Penetration testing (PT) [12, 13, 14]: the former allows
      to identify possible vulnerabilities within a network, while the latter consists in identifying
      and exploiting the vulnerabilities (already known ones and new 0days [15]) in order to
      take control of the system, as it happens in real attacks.
   2. Static [16] and dynamic analysis of applications [17]: static analysis makes it possible
      to analyze a program without running it. This analysis can be done on the source code,
      or from the software executable (reverse engineering). Dynamic analysis consists in
      analyzing the software during its execution. Unlike static analysis, the result of dynamic
      analysis may depend on the input used.
   3. Semi-automatic tools: these tools perform a check for known vulnerabilities. Then, the
      results are analyzed by a human eye [18].
   While such approaches are well suited for anticipating possible consequences in the event
of cyber attacks, in practice they present issues that cannot be ignored. Taking up some of
the challenges presented in “The future of Cybersecurity in Italy: Strategic focus areas” white
paper [8], we mention:
   1. Verification costs: this is probably the most important aspect. In fact, not every company
      or entity can handle security costs, especially when the infrastructure to be protected
      frequently changes.
   2. Certifiability and verifiability of analysis: they ensure that a vulnerability found
      during an analysis is reproducible, and then verifiable.
   3. Limits of automatic tools: automated tools can only give an idea of what are the
      possible vulnerabilities in the assets under analysis. Specifically, some errors that arise
      from a human factor cannot be found automatically. In addition, some software makes
      automatic analysis difficult because of the adopted language: for example, interpreted
      languages, such as JavaScript, allows code injection.
   4. Vulnerabilities in specific IT environments and contexts: this aspect is related to the
      previous one. Some vulnerabilities might emerge primarily as a result of the introduction
      of a given set of inputs. Therefore, the occurrence of vulnerabilities that are unlikely
      in a generic scenario might instead become more likely in specific application contexts.
      These vulnerabilities may therefore lead to a higher probability of intrusion and represent
      weaknesses for the entire ICT infrastructure.
   5. Environments for the security analysis of interoperable systems: real testbeds for
      experimental analysis of third-party solutions, or solutions that come from untrusted
      sources.


3. Framework proposal
Based on the previous discussion, we introduce a proposal to promote proactive security and
increase the ability to prevent, deter, and detect cyber attacks in a coordinated manner with the
various institutions involved in order to meet some of the challenges highlighted in the White
Paper.
   The proposal consists in the high-level design of a new class of processes to manage infor-
mation content regarding security tests as a resource. The expected effect of this design is to
introduce a new observable criterion, i.e. the useful information content regarding security test,
to formalise and enhance the concrete implementation of secure connections among nodes of
the PA. This criterion not only can integrate the effective approaches and in-use recommenda-
tions with active cyber defence capability, but also represents an explicit discrimination among
different nodes of the PA: the information content can be shared and accessed only based on the
actual security needs of the different nodes of the PA, beyond their functionalities. In addition,
our solution encompasses in a natural way the guidelines issued by AgID regarding code reuse
for PAs: specifically, it solves several limitations of the current organization also highlighted in
the White Paper, directly addressing the code reuse paradigm.
   In order to clarify the points addressed by our proposal, we start from cost reduction for
verification, which represents a major limitation for some institutions (such as small PAs). Then,
software solutions adopted in distinct nodes with similar needs may take advantage from the
reuse of security tests and the information on bug fixing: this can result in a larger set of
in-use solutions to evaluate and update before moving to other proprietary software, which
prompts cost reduction and enhances the adoption of certified and verified solutions. Finally, it
is worth stressing that this approach could also solve the limitation introduced by automated
tools, since the time saved in the analysis phase allows to transfer resources for additional,
in-depth analyses. In this regard, multiple tests on software assets may be needed in order to
explore vulnerabilities arising in different configuration settings: we stress that these tests do
not represent redundancy, instead they improve the accuracy of PT/VA exploring potential
vulnerabilities in different environments.

3.1. Details of the proposal
As well as for software, behind the concept of “reuse” there is the observation that different PAs
acting in a common context often share the same solutions, either from AgID-promoted reuse
or from proprietary solutions. As a consequence, in the case of VA/PT, the same components
could be analyzed. The first implication is the violation of one of the main desiderata we want
to satisfy, that is, cost minimization. An approach to solve this issue is to avoid redundant
double-checks through the sharing of reports from VAs and/or PTs carried out by PAs. In
particular, this allows to:
   1. minimize costs: it is the obvious consequence of sharing. In this way, it is possible to
      analyze in detail only those solutions that are not yet equipped with security test results
      or with specific configurations;
   2. support small PAs in the protection of their assets: shared results should be available
      to all PAs (limited to those concerned, for obvious security reasons). In this way, even
      PAs that are not capable of in-depth analysis can provide an appropriate level of security.
      At a deeper level of detail, the results could be accessible only to a given set of PA nodes,
      e.g. those nodes that have adopted the same software (nominal approach) or those that
      perform similar functions (functional approach);
   3. notifying new vulnerabilities: the technical manager of a PA can be directly notified
      about new vulnerabilities in the assets he is in charge of. Furthermore, these communica-
      tions can certify that updates have been notified, so the manager is required to update
      the system accordingly.
Given the sensitive context, results cannot be publicly shared and access must be granted only
to certain specific entities. In addition, results should be made available without providing
information about the PA that performed the test in order not to disclose its technological
infrastructure. In any case, information can be shared only after the security bugs found have
been fixed (case zero).
   Operationally, this proposal requires both a dedicated platform, which establishes an official
communication channel for notifications and information exchange encompassing the whole
network, and an active participation of the technical staff in charge of its management. For
each PA node, the technical managers should be involved whether the PA receives a report after
a security test, or after a modification of the assets. In detail:
   1. The PA that has carried out the security test first verifies that the discovered vulnerabilities
      have been resolved by the vendor; then, the PA uploads the results on the platform
      specifying vendor, product, version, and impact of the vulnerability (CVSS score [19])
      with a description of such vulnerability. It is also possible to indicate who carried out the
      test.
   2. The PA that modifies its technological infrastructure, in terms of both hardware and
      software assets, updates these changes on the platform. In this way it can be notified for
      any already known problem, or for future ones.
Organisations such as CSIRTs are natural candidates to manage the platform, but the proposed
framework introduces a bottom-up approach beyond the scope of CSIRTs: information and
queries on security tests come from PA nodes and actively involve the whole PA network,
including small PAs.

3.2. Diagrammatic representation of process schemes
The logical flow of interactions to enable Security Tests reuse is mainly determined by re-
quirements. We start from the constraint coming from the current AgID guidelines and good
practices in PT/VA.

    • Security Test execution (e.g. PT) must be conducted by a third party vendor and must not
      be performed by the PA or the vendor that developed the software.
    • There are standard scenarios that should be considered by any PA: information acquisition
      associated to new software introduced in the PA node; information retrieval and update
      regarding existing software in the PA node; information retrieval and update regarding
      new software in the PA node.
    • there exists non-standard, context-based scenarios that may generate new process schemes.
      This eventuality has to be considered by default, in order to trace, assess, and possibly
      accept the process or correct it.

  In order to contextualize the following process schemes in the same scenario while complying
with the previous requirement regardless of the software being analyzed, we will adopt the
convention of two distinct actors, associated respectively to software sales and to PT/VA services.
Actors:

    • PA (1, 2, 3, . . . ): public administration;
    • SW-1: Software vendor. This actor develops, customizes, and sells the software to PAs;
    • PT-1: Security test vendor. This actor sells security tests to public administrations;
    • PLATFORM: the platform.
3.2.1. Process scheme 1
  1. PA1 buys software from SW-V1
  2. SW-V1 provides the software to PA1 (e.g. sw_calcoloImu v1.0)
  3. PA1 requires a security testing service from PT-V2
  4. PT-V2 executes the security test and provides the report regarding security bugs and 0day
     to PA1
  5. PA1 sends the security bugs and 0days found during the security test to SW-V1 and
     requests the bug fixing of the software (e.g. sw1_calcoloImu v1.0)
  6. SW-V1 executes bug fixing on the software according to the agreement between all parts
     (e.g. sw_calcoloImu v1.0)
  7. SW-V1 releases the fixed version of the software (e.g. sw1_calcoloImu v2.0)
  8. PA1 uploads on the platform the security bugs found during the security testing (e.g.
     security bug and/or 0day) for software version 1 (e.g. sw1_calcoloImu v1.0) developed
     by SW-V1
  9. PLATFORM notifies all PAs that have registered the software on the platform for vulnera-
     bilities that have been added on the specific software version
 10. Every single PA checks the software for which a vulnerability has been reported. At this
     point there are two possibilities:
        a) the PA has the vulnerable software
        b) the PA no longer has the software among its assets
 11. PA2 requires the latest version of the software to SW-V1
 12. SW-V1 releases to PA2 the latest version of software the (e.g. sw1_calcoloImu v2.0)


3.2.2. Process scheme 2
  1. PA1 requires to PLATFORM an updated list of vulnerabilities regarding their software
     assets
  2. PLATFORM provides the vulnerability list to PA1 for every single software owned by PA1
  3. PA1 analyzes the vulnerability list from PLATFORM. The list can be made as follows:
       a) it contains recent information for some components owned by PA1
              i. PA1 contacts SW-V1 for bug fixing of information that meets 3.(a)
             ii. SW-V1 provides the fixed version
       b) it contains outdated information (e.g. the date of the last security test performed on
           a single software version is older than 6 months) or does not contain information
          (e.g. some security test has never been performed on that specific software version)
           for some components owned by PA1
              i. PA1 requires a security test to PT-V2 regarding the assets that satisfy point 3.(b)
             ii. PT-V2 executes the security test and provides the report regarding security
                 bugs and 0day to PA1
            iii. PA1 updates its assets based on the report provided by PT-V2
            iv. PA1 uploads the results of the security test on PLATFORM
Figure 1: Process scheme 1


   Note that the attributes “recent information” and “outdated information” in Point 3 of Process
scheme 2 are related to implementation aspects that are independent of the proposed logical
structure. That is, the attributes may depend on factors such as the addition of new functionalities
to the software under consideration, individual assessments by the PA, or criteria related to the
periodicity of testing based on safe software management guidelines (e.g., “to be performed
preferably every 6 months”).

3.2.3. Process scheme 3
   1. PA1 buys new software assets from SW-V1
   2. SW-V1 provides the assets to PA1
   3. PA1 updates its inventory by adding newly acquired assets
   4. PA1 adds newly acquired assets to PLATFORM
   5. PLATFORM provides a list of known vulnerabilities regarding the latest assets added
      based on the information provided to the platform
   6. PA1 analyzes the report to check that all new assets are up-to-date and have no known
      vulnerabilities
Figure 2: Process scheme 2




Figure 3: Process scheme 3


4. Expected measurable economic effects
The implementation of the reuse of results of PTs described above could bring effective ad-
vantages both from a microeconomic and a macroeconomic point of view. These advantages
represent a tangible, i.e. measurable effects, since the economic indicators can be assessed to
evaluate the effectiveness of the proposed approach at different scales:

    • improved evaluation of public spending policies: if the description of some vulnerabilities
      has emerged during the execution of a PT and the information regarding the patched
      version of the same software under test is available, public spending can be reallocated
      on different investments;
    • competitive advantage for territorial ecosystems: the whole country system would gain
      competitive advantage, for example through the empowerment of PAs that are unable
      to execute PT in a regular and constant manner due to budget issues or difficulties in
      finding specialized personnel;
    • support to policy makers in the spending review, based on secure information from a
      trusted network;
    • choice of the different sectors where to intervene: saving in a sector enables potential
      reinvestments in other ones (e.g. cultural goods, environment, health, etc.).

   We can identify some advantages from the microeconomic point of view using the concept of
economies of scope: with this term we refer to the savings resulting from the joint production of
different products, or the pursuit of different objectives through the use of the same production
factors. In this way, one can reach the production of different types of goods with the same class
of resources. Using this notion, it is easy to identify the effects of the reuse of PTs results as
the benefits of the investments made by an individual entity of the PA for all the other entities
sharing the same need.
   On the other hand, the proposal would also have a macroeconomic effect due to the consider-
able savings by the PA. In order to quantify them, we start from the public savings in formula
𝑆𝑝𝑢𝑏𝑏 = 𝑇 − 𝐺: a lowering of the public expenditure (𝐺) would mean greater public savings,
which could allow a lowering of taxes (𝑇 ). It is also worth recalling that overall savings are
given by 𝑆 = 𝑆𝑝𝑟𝑖𝑣 + 𝑆𝑝𝑢𝑏𝑏 . Therefore, greater public savings would lead to greater overall
savings. In the Keynesian theory, the macroeconomic identity 𝑆 = 𝐼 applies. Then it is evident
that the increment of the overall savings corresponds to increased investment (𝐼) and, therefore,
prompts an overall improvement in national GDP.
   Macroeconomic advantage emerges not only from greater economic-financial resources
that may cover different needs, but also in terms of redefinition of strategies shared among
different local nodes of the PA. A modification of the structure of information sharing entails
a corresponding change in the set of feasible solutions or policies for resource allocation;
in particular, the present approach does not exclude possible strategies, but it introduces
new ones. A practical example is the reuse of useful information from VA/PT carried out on
some specific components of a given asset: if a PA node does not have sufficient resources to
ensure the fulfillment of all the criteria required by national guidelines, it can limit to recover
missing information, assuming that complementary information is already available after testing
and sharing actions by other nodes. In principle, this knowledge can support the strategic
administrative planning of individual nodes, bringing possible reciprocal benefits.
   Finally, the reuse of security tests or, more precisely, of the useful information they provide,
can also lead to advantages at supranational, e.g. European level. This aspect concerns the
adherence of the policies adopted by the EU with regard to open data. Moreover, the reuse of
information coming from security tests can be configured as a secure-by-design channel of
communication between two types of actors, namely, the purely national level (PA) and the
international level (vendors).
5. Conclusions and future work
This contribution proposes a new framework that aims at supporting national PA in meeting the
requirements posed by digital transformation in compliance with European recommendations.
In turn, this framework also paves the way for new savings and business opportunities for
public and private Organizations.
   There are several research directions to refine this proposal: first, information coming from
the reuse of security tests assumes new value, which can become a new asset for Organizations.
The added value brought by information sharing can be exploited to explore new organization
reward models with the goal of enhancing transparency in PA-oriented cybersecurity. Such a
perspective is set up as a form of circular economy with immaterial resources, which is strategically
important not only for individual PA nodes, but also for the country system and, more generally,
for the EU. Also Vendors could get benefits from such an framework: increased transparency
in the security testing requirements for a specific node of the network may integrate partial
information already available to the PAs, both in terms of reduction of fallacies in the testing
process (for instance, violations of the condition in the Guidelines) and market access beyond
the local scale (i.e. countrywide).
   In this work we have presented a high-level structure without providing a specific real-case
context: this approach is motivated by the possibilities offered by this level of abstraction, since
the proposed scheme may be adapted to several distinct contexts. There may be situations
where different security needs and conflicting requirements (e.g. confidentiality vs. accessibility)
lead to ad hoc implementations of this framework. For instance, new security layers may be
introduced, where different offices or Entities within the stratified PA structure have their own
security requirements and associated counteractions. The opportunity to adapt the logical
structure to the contextual characteristics of nodes fits well with the complexity of Italian PA
and may enhance secure information sharing between central and local/periferic levels. On the
other hand, the context-dependent implementation of the present framework, which is typical
of large-scale technological systems, requires specific validation procedures for each context.
   In this way, the proposed framework:

    • introduces data separation in the access to information, making information exchange
      asymmetric between these layers as formally defined by the Principle of Least Privi-
      lege [20]: local layers cannot access to central information preventing vertical privilege
      escalation access;
    • may support the definition of communication layers (e.g. alerts) based on specific secu-
      rity qualification levels that are expected or required at each node. This enhancement
      may stimulate a clearer definition of fields of competence and responsibilities related to
      cybersecurity in the PA, in order to send relevant information to target Entities that are
      able to interpret it and counteract cyber-risks;
    • allows to share information without getting access to the original data (e.g. original
      reports), which may be confidential. We can get the access to information without
      disclosure providing only confirmation for specific queries by a node of the PA regarding
      its software assets, which promote the required counteractions and enhance, rather than
      compromise, the security of the PA network.
References
 [1] J. Carr, Inside cyber warfare: Mapping the cyber underworld, O’Reilly Media, Inc., 2012.
 [2] V. A. Almeida, D. Doneda, J. de Souza Abreu, Cyberwarfare and digital governance, IEEE
     Internet Computing 21 (2017) 68–71.
 [3] AgID, Linee guida di sicurezza nello sviluppo delle applicazioni, https://www.agid.gov.
     it/sites/default/files/repository_files/documentazione/lineeguidasicurezza-introduzione.
     pdf, 2017.
 [4] AgID, Linee guida per l’adozione di un ciclo di sviluppo di software sicuro,
     https://www.agid.gov.it/sites/default/files/repository_files/allegato_1-_linee_guida_per_
     ladozione_di_un_ciclo_di_sviluppo_di_software_sicuro.pdf, 2020.
 [5] AgID, Linee guida per lo sviluppo sicuro, https://www.agid.gov.it/sites/default/files/
     repository_files/allegato_2_-_linee_guida_per_lo_sviluppo_sicuro_di_codice.pdf, 2020.
 [6] AgID, Linee guida per la configurazione per adeguare la sicurezza del software di
     base, https://www.agid.gov.it/sites/default/files/repository_files/allegato_3_-_linee_guida_
     per_la_configurazione_per_adeguare_la_sicurezza_del_software_di_base.pdf, 2020.
 [7] AgID, Linee guida per la modellazione delle minacce ed individuazione delle
     azioni di mitigazione conformi ai principi del secure/privacy by design,
     https://www.agid.gov.it/sites/default/files/repository_files/allegato_4_-_linee_guida_
     per_la_modellazione_delle_minacce-dlt.pdf, 2020.
 [8] R. Baldoni, R. De Nicola, P. Prinetto, Il futuro della cybersecurity in italia: Ambiti progettuali
     strategici progetti e azioni per difendere al meglio il paese dagli attacchi informatici,
     Laboratorio Nazionale di Cybersecurity (CINI)-Consorzio Interuniversitario Nazionale per
     l’Informatica (2018).
 [9] P. Voigt, A. Von dem Bussche, The eu general data protection regulation (gdpr), A Practical
     Guide, 1st Ed., Cham: Springer International Publishing 10 (2017) 3152676.
[10] AgID, Linee guida su acquisizione e riuso di software per le pubbliche
     amministrazioni,                https://www.agid.gov.it/sites/default/files/repository_files/
     lg-acquisizione-e-riuso-software-per-pa-docs_pubblicata.pdf, 2019.
[11] A. Kuehn, M. Mueller, Analyzing bug bounty programs: An institutional perspective on
     the economics of software vulnerabilities, in: 2014 TPRC Conference Paper, 2014.
[12] J. N. Goel, B. M. Mehtre, Vulnerability assessment & penetration testing as a cyber defence
     technology, Procedia Computer Science 57 (2015) 710–715.
[13] I. Yaqoob, S. A. Hussain, S. Mamoon, N. Naseer, J. Akram, A. ur Rehman, Penetration
     testing and vulnerability assessment, Journal of Network Communications and Emerging
     Technologies (JNCET) www. jncet. org 7 (2017).
[14] P. S. Shinde, S. B. Ardhapurkar, Cyber security analysis using vulnerability assessment
     and penetration testing, in: 2016 World Conference on Futuristic Trends in Research and
     Innovation for Social Welfare (Startup Conclave), 2016, pp. 1–5. doi:10.1109/STARTUP.
     2016.7583912.
[15] M. A. McQueen, T. A. McQueen, W. F. Boyer, M. R. Chaffin, Empirical estimates and
     observations of 0day vulnerabilities, in: 2009 42nd Hawaii International Conference on
     System Sciences, IEEE, 2009, pp. 1–12.
[16] P. Ferrara, F. Spoto, Static analysis for gdpr compliance., in: ITASEC, 2018.
[17] T. Ball, The concept of dynamic analysis, in: Software Engineering—ESEC/FSE’99, Springer,
     1999, pp. 216–234.
[18] Y. Stefinko, A. Piskozub, R. Banakh, misc and automated penetration testing. benefits and
     drawbacks. modern tendency, in: 2016 13th International Conference on Modern Problems
     of Radio Engineering, Telecommunications and Computer Science (TCSET), IEEE, 2016,
     pp. 488–491.
[19] P. Mell, K. Scarfone, S. Romanosky, A complete guide to the common vulnerability scoring
     system version 2.0, in: Published by FIRST-forum of incident response and security teams,
     volume 1, 2007, p. 23.
[20] F. B. Schneider, Least privilege and more, in: Monographs in Computer Science, Springer-
     Verlag, 2003, pp. 253–258. URL: https://doi.org/10.1007%2F0-387-21821-1_38. doi:10.1007/
     0-387-21821-1_38.