Teníem 2 analitzadors de codi, 4 eines de prova dinàmica, les nostres pròpies manualitats i 250 scripts. No és que tot això fos necessari en el procés actual, però un cop comenceu a implementar DevSecOps, heu d'anar fins al final.
. Personatges creats per Justin Roiland i Dan Harmon.
Què és SecDevOps? Què passa amb DevSecOps? Quines són les diferències? Seguretat d'aplicacions: de què es tracta? Per què ja no funciona l'enfocament clàssic? Totes aquestes preguntes saben la resposta Yuri Shabalin d' Seguretat del peix espasa. Yuriy respondrà tot detalladament i analitzarà els problemes de transició del model clàssic de seguretat d'aplicacions al procés DevSecOps: com abordar correctament la integració del procés de desenvolupament segur en el procés DevOps i no trencar res, com passar per les etapes principals. de proves de seguretat, quines eines es poden utilitzar, com es diferencien i com configurar-les correctament per evitar inconvenients.
Sobre l'altaveu: Yuri Shabalin - Arquitecte en cap de seguretat de l'empresa Seguretat del peix espasa. Responsable de la implementació de SSDL, per a la integració global d'eines d'anàlisi d'aplicacions en un únic ecosistema de desenvolupament i proves. 7 anys d'experiència en seguretat de la informació. Va treballar a Alfa-Bank, Sberbank i Positive Technologies, que desenvolupa programari i ofereix serveis. Ponent de conferències internacionals ZerONights, PHDays, RISSPA, OWASP.
Seguretat d'aplicacions: de què es tracta?
Seguretat d'aplicacions és la secció de seguretat que s'encarrega de la seguretat de l'aplicació. No es tracta d'infraestructura o seguretat de xarxa, sinó del que escrivim i en què treballen els desenvolupadors: aquests són els defectes i les vulnerabilitats de l'aplicació en si.
Destí - Cicle de vida del desenvolupament de la seguretat - Desenvolupat per Microsoft. El diagrama mostra el model canònic SDLC, la tasca principal del qual és la participació de la seguretat en totes les etapes del desenvolupament, des dels requisits fins al llançament i el llançament fins a la producció. Microsoft es va adonar que hi ha massa errors a la festa de graduació, n'hi ha més i cal fer-hi alguna cosa, i van proposar aquest enfocament, que es va convertir en canònic.
Application Security i SSDL no estan orientats a detectar vulnerabilitats, com es creu habitualment, sinó a prevenir-ne l'ocurrència. Amb el temps, l'enfocament canònic de Microsoft s'ha millorat, desenvolupat, té una immersió detallada més profunda.
El SDLC canònic està molt detallat en diverses metodologies: OpenSAMM, BSIMM, OWASP. Les metodologies són diferents, però generalment són similars.
Seguretat de l'edifici en el model de maduresa
M'agrada més BSIMM - . La base de la metodologia és la divisió del procés de seguretat d'aplicacions en 4 dominis: governança, intel·ligència, punts de contacte SSDL i desplegament. Cada domini té 12 pràctiques, que es representen com 112 activitats.
Cadascuna de les 112 activitats té 3 nivells de maduresa: principiant, mitjà i avançat. Podeu estudiar les 12 pràctiques en seccions, seleccionar coses que us són importants, descobrir com implementar-les i afegir elements gradualment, per exemple, anàlisi de codi estàtica i dinàmica o revisió de codi. Elabores un pla i treballes segons ell amb calma com a part de la realització de les activitats seleccionades.
Per què DevSecOps
DevOps és un procés global important en el qual s'ha de tenir cura de la seguretat.
Inicialment comprovacions de seguretat implicades. A la pràctica, el nombre d'equips de seguretat era molt més reduït que ara, i no actuaven com a participants en el procés, sinó com a òrgan de control i supervisió que l'exigeix i verifica la qualitat del producte al final del llançament. Aquest és un enfocament clàssic en què els equips de seguretat estaven darrere d'un mur des del desenvolupament i no van participar en el procés.
El principal problema és que la seguretat de la informació està separada del desenvolupament. En general, es tracta d'una mena de circuit IB i conté 2-3 eines grans i cares. Un cop cada sis mesos, arriba el codi font o l'aplicació per ser provat, i un cop l'any . Tot això fa que les dates de llançament de la indústria es posposen i que un gran nombre de vulnerabilitats de les eines automatitzades cauen al desenvolupador. És impossible desmuntar i reparar tot això, perquè fins i tot en els sis mesos anteriors els resultats no es van desmuntar, i aquí teniu un nou lot.
En el transcurs del treball de la nostra empresa, veiem que la seguretat en tots els àmbits i indústries entén que és hora de posar-se al dia i girar amb el desenvolupament en una sola roda, en . El paradigma DevSecOps s'adapta perfectament a la metodologia de desenvolupament àgil, la implementació, el suport i la participació en cada llançament i iteració.
Transició a DevSecOps
La paraula més important en el cicle de vida del desenvolupament de seguretat és "procés". Cal entendre això abans de pensar en comprar eines.
No n'hi ha prou amb incloure eines al procés DevOps: és important la comunicació i la comprensió entre els participants del procés.
Les persones són més importants que les eines
Sovint, la planificació d'un procés de desenvolupament segur comença amb l'elecció i la compra d'una eina, i acaba amb els intents d'integrar l'eina en el procés actual, que segueixen sent intents. Això porta a conseqüències tristos, perquè totes les eines tenen les seves pròpies característiques i limitacions.
Un cas comú és quan el departament de seguretat va triar una eina bona i cara amb una àmplia gamma de funcions i va acudir als desenvolupadors per incorporar-la al procés. Però no funciona: el procés està dissenyat de manera que les limitacions d'un instrument ja comprat no s'ajusten al paradigma actual.
Primer, descriu quin resultat voleu i com serà el procés. Això ajudarà a entendre les funcions de l'eina i la seguretat en el procés.
Comenceu amb el que ja està en ús
Abans de comprar eines cares, mireu el que ja teniu. Cada empresa té requisits de seguretat que s'apliquen al desenvolupament, hi ha controls, proves de penetració, per què no transformar tot això en una forma entenedora i còmoda per a tothom?
Normalment els requisits són un Talmud de paper que es troba en un prestatge. Hi va haver un cas quan venim a l'empresa per mirar els processos i demanar-los que mostressin els requisits de seguretat del programari. L'especialista que va fer això va estar buscant durant molt de temps:
- Ara, en algun lloc de les notes hi havia un camí on es troba aquest document.
Com a resultat, vam rebre el document una setmana més tard.
Per a requisits, comprovacions i més, creeu una pàgina, per exemple a Confluència - És convenient per a tothom.
És més fàcil reformatar el que ja hi ha i utilitzar-lo per començar.
Utilitza Security Champions
Normalment, en una empresa mitjana per a 100-200 desenvolupadors, hi ha un oficial de seguretat que realitza diverses funcions i no té temps físicament per comprovar-ho tot. Fins i tot si fa tot el possible, ell sol no comprovarà tot el codi que genera el desenvolupament. Per a aquests casos, s'ha desenvolupat un concepte: .
Security Champions és una persona de l'equip de desenvolupament que està interessada en la seguretat del vostre producte.
Security Champion és un punt d'entrada per a l'equip de desenvolupament i un evangelista de seguretat, tot plegat.
Normalment, quan un oficial de seguretat ve a l'equip de desenvolupament i assenyala un error al codi, rep una resposta sorpresa:
- I qui ets tu? Et veig per primera vegada. Tot em va bé: el meu amic sènior va posar "aplica" a la revisió del codi, seguim endavant!
Aquesta és una situació típica, perquè hi ha molta més confiança en la gent gran o només en els companys d'equip amb qui el desenvolupador interactua constantment a la feina i en la revisió del codi. Si, en comptes d'un vigilant de seguretat, el Campió de Seguretat assenyala l'error i les conseqüències, llavors la seva paraula tindrà més pes.
A més, els desenvolupadors coneixen el seu codi millor que qualsevol persona de seguretat. Per a una persona que té almenys 5 projectes en una eina d'anàlisi estàtica, sol ser difícil recordar tots els matisos. Els campions de seguretat coneixen el seu producte: què interactua amb què i què han de mirar en primer lloc: són més eficients.
Així que considereu implementar Security Champions i ampliar la influència de l'equip de seguretat. Per al propi campió, això també és útil: desenvolupament professional en un nou camp, ampliació dels horitzons tècnics, augmentar les habilitats tècniques, de gestió i de lideratge, augmentar el valor de mercat. Aquest és un element de l'enginyeria social, els vostres "ulls" a l'equip de desenvolupament.
Etapes de prova
diu que el 20% dels esforços donen el 80% dels resultats. Aquest 20% són pràctiques d'anàlisi d'aplicacions que es poden i s'han d'automatitzar. Exemples d'aquestes activitats són l'anàlisi estàtica − SAST, anàlisi dinàmica - DAST и control de codi obert. Us explicaré més coses sobre les activitats, així com sobre les eines, quines característiques ens trobem habitualment quan s'introdueixen en el procés i com fer-ho correctament.
Principals problemes de l'eina
Destacaré els problemes que són rellevants per a tots els instruments que requereixen atenció. Les analitzaré amb més detall per no repetir més.
Llarg temps d'anàlisi. Si totes les proves i el muntatge triguen 30 minuts des de la confirmació fins al llançament per a la producció, les comprovacions de seguretat de la informació trigaran un dia. Així que ningú alentirà el procés. Considereu aquesta característica i treu conclusions.
Alt fals negatiu o fals positiu. Tots els productes són diferents, tots utilitzen marcs diferents i el seu propi estil de codificació. En diferents bases de codi i tecnologies, les eines poden mostrar diferents nivells de fals negatiu i fals positiu. Així que mira què hi ha de la vostra empreses i per seva les aplicacions mostraran un resultat bo i fiable.
No hi ha integracions amb les eines existents. Mireu les eines en termes d'integracions amb el que ja feu servir. Per exemple, si teniu Jenkins o TeamCity, comproveu la integració d'eines amb aquest programari, i no amb GitLab CI, que no feu servir.
Manca o complexitat excessiva de personalització. Si l'eina no té una API, per què és necessària? Tot el que es pot fer a la interfície hauria d'estar disponible a través de l'API. Idealment, l'eina hauria de tenir la capacitat de personalitzar les comprovacions.
No hi ha cap full de ruta de desenvolupament de producte. El desenvolupament no s'atura, sempre fem servir nous marcs i funcions, reescriu el codi antic en nous llenguatges. Volem assegurar-nos que l'eina que comprem admetrà nous marcs i tecnologies. Per tant, és important saber que el producte té un efecte real i correcte desenvolupament.
Funcions del procés
A més de les característiques de les eines, tingueu en compte les característiques del procés de desenvolupament. Per exemple, interferir amb el desenvolupament és un error típic. Vegem quines altres funcions s'han de tenir en compte i a què ha de prestar atenció l'equip de seguretat.
Per no interrompre el desenvolupament i els terminis de llançament, creeu regles diferents i diferents mostrar els taps - criteris per aturar el procés de construcció en presència de vulnerabilitats - per a diferents entorns. Per exemple, entenem que la branca actual va a un estand de desenvolupament o UAT, així que no ens aturem a dir:
- Aquí tens vulnerabilitats, no aniràs més lluny!
En aquest punt, és important dir als desenvolupadors que hi ha problemes de seguretat que cal tenir en compte.
La presència de vulnerabilitats no és una barrera per a més proves: manual, integració o manual. D'altra banda, hem de millorar d'alguna manera la seguretat del producte, i perquè els desenvolupadors no puntuin el que troba la seguretat. Per tant, de vegades fem això: a l'estand, quan es desplega a l'entorn de desenvolupament, simplement avisem el desenvolupament:
- Nois, teniu problemes, feu-hi cas, si us plau.
A l'etapa d'UAT, tornem a mostrar advertències sobre vulnerabilitats, i a l'etapa de sortida del bal diem:
"Nois, us vam avisar diverses vegades, no heu fet res; no us deixarem sortir amb això.
Si parlem de codi i dinàmica, llavors cal mostrar i advertir sobre les vulnerabilitats només d'aquelles característiques i codi que s'acaba d'escriure en aquesta característica. Si el desenvolupador ha mogut el botó 3 píxels i li diem que hi té una injecció SQL i, per tant, s'ha de solucionar amb urgència, això està malament. Mireu només el que està escrit ara i el canvi que comporta l'aplicació.
Suposem que tenim algun defecte funcional: com no hauria de funcionar l'aplicació: no es transfereixen diners, quan feu clic al botó, no hi ha cap transició a la pàgina següent o el producte no es carrega. Defectes de seguretat - aquests són els mateixos defectes, però no en el context de l'aplicació, sinó de seguretat.
No tots els problemes de qualitat del programari són problemes de seguretat. Però tots els problemes de seguretat estan relacionats amb la qualitat del programari. Sherif Mansour, Expedia.
Com que totes les vulnerabilitats són els mateixos defectes, haurien d'estar ubicades al mateix lloc que tots els defectes de desenvolupament. Així que oblideu-vos dels informes i dels PDF aterridors que ningú llegeix.
Quan treballava per a una empresa de desenvolupament, vaig rebre un informe d'eines d'anàlisi estàtica. El vaig obrir, em vaig horroritzar, vaig fer cafè, vaig fullejar 350 pàgines, el vaig tancar i vaig començar a treballar. Els grans informes són informes morts. Normalment no van enlloc, els correus electrònics s'esborren, s'obliden, es perden o l'empresa diu que està assumint riscos.
Què fer? Simplement convertim els defectes confirmats que hem trobat en un formulari convenient per al desenvolupament, per exemple, l'afegim al backlog de Jira. Els defectes es prioritzen i s'eliminen per ordre de prioritat juntament amb els defectes funcionals i els defectes de prova.
Anàlisi estàtica - SAST
Aquesta és l'anàlisi de codi per a vulnerabilitats., però no és el mateix que SonarQube. Comprovem no només els patrons o l'estil. L'anàlisi utilitza una sèrie d'enfocaments: per arbre de vulnerabilitat, per , mitjançant l'anàlisi dels fitxers de configuració. Això és tot pel codi en si.
Pros de l'enfocament: identificar vulnerabilitats en el codi en una fase inicial de desenvolupamentquan no hi ha estands i eines ja fetes, i capacitat d'escaneig incremental: escaneja una secció de codi que ha canviat, i només la funció que estem fent actualment, la qual cosa redueix el temps d'escaneig.
Contres és la manca de suport per als idiomes requerits.
Integracions necessàries, que hauria d'estar a les eines, segons la meva opinió subjectiva:
- Eina d'integració: Jenkins, TeamCity i Gitlab CI.
- Entorn de desenvolupament: Intellij IDEA, Visual Studio. És més convenient per a un desenvolupador no pujar a una interfície incomprensible que encara cal recordar, sinó veure totes les integracions i vulnerabilitats necessàries que ha trobat al lloc de treball en el seu propi entorn de desenvolupament.
- Revisió de codi: SonarQube i revisió manual.
- Seguidors de defectes: Jira i Bugzilla.
La imatge mostra alguns dels millors representants de l'anàlisi estàtica.
No són les eines les que importen, sinó el procés, de manera que hi ha solucions de codi obert que també són bones per executar el procés.
SAST Open Source no trobarà un gran nombre de vulnerabilitats o DataFlow complex, però es poden i s'han d'utilitzar quan es construeix un procés. Ajuden a entendre com es construirà el procés, qui respondrà als errors, qui informarà, qui informarà. Si voleu dur a terme l'etapa inicial de construcció de la seguretat del vostre codi, utilitzeu solucions de codi obert.
Com es pot integrar això si estàs al començament del viatge, no tens res: ni CI, ni Jenkins, ni TeamCity? Considereu la integració de processos.
Integració a nivell CVS
Si teniu Bitbucket o GitLab, podeu fer la integració al nivell .
Per esdeveniment sol·licitud d'extracció, confirmació. Escanegeu el codi i mostreu a l'estat de construcció que la comprovació de seguretat ha passat o ha fallat.
Comentaris. Per descomptat, sempre cal la retroalimentació. Si ho vau fer pel costat de la seguretat, ho vau posar en una caixa i no li vau dir res a ningú, i després vau llençar un munt d'errors a finals de mes, això no és correcte i no és bo.
Integració amb el sistema de revisió de codi
Un cop, establim l'usuari tècnic d'AppSec com a revisor predeterminat en una sèrie de projectes importants. Depenent de si s'han trobat errors al codi nou o si no hi ha errors, el revisor posa l'estat a la sol·licitud d'extracció per "acceptar" o "necessitar feina"; o bé, tot està bé o bé cal que finalitzeu i enllaça amb què exactament. per finalitzar. Per a la integració amb la versió que s'està llançant, hem desactivat la fusió si no s'aprova la prova d'IS. Ho vam incloure a la revisió manual del codi i la resta de participants del procés van veure els estats de seguretat d'aquest procés en concret.
Integració amb SonarQube
Molts ho han fet pel que fa a la qualitat del codi. Aquí és el mateix: només podeu fer les mateixes portes per als instruments SAST. Hi haurà la mateixa interfície, la mateixa porta de qualitat, només s'anomenarà porta de seguretat. A més, si teniu un procés configurat amb SonarQube, podeu integrar-ho fàcilment tot.
Integració a nivell CI
Aquí també tot és ben senzill:
- A l'igual dels autotests, proves unitàries.
- Divisió per etapes de desenvolupament: dev, prova, prod. Es poden incloure diferents conjunts de regles, o diferents condicions de fallada: parem el muntatge, no parem el muntatge.
- Execució síncrona/asíncrona. Estem esperant que finalitzin les proves de seguretat o no estem esperant. És a dir, els acabem de llançar i seguim endavant, i després obtenim un estat que tot és bo o dolent.
Tot està en un món rosa perfecte. A la vida real, aquest no és el cas, però ens esforcem. El resultat de la realització de controls de seguretat ha de ser similar als resultats de les proves unitàries.
Per exemple, vam agafar un projecte gran i vam decidir que ara l'escanegem amb SAST - D'acord. Vam introduir aquest projecte a SAST, ens va donar 20 vulnerabilitats i vam prendre la decisió ferma que tot està bé. 000 vulnerabilitats és el nostre deute tècnic. Posarem el deute en una caixa, l'anirem remuntant lentament i començarem errors en els rastrejadors de defectes. Contracteu una empresa, fem-ho tot nosaltres mateixos o feu que ens ajudin els campions de seguretat, i el deute tècnic disminuirà.
I totes les vulnerabilitats que apareixen recentment al codi nou s'han d'eliminar de la mateixa manera que els errors en una unitat o en les proves automàtiques. Relativament parlant, el muntatge va començar, va marxar, van caure dues proves i dues proves de seguretat. D'acord: vam anar, vam mirar què va passar, n'hem corregit un, n'hem corregit el segon, hem conduït la propera vegada: tot està bé, no han aparegut noves vulnerabilitats, les proves no han fallat. Si aquesta tasca és més profunda i cal entendre-la bé, o corregir vulnerabilitats afecta grans capes del que hi ha sota el capó: s'introdueix un error al rastrejador de defectes, es prioritza i es corregeix. Malauradament, el món no és perfecte i les proves de vegades fracassen.
Un exemple de porta de seguretat és un anàleg d'una porta de qualitat, pel que fa a la presència i el nombre de vulnerabilitats al codi.
Ens integrem amb SonarQube: el connector està instal·lat, tot és molt còmode i genial.
Integració de l'entorn de desenvolupament
Opcions d'integració:
- Iniciant una exploració des de l'entorn de desenvolupament fins i tot abans de la confirmació.
- Veure resultats.
- Anàlisi dels resultats.
- Sincronització amb el servidor.
Així és com es veu obtenir resultats del servidor.
En el nostre entorn de desenvolupament només apareix un element addicional que diu que aquestes vulnerabilitats es van trobar durant l'exploració. Podeu editar el codi immediatament, veure recomanacions i . Tot això es troba al lloc de treball del desenvolupador, cosa que és molt convenient: no cal que seguiu la resta d'enllaços i mireu alguna cosa addicional.
Open Source
Aquest és el meu tema preferit. Tothom fa servir biblioteques de codi obert: per què escriure un munt de crosses i bicicletes quan pots agafar una biblioteca ja feta en la qual ja està tot implementat?
Per descomptat, això és cert, però les biblioteques també són escrites per persones, també inclouen certs riscos, i també hi ha vulnerabilitats que s'informa periòdicament, o constantment. Per tant, hi ha un pas següent en la seguretat de les aplicacions: aquesta és l'anàlisi dels components de codi obert.
Anàlisi de codi obert - OSA
L'eina inclou tres passos principals.
Trobar vulnerabilitats a les biblioteques. Per exemple, l'eina sap que estem utilitzant algun tipus de biblioteca, i que en o en els rastrejadors d'errors hi ha algunes vulnerabilitats relacionades amb aquesta versió de la biblioteca. Si proveu d'utilitzar-lo, l'eina us avisarà que la biblioteca és vulnerable i us aconsellarà que utilitzeu una altra versió on no hi hagi vulnerabilitats.
Anàlisi de la puresa de la llicència. Això encara no és molt popular entre nosaltres, però si treballeu a l'estranger, de tant en tant podeu rebre un atac per utilitzar un component de codi obert que no es pot utilitzar ni modificar. D'acord amb la política de la biblioteca amb llicència, no podem fer-ho. O, si l'hem modificat i l'utilitzem, hem de publicar el nostre codi. Per descomptat, ningú vol publicar el codi dels seus productes, però també podeu protegir-vos d'això.
Anàlisi de components que s'utilitzen en un entorn industrial. Imagineu una situació hipotètica en què finalment hem completat el desenvolupament i hem llançat la darrera versió del nostre microservei al sector. Hi viu meravellosament: una setmana, un mes, un any. No el recollim, no fem controls de seguretat, sembla que tot va bé. Però de sobte, dues setmanes després del llançament, surt una vulnerabilitat crítica en el component de codi obert, que fem servir en aquest conjunt en concret, en l'entorn industrial. Si no registrem què i on fem servir, aquesta vulnerabilitat simplement no es veurà. Algunes eines tenen la capacitat de supervisar les vulnerabilitats de les biblioteques que s'utilitzen actualment al bal. És molt útil.
Característiques:
- Diferents polítiques per a diferents etapes de desenvolupament.
- Monitoritzar components en un entorn industrial.
- Control de biblioteques en el contorn de l'organització.
- Suport per a diversos sistemes de construcció i llenguatges.
- Anàlisi d'imatges de Docker.
Alguns exemples de líders en el camp que es dediquen a l'anàlisi del codi obert.
L'únic gratuït és de l'OWASP. Podeu activar-lo en les primeres etapes, veure com funciona i què admet. Bàsicament, tots són productes al núvol, o locals, però darrere de la seva base encara van a Internet. No envien les teves biblioteques, sinó hash o els seus valors que calculen, i empremtes dactilars al seu servidor per tal de rebre notícies de la presència de vulnerabilitats.
Integració de processos
Control de biblioteca perimetralque es descarreguen de fonts externes. Disposem de repositoris externs i interns. Per exemple, tenim Nexus a Event Central i volem assegurar-nos que no hi hagi vulnerabilitats amb un estat "crític" o "alt" dins del nostre dipòsit. Podeu configurar el proxy mitjançant l'eina Nexus Firewall Lifecycle per tal que aquestes vulnerabilitats s'eliminin i no s'incloguin al repositori intern.
Integració de CI. Al mateix nivell amb autotests, tests unitaris i divisió en etapes de desenvolupament: dev, test, prod. En cada etapa, podeu descarregar qualsevol biblioteca, fer servir qualsevol cosa, però si hi ha alguna cosa difícil amb l'estat "crític", probablement hauríeu de cridar l'atenció dels desenvolupadors sobre això en l'etapa d'entrar al baile de graduació.
Integració d'artefactes: Nexus i JFrog.
Integració en l'entorn de desenvolupament. Les eines que trieu haurien de tenir integració amb entorns de desenvolupament. El desenvolupador ha de tenir accés als resultats de l'anàlisi des del seu lloc de treball, o la capacitat d'escanejar i comprovar el codi per detectar vulnerabilitats abans de cometre-ho a CVS.
Integració de CD. Aquesta és una característica interessant que m'agrada molt i de la qual ja he parlat: el seguiment de l'aparició de noves vulnerabilitats en un entorn industrial. Funciona així.
Tenim Repositoris públics de components - algunes eines a l'exterior i el nostre repositori intern. Volem que només hi hagi components de confiança. Quan enviem una sol·licitud de proxy, comprovem que la biblioteca baixada no tingui vulnerabilitats. Si s'inclou en determinades polítiques que establim i necessàriament coordinem amb el desenvolupament, aleshores no el pengem i rebem un rebuig per utilitzar una altra versió. En conseqüència, si hi ha alguna cosa realment crítica i dolenta a la biblioteca, el desenvolupador no rebrà la biblioteca ni tan sols en l'etapa d'instal·lació; deixeu-lo utilitzar una versió superior o inferior.
- A l'hora de construir, comprovem que ningú no hagi relliscat res dolent, que tots els components estiguin segurs i que ningú no hagi portat res perillós a la unitat flaix.
- Només tenim components de confiança al repositori.
- En el desplegament, tornem a comprovar el propi paquet: imatge war, jar, DL o Docker que compleixi amb la política.
- En entrar a l'entorn industrial, fem un seguiment del que passa a l'entorn industrial: apareixen o no apareixen vulnerabilitats crítiques.
Anàlisi Dinàmica - DAST
Les eines d'anàlisi dinàmica són fonamentalment diferents de tot el que s'ha dit abans. Es tracta d'una mena d'imitació del treball de l'usuari amb l'aplicació. Si es tracta d'una aplicació web, enviem peticions imitant el treball del client, clica sobre els botons de la part davantera, enviem dades artificials des del formulari: cometes, claudàtors, caràcters en diferents codificacions per veure com funciona l'aplicació i els processos externs. dades.
El mateix sistema us permet comprovar si hi ha vulnerabilitats de plantilles al codi obert. Com que DAST no sap quin codi obert estem utilitzant, simplement llança patrons "maliciosos" i analitza les respostes del servidor:
- Sí, aquí hi ha un problema de deserialització, però aquí no.
Hi ha grans riscos en això, perquè si feu aquesta prova de seguretat al mateix estand amb què treballen els provadors, poden passar coses desagradables.
- Alta càrrega a la xarxa del servidor d'aplicacions.
- Sense integracions.
- La possibilitat de canviar la configuració de l'aplicació analitzada.
- No hi ha suport per a les tecnologies necessàries.
- Dificultat de fixació.
Vam tenir una situació quan finalment vam llançar AppScan: vam deixar sense accés l'aplicació durant molt de temps, vam rebre 3 comptes i vam estar encantats; finalment, ho comprovarem tot! Vam llançar una exploració i el primer que va fer AppScan va ser entrar al tauler d'administració, perforar tots els botons, canviar la meitat de les dades i després matar el servidor per complet amb el seu propi -sol·licituds. Desenvolupament amb proves va dir:
"Nois, esteu fent broma?! Et vam donar comptes, i tu vas posar l'estand!
Considereu els possibles riscos. L'ideal és preparar un estand separat per provar la seguretat de la informació, que s'aïllarà de la resta de l'entorn, almenys d'alguna manera, i comprovar condicionalment el tauler d'administració, preferiblement en mode manual. Aquest és un pentest: aquells percentatges restants d'esforços que no estem considerant ara.
Val la pena tenir en compte que podeu utilitzar-ho com a anàleg de les proves de càrrega. A la primera etapa, podeu activar l'escàner dinàmic en 10-15 fils i veure què passa, però normalment, com mostra la pràctica, no hi ha res de bo.
Uns quants recursos que fem servir habitualment.
Val la pena destacar és el "ganivet suís" per a qualsevol professional de la seguretat. Tothom l'utilitza i és molt convenient. Ara s'ha llançat una nova versió de demostració de l'edició empresarial. Si abans només era una utilitat autònoma amb complements, ara els desenvolupadors finalment fan un gran servidor des del qual es podran gestionar diversos agents. Està genial, us recomano que ho proveu.
Integració de processos
La integració és bastant bona i senzilla: iniciar l'exploració després d'una instal·lació correcta aplicacions a l'estand i escaneig després de proves d'integració reeixides.
Si les integracions no funcionen o hi ha talons i funcions simulades, no té sentit ni serveix; no importa el patró que enviem, el servidor encara respondrà de la mateixa manera.
- Idealment, un banc de proves independent.
- Abans de provar, anoteu la seqüència d'inici de sessió.
- La prova del sistema d'administració és només manual.
procés
Una mica generalitzat sobre el procés en general i sobre el treball de cada eina, en particular. Totes les aplicacions són diferents: una funciona millor amb anàlisi dinàmica, una altra amb anàlisi estàtica, la tercera amb anàlisi OpenSource, pentests o alguna altra cosa en general, per exemple, esdeveniments amb .
Cada procés ha de ser controlat.
Per entendre com funciona el procés i on es pot millorar, heu de recopilar mètriques de tot el que podeu tenir a les vostres mans, incloses les mètriques de producció, les mètriques d'eines i els rastrejadors de defectes.
Qualsevol informació és útil. Cal mirar en diversos apartats on s'utilitza millor aquesta o aquella eina, on el procés s'enfonsa específicament. Potser val la pena mirar el temps de resposta del desenvolupament per veure on millorar el procés en funció del temps. Com més dades, més retallades es poden construir des del nivell superior fins als detalls de cada procés.
Com que tots els analitzadors estàtics i dinàmics tenen les seves pròpies API, els seus propis mètodes de llançament, principis, alguns tenen programadors, d'altres no, estem escrivint una eina AppSec Orchestrator, que permet fer un únic punt d'entrada a tot el procés des del producte i gestionar-lo des d'un punt.
Els gestors, els desenvolupadors i els enginyers de seguretat tenen un punt d'entrada des del qual poden veure què s'està executant, configurar i executar exploracions, obtenir resultats d'anàlisi i enviar requisits. Intentem allunyar-nos dels trossos de paper, traduir-ho tot en un humà que utilitza el desenvolupament: pàgines sobre Confluence amb estat i mètriques, defectes a Jira o en diversos rastrejadors de defectes, o incrustant en un procés síncron/asíncron en CI/CD.
Sortides de claus
Les eines no importen. Penseu primer en el procés i després implementeu les eines. Les eines són bones, però cares, de manera que podeu començar amb el procés i afinar la interacció i la comprensió entre desenvolupament i seguretat. Des del punt de vista de la seguretat, no cal "aturar" tot seguit. Des del punt de vista del desenvolupament, si hi ha alguna cosa alta mega supercrítica, llavors això s'ha d'eliminar i no tancar-se al problema. .
Qualitat del producte - objectiu comú tant de seguretat com de desenvolupament. Fem una cosa, intentem que tot funcioni correctament i que no hi hagi riscos reputacionals i pèrdues financeres. És per això que impulsem l'enfocament a DevSecOps, SecDevOps per tal d'establir comunicació i millorar el producte.
Comenceu pel que ja hi ha: requisits, arquitectura, comprovacions parcials, formacions, directrius. No cal aplicar immediatament totes les pràctiques a tots els projectes - moure's iterativament. No hi ha un únic estàndard experiment i prova diferents enfocaments i solucions.
Signe igual entre els defectes IS i els defectes funcionals.
Automatitzar-ho totque es mou. Qualsevol cosa que no es mou, es mou i automatitza. Si alguna cosa es fa a mà, això no és una bona part del procés. Potser també val la pena reconsiderar-ho i automatitzar-lo.
Si la mida de l'equip de l'IB és petita - utilitzar Security Champions.
Potser el que he parlat no us convé i us sortirà alguna cosa pròpia, i això és bo. Però Trieu eines en funció dels requisits del vostre procés. No mireu què diu la comunitat que aquesta eina és dolenta i aquesta és bona. Potser serà al revés en el vostre producte.
Requisits de l'eina.
- Baix fals positiu.
- Temps d'anàlisi adequat.
- La comoditat d'ús.
- Disponibilitat d'integracions.
- Entendre el full de ruta de desenvolupament de productes.
- Capacitat de personalitzar eines.
L'informe de Yuriy va ser escollit com un dels millors a DevOpsConf 2018. Per familiaritzar-se amb idees i casos pràctics encara més interessants, vine a Skolkovo els dies 27 i 28 de maig dins . Encara millor, si estàs disposat a compartir la teva experiència, aleshores Envieu el vostre informe abans del 21 d'abril.
Font: www.habr.com