Sviluppatori SAP. Meglio un team di sviluppo interno o esterno?

Posted by Massimo Manara on Sep 18, 2019 8:35:00 AM
Massimo Manara
Find me on:

 

Avere all’interno dell’azienda know how anche sulla parte degli sviluppi SAP è sicuramente importante. Soprattutto per non dipendere da terzi anche nel caso di problematiche semplici.

Programmazione sicura SAP

 

Non parliamo direttamente di sviluppatori ABAP. Ma di quali sono o potrebbero essere gli impatti nell’avere un gruppo interno di sviluppatori per quanto riguarda gli aspetti security.

 

È meglio, da un punto di vista di security SAP, avere un team di sviluppo interno oppure esterno?

Come controllare gli sviluppi dal punto di vista security SAP?

Una delle difficoltà maggiori è quella di verificare se gli sviluppi software siano sicuri. Non è semplice farlo in quanto presuppone una conoscenza tecnica molto verticale del linguaggio ed una disponibilità di tempo che può non essere indifferente.

Spesso queste due risorse sono difficili da trovare in azienda e probabilmente anche ingiustificate.

 

Riuscire ad identificare problemi di sicurezza durante lo sviluppo ha costi più bassi rispetto a scoprire anomalie di programmi già attivi ed utilizzati.

 

Esistono diversi modi in SAP per controllare gli sviluppi dal punto di vista della sicurezza.

 

  • Tramite la transazione SCI (Source Code Inspector) di SAP, oppure tramite transazione SE38, vedi immagine sotto è possibile testare i programmi sotto diverse metriche, non solo security SAP:

 

Code Inspector

 

  • Tramite il software a pagamento di SAP chiamato Code Vulnerability Analysis
  • Tramite software terzi, specifici per l’ambito SAP oppure general purpose ad esempio:
    • Onapsis, specifico per SAP
      Guarda qui una video intervista tra Onapsis e Kiuwann
    • Security Bridge specifico per SAP (leggi anche qui)
      • Security Bridge è anche una suite di Threat Intelligence


    • Kiuwan, general purpose
    • CAST, general purpose
    • Fortify, general purpose

 

Cosa può comportare avere un team di sviluppo interno

Nell'attività di supporto che l'IT svolge possono essere presenti diverse tipologie di supporto:

  • In alcuni casi l’IT si sostituisce al business
  • Può non esservi un team coordinato di lavoro. Ogni area di processo lavora in modo autonomo
  • L’IT in caso di urgenze trova la soluzione più veloce, non necessariamente la migliore

 

La sostituzione del business non è mai un modo corretto di gestione (anche se in alcune situazioni può apparentemente semplificare la gestione). Potrebbe infatti portare con se delle anomalie di processo che emergerebbero in fase di separazione dei compiti ad esempio.

 

L'emergenza può portare alla definizione compulsiva di transazioni custom di fatto ad personam. Ogni dipartimento richiede delle personalizzazioni specifiche e non si abitua o trova funzionalità standard che possa essere utilizzata. Spesso confondendo i sistemi transazionali (OLTP Online Transaction Processing) con quelli di analisi (OLAP Online Analysis Processing).

 

Ogni oggetto custom definito nel sistema ha un costo di gestione non indifferente. Molte delle funzionalità custom dopo qualche anno non sono più utilizzate.

 

È meglio un team di sviluppo esterno quindi?

Esistono sicuramente dei vantaggi. Ma anche punti di attenzione da tenere in considerazione.

 

Quali sono i vantaggi di avere un team di sviluppo esterno:

  • Maggiore documentazione e formalizzazione
  • Supporto migliore sui processi di business
  • Maggiore forza lavoro in caso di necessità

 

Attenzione, gli aspetti sopra possono essere dei punti di vantaggio. Ma non sempre è così. Gli accordi contrattuali in alcuni casi potrebbero favorire o sfavorire alcuni comportamenti virtuosi da parte del fornitore di turno.

 

È quindi fondamentale avere internamente un referente che possa capire anche dal punto di vista tecnico le proposte, valutarle prima di procedere con lo sviluppo. Soprattutto sugli aspetti Security SAP.

 

In molti casi, infatti, se nei documenti di specifiche non sono presenti aspetti autorizzativi e/o sviluppo sicuro, questi non sono considerati.

 

È importante inoltre dotarsi di strumenti che possano certificare l’operato di società terze di sviluppo. Gli strumenti citati all'inizio possono essere di aiuto nel definire delle soglie di accettabilità degli sviluppi.

 

Sarà infatti possibile inserire nei contratti delle clausole specifiche di conformità basate su analisi realizzate da strumenti terzi di controllo.

 

Conclusioni, cosa conviene fare?

Non in tutti gli scenari è possibile applicare lo stesso criterio di scelta. Tuttavia, alcune considerazioni possono essere comuni.

  • Avere un referente interno che segua gli sviluppi è fondamentale. Questo permette di valutare cosa viene proposto dall'eventuale fornitore ed effettuare un confronto tra le parti.
  • Appoggiarsi all'esterno è utile, ma se si può controllare in maniera automatica cosa viene fatto e come
  • Lo sviluppo sicuro è alla base della sicurezza applicativa dell'ERP, soprattutto per gli aspetti riguardanti gli sviluppi custom SAP.

Iscriviti al blog se ancora non lo hai fatto!

Topics: programmazione sicura, codice sicuro SAP, CVA

Voglio iscrivermi!

Blog Aglea, cosa puoi trovare?

Ogni mercoledì pubblichiamo articoli, interviste e documenti relativi alla security SAP.

Cosa puoi trovare:

  • Suggerimenti su come mettere in sicurezza i sistemi SAP
  • Come fare a … (How To)
  • Checklist
  • Gli errori comuni che spesso vengono fatti in ambito Security SAP
  • Interviste con esperti del settore
  • Chi è AGLEA quale è la nostra vision security SAP

Post recenti

Post By Topic

Visualizza tutti