Mesures per SSDLC (cicle de vida segur de desenvolupament de programari)

measures ssdlc

Obteniu informació sobre diverses mesures de seguretat a implementar per a un SDLC o SSDLC segur:

Com que la tecnologia creix ràpidament, les amenaces relacionades amb la seguretat de pirateria i robatori de dades segures també han augmentat en conseqüència. Per tant, no hi ha dubte que el creixement de la tecnologia llança desafiaments als fabricants de programari per garantir que el seu programari sigui fort i robust contra les amenaces i vulnerabilitats de seguretat.

No es pot publicar un producte de programari, fins i tot si funciona perfectament per a la funcionalitat prevista, tret que demostri ser altament segur i compleixi els estàndards de seguretat i privadesa especificats i regulats, especialment en sectors com Defensa, Finances i Assistència sanitària que impliquen dades personals i financeres. .

No es pot permetre el luxe de tenir un defecte de seguretat al producte quan es desplega, ja sigui de gravetat alta o mitjana. Per tant, és molt essencial protegir el programari i les dades de qualsevol tipus d’atac, amenaces malicioses, vulnerabilitats i garantir la fiabilitat del programari per a l’usuari final.

A diferència del nostre desenvolupament de programari tradicional, les proves en l'última fase després de desenvolupar tot el programari no són més efectives. Amb la implementació del concepte Agile, DevOps i ShiftLeft, és essencial dur a terme les proves tan aviat com en totes les fases del cicle de vida de l’aplicació.

Dit això, la seguretat del programari no es pot crear ni tan sols provar en l'última etapa i, per tant, s'ha de construir en totes les fases per garantir la seguretat total del programari.

Què aprendreu:

• Mesures de seguretat per a SSDLC
  • # 1) Fase de requisits
  • # 2) Fase de planificació
  • # 3) Fase d’Arquitectura i Disseny
  • # 4) Fase de desenvolupament
  • # 5) Fase d'implementació
  • # 6) Prova: fase prèvia al desplegament
• Resum tabular per a SSDLC
• Conclusió
  • Lectura recomanada

Mesures de seguretat per a SSDLC

A continuació s’enumeren els diferents mitjans de mesures relacionades amb la seguretat que es poden implementar durant tot el cicle de vida del desenvolupament de programari per tal de garantir SDLC o SSDLC segurs i, en la mesura del possible, no es permet que els defectes continuïn a la següent fase.

Hi ha diverses anàlisis i avaluacions de seguretat en què cal construir seguretat en fases SDLC.

1. Fase de requisits
2. Fase de Planificació
3. Fase d'Arquitectura i Disseny: Avaluació de riscos de seguretat basada en el disseny.
4. Fase de desenvolupament: Secure Code Analysis, una anàlisi estàtica del codi per a la seguretat.
5. Fase d'implementació: Dynamic Code Analysis, una prova de seguretat de l'aplicació.
6. Proves: fase prèvia al desplegament: Proves de penetració i anàlisi de vulnerabilitat.

# 1) Fase de requisits

• Principalment, per tal d’assegurar que s’incorporin les mesures de seguretat necessàries al programari, Requisits específics relacionats amb la seguretat han de ser capturats clarament durant la fase de requisits amb prou detalls i resultats esperats.
• Tot i identificar els casos d’ús típics i els escenaris empresarials, un conjunt clar de Casos d'ús i escenaris relacionats amb la seguretat a efectes de verificació, cal identificar-los per capturar les característiques de seguretat i dissenyar escenaris de proves de seguretat.

A continuació, es mostren alguns exemples d'exemple que il·lustren els requisits explícits relacionats amb la seguretat que es poden capturar.

Sec-Req-01: El sistema ha de tenir mesures d’autenticació a totes les portes d’entrada i punts d’entrada.

Sec-Req-02: El sistema és necessari per implementar l’autenticació mitjançant una pantalla d’inici de sessió segura.

Sec-Req-03: Les dades personals s’encriptaran en repòs.

# 2) Fase de planificació

A un nivell alt, però no només limitat a aquests, cal tenir en compte els següents punts a la fase de planificació.

programari escrit en c ++

• Un fort, Equip de seguretat dedicat , que funciona fora de la PMO (oficina de gestió de projectes) de l 'equip del programa, format per Oficial de seguretat, arquitectes de seguretat, verificadors de seguretat que es formi per dur a terme i gestionar totes les activitats relacionades amb la seguretat del programa de manera imparcial. Per a cadascun d’aquests rols, es defineixen un RnR (rols i responsabilitats) i RACI clars.
• Cap escalades, ambigüitats El PSO (Product Security Officer) ha de gestionar els problemes relacionats amb la seguretat perquè l'equip de seguretat funcioni sense problemes i ajudi a prendre les decisions correctes.
• Un robust Estratègia de proves de seguretat especificant com implementar els requisits relacionats amb la seguretat, com, quan i què provar, quines eines s’han d’utilitzar en cada etapa, cal identificar-se.
• És obligatori incloure el Punt de contacte de seguretat per a totes les discussions tècniques / de revisió relacionades amb el programa perquè l'equip de seguretat tingui coneixement dels canvis que es produeixin al programa.

# 3) Fase d’Arquitectura i Disseny

Prestar més atenció als aspectes de seguretat al principi durant la fase de disseny ajudarà a prevenir els riscos de seguretat i a reduir els esforços considerables en els canvis de disseny més endavant al SDLC.

Tot el possible per dissenyar el programari i la infraestructura on s’allotjarà el programari Implementacions de disseny de seguretat han d’estar ben dissenyats amb la participació dels arquitectes de seguretat.

Qualsevol ambigüitat i conflicte entre els aspectes funcionals i no funcionals del disseny i l'arquitectura han de ser resolts mitjançant sessions de pluja d'idees que impliquin els grups d'interès adequats.

Durant aquesta fase, es fa una avaluació detallada del risc de seguretat del producte, que de vegades també s’anomena 'Avaluació estàtica' l’ha de dur a terme l’equip d’experts en seguretat.

Avaluació de riscos de seguretat inclou una revisió dels programes des del punt de vista de la seguretat en la fase preliminar de disseny / arquitectura per identificar els defectes relacionats amb la seguretat des de la perspectiva del disseny i, en conseqüència, elevar el producte. Riscos de seguretat a l’equip del projecte per abordar-los i evitar entrar a la següent fase.

Aquestes avaluacions es realitzen sobre la base de les directrius, normes i controls de seguretat organitzacional / industrial esmentats en aquests documents. Per exemple. UXW 00320, UXW 030017

Durant l'avaluació del risc de seguretat del producte:

• Es revisen els requisits, les funcions, les històries dels usuaris i els seus documents de disseny, basant-se en els detalls, els artefactes compartits per l'equip del projecte, Per exemple. Documents de disseny (HLDD i LLDD). Les avaluacions també impliquen discussions amb els membres de l’equip del projecte pertinents en cas d’absència de documents o per aclarir si hi ha dubtes.
• S’identifiquen els buits mentre s’assignen els requisits de seguretat del programa amb els estàndards establerts i altres pràctiques recomanades. De vegades, també es desenvolupen models d’amenaça basats en els buits identificats.
• Aquests buits s’identifiquen com a possibles riscos de seguretat que també inclouen suggerir possibles mitigacions per a la implementació, es plantegen i es gestionen.
• Una vegada que l’equip del projecte ha implementat aquestes mitigacions, es verifica el tancament mitjançant casos de prova adequats dissenyats per l’equip de proves del sistema.
• La matriu de gestió de riscos, que proporciona la traçabilitat, està preparada per fer un seguiment d’aquests riscos. L'arquitecte de seguretat i PSO prendran l'aprovació i la signatura del risc residual.

Els patrons d’amenaça típics que s’identifiquen a la fase de disseny estan relacionats amb la validació d’entrada, la gestió d’auditories / registres, les configuracions i els xifrats. La identificació de riscos inclou atacar vulnerabilitats com ara contrasenyes febles, atacs senzills de força bruta, etc.,

Entre les ressenyes típiques s’inclouen els riscos relacionats amb l’accés a dades personals, l’accés a les pistes d’auditoria, les entitats de la llista negra, la neteja de dades i l’activitat de supressió.

Els exemples d’escenaris de prova inclouen:

• Vulnerabilitat de desbordament de memòria intermèdia: Per assegurar-vos que, ajustant manualment els paràmetres, no hauria de ser possible frenar el servidor i obligar-lo a no respondre (denegació de servei).
• Sanejament de dades: Per garantir que es faci un sanejament adequat de les dades per a cada entrada i sortida, de manera que l'atacant no pugui injectar i emmagatzemar contingut maliciós al sistema.

# 4) Fase de desenvolupament

Anàlisi de codi segur és un Avaluació del codi estàtic mètode que s'utilitza per avaluar el Codi segur de les diverses funcions del programari mitjançant una eina d’escaneig automatitzada. Exemple: Enfortir.

Aquesta anàlisi es realitza a cada registre d’entrada / construcció de codi per escanejar el codi generat per detectar les amenaces de seguretat. Aquesta avaluació es fa generalment a nivell d’usuari.

• Cal escanejar Fortify mitjançant connectors a les màquines del desenvolupador.
• Cal integrar Fortify amb la plantilla de compilació.
• L’escaneig automàtic es realitzarà diàriament en totes les versions.
• L’equip de seguretat analitzarà el resultat de l’exploració per detectar falsos positius.
• Els defectes identificats per aquesta avaluació s’eleven i es gestionen fins al tancament, de manera que les filtracions es minimitzen / es redueixen al nivell següent.

Els exemples d’escenaris de prova inclouen:

• Per garantir que les dades sensibles no s’envien en text pla durant la transmissió de dades.
• Per garantir una transmissió de dades segura, els API orientats cap a l'exterior s'han de desplegar en un canal HTTPS.

# 5) Fase d'implementació

Anàlisi de codi dinàmic no és altra cosa que proves de seguretat d'aplicacions, que també s'anomena proves OWASP (Open Web Application Security Project). Cal fer anàlisis de vulnerabilitat i proves de penetració (VAPT) a la fase d’implementació / prova.

Aquesta anàlisi avalua els fitxers binaris i algunes configuracions d'entorn i reforça encara més el codi per als requisits de seguretat.

Com a part d 'aquesta anàlisi, el Comportament dinàmic o la funcionalitat de diverses funcions dels programes s’analitza per detectar vulnerabilitats relacionades amb la seguretat. També s’utilitzen casos d’ús i escenaris empresarials estipulats per dur a terme anàlisis de codi dinàmic.

Aquesta activitat es realitza a Prova de compilacions utilitzant diverses eines de seguretat amb un enfocament automatitzat i manual.

• Les eines d’interfície d’usuari HP WebInspect, Burp Suite, ZAP i SOAP s’utilitzen generalment per comprovar les vulnerabilitats contra les bases de dades estàndard de vulnerabilitats ( Exemple: Top 10 d’OWASP )
• Tot i que aquesta activitat està principalment automatitzada, a causa de certes restriccions d’eines, és possible que calgui treballar manualment per triar els falsos positius.
• Això es fa idealment en un entorn independent (entorn de proves de sistema), on es desplega el programari preparat per a la prova.
• Cal augmentar les vulnerabilitats i tancar-les amb les mitigacions suggerides.

Els patrons d’amenaça típics identificats durant aquesta anàlisi estan relacionats amb la validació d’entrada, l’autenticació trencada i la gestió de sessions, l’exposició de dades sensibles, l’XSS i la gestió de contrasenyes.

Els exemples d’escenaris de proves inclouen:

format de casos de prova en proves de programari

• Gestió de contrasenyes: Per assegurar-vos que les contrasenyes no s’emmagatzemen en text pla als fitxers de configuració ni en cap lloc del sistema.
• Fuga d'informació del sistema: Per garantir que la informació del sistema no es filtri en cap moment, la informació revelada per printStackTrace podria ajudar l'adversari a partir d'un pla d'atac.

# 6) Prova: fase prèvia al desplegament

Proves de penetració , Pen Test en resum i Infra VAPT (anàlisi de vulnerabilitats i proves de penetració) , és la prova holística completa amb solució completa i configuracions (inclosa la xarxa) que es fa idealment en un entorn de preproducció o de producció.

Es duu a terme principalment per identificar les vulnerabilitats de la base de dades i les vulnerabilitats del servidor junt amb qualsevol altra vulnerabilitat. Aquesta és l'última etapa de les proves de seguretat que es durien a terme. Per tant, això també inclou la verificació de defectes i riscos notificats anteriorment.

• Eines com Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP disponibles al mercat s’utilitzen per realitzar proves de ploma.
• Durant aquesta prova es realitza l’escaneig d’aplicacions web mitjançant eines automatitzades i l’explotació per a una posterior verificació. Les proves es fan per simular el comportament de l'atacant real i, per tant, també poden incloure algunes proves negatives.
• Vulnerabilitat a la infraestructura l’avaluació inclou l’escaneig, l’anàlisi i la revisió de la configuració de seguretat de la infraestructura (xarxes, sistemes i servidors) per identificar les vulnerabilitats i comprovar la resistència davant els atacs objectius.
• Això es duu a terme en un entorn de preproducció o de producció, on es prova el programari que ja es pot implementar i, per tant, simula l'entorn en temps real.
• Les vulnerabilitats s’identifiquen mitjançant escàners i tècniques manuals per eliminar els falsos positius. A més, es duran a terme escenaris comercials en temps real durant les proves manuals.
• Es produirà un informe final sobre tota l’anàlisi de seguretat que es realitzarà per a tot el programa on es ressalti l’estat dels elements d’alt risc si n’hi ha.

Els exemples d’escenaris de proves inclouen:

• Per garantir que els mètodes HTTP vulnerables no estiguin habilitats.
• Per garantir que la informació sensible dels altres usuaris no sigui visible en text clar a la xarxa.
• Per garantir la validació de la càrrega de fitxers, s’implementa per evitar la càrrega d’un fitxer maliciós.

Resum tabular per a SSDLC

La taula següent resumeix els diferents aspectes de l’anàlisi de seguretat que s’expliquen anteriorment.

Conclusió

Així, amb la implementació de tots aquests aspectes relacionats amb la seguretat integrats en les diverses fases de SDLC, l’organització ajuda a identificar els defectes de seguretat al començament del cicle i permet a l’organització implementar les mitigacions adequades, evitant així la Defectes de seguretat d’alt risc al sistema Live.

L'estudi també mostra que la majoria dels defectes de seguretat s'indueixen al programari durant l'etapa de desenvolupament, és a dir, durant el Fase de codificació , en què la codificació no ha tingut prou cura de tots els aspectes de seguretat, per qualsevol motiu.

Idealment, cap desenvolupador no voldria escriure un codi incorrecte que comprometi la seguretat. Per tant, per tal d’orientar els desenvolupadors sobre com escriure un programari segur, es tracta del proper tutorial Bones pràctiques i directrius de codificació per als desenvolupadors, per garantir una millor seguretat del programari.

Esperem que aquest tutorial sobre Secure SDLC o SSDLC sigui útil !!

Lectura recomanada

• Fases, metodologies, processos i models de SDLC (cicle de vida de desenvolupament de programari)
• 10 millors eines de proves de seguretat de les aplicacions mòbils el 2021
• 19 potents eines de prova de penetració utilitzades pels professionals el 2021
• Directrius de proves de seguretat de les aplicacions mòbils
• Proves de seguretat de xarxa i millors eines de seguretat de xarxa
• Proves de seguretat (una guia completa)
• Top 4 eines de proves de seguretat de codi obert per provar aplicacions web
• Guia de proves de seguretat d'aplicacions web