Medo e odio DevSecOps

Tiñamos 2 analizadores de código, 4 ferramentas de proba dinámica, as nosas propias manualidades e 250 scripts. Non é que todo isto fose necesario no proceso actual, pero unha vez que comezou a implementar DevSecOps, cómpre ir ata o final.

Orixe. Personaxes creados por Justin Roiland e Dan Harmon.

Que é SecDevOps? Que pasa con DevSecOps? Cales son as diferenzas? Seguridade das aplicacións: de que se trata? Por que xa non funciona o enfoque clásico? Todas estas preguntas saben a resposta Yuri Shabalin de Seguridade do peixe espada. Yuriy responderá todo en detalle e analizará os problemas de transición do modelo clásico de Seguridade de Aplicacións ao proceso DevSecOps: como abordar correctamente a integración do proceso de desenvolvemento seguro no proceso DevOps e non romper nada, como pasar polas principais etapas. de probas de seguridade, que ferramentas se poden utilizar, como se diferencian e como configuralas adecuadamente para evitar trampas.

Sobre o orador: Yuri Shabalin - Arquitecto xefe de seguridade da empresa Seguridade do peixe espada. Responsable da implementación de SSDL, para a integración global das ferramentas de análise de aplicacións nun único ecosistema de desenvolvemento e probas. 7 anos de experiencia en seguridade da información. Traballou en Alfa-Bank, Sberbank e Positive Technologies, que desenvolve software e ofrece servizos. Ponente de conferencias internacionais ZerONights, PHDays, RISSPA, OWASP.

Seguridade das aplicacións: de que se trata?

Seguridade de aplicacións é a sección de seguridade que se encarga da seguridade das aplicacións. Non se trata da infraestrutura ou da seguridade da rede, senón do que escribimos e no que traballan os desenvolvedores: estes son os fallos e vulnerabilidades da propia aplicación.

dirección SDL ou SDLC - Ciclo de vida do desenvolvemento da seguridade - Desenvolvido por Microsoft. O diagrama mostra o modelo SDLC canónico, cuxa tarefa principal é a participación da seguridade en todas as fases de desenvolvemento, desde os requisitos ata a liberación e o lanzamento ata a produción. Microsoft deuse conta de que hai demasiados erros no baile de graduación, hai máis e hai que facer algo ao respecto, e propuxeron este enfoque, que se converteu en canónico.

Application Security e SSDL non están dirixidos a detectar vulnerabilidades, como se cre habitualmente, senón a previr a súa aparición. Co paso do tempo, o enfoque canónico de Microsoft foi mellorado, desenvolvido, ten unha inmersión detallada máis profunda.

O SDLC canónico está moi detallado en varias metodoloxías: OpenSAMM, BSIMM, OWASP. As metodoloxías difiren, pero en xeral son similares.

Modelo de Seguridade do Edificio en Madurez

A min gústame máis BSIMM - Modelo de Seguridade do Edificio en Madurez. A base da metodoloxía é a división do proceso de Seguridade das Aplicacións en 4 dominios: Gobernanza, Intelixencia, Puntos de contacto SSDL e Implementación. Cada dominio ten 12 prácticas, que se representan como 112 actividades.

Cada unha das 112 actividades ten 3 niveis de madurez: principiante, intermedio e avanzado. Podes estudar as 12 prácticas en seccións, seleccionar as cousas que son importantes para ti, descubrir como implementalas e engadir gradualmente elementos, por exemplo, análise de código estático e dinámico ou revisión de código. Elaboras un plan e traballas segundo el con calma como parte da realización das actividades seleccionadas.

Por que DevSecOps

DevOps é un gran proceso xeral no que hai que coidar a seguridade.

Inicialmente DevOps comprobacións de seguridade implicadas. Na práctica, o número de equipos de seguridade era moito menor que agora, e non actuaron como participantes no proceso, senón como un órgano de control e supervisión que lle esixe e verifica a calidade do produto ao final do lanzamento. Este é un enfoque clásico no que os equipos de seguridade estaban detrás dun muro desde o desenvolvemento e non participaron no proceso.

O principal problema é que a seguridade da información está separada do desenvolvemento. Normalmente este é algún tipo de circuíto IB e contén 2-3 ferramentas grandes e caras. Unha vez cada seis meses, o código fonte ou a aplicación chega para ser probado, e unha vez ao ano Pentests. Todo isto leva ao feito de que as datas de lanzamento para a industria se aprazan e un gran número de vulnerabilidades das ferramentas automatizadas caen sobre o programador. É imposible desmontar e reparar todo isto, porque nin sequera nos seis meses anteriores non se desmontaron os resultados, e aquí hai un novo lote.

No proceso de traballo da nosa empresa, vemos que a seguridade en todas as áreas e industrias entende que é hora de poñerse ao día e darlle voltas ao desenvolvemento nunha soa roda. Áxil. O paradigma DevSecOps encaixa perfectamente na metodoloxía de desenvolvemento áxil, implementación, soporte e participación en cada versión e iteración.

Transición a DevSecOps

A palabra máis importante no ciclo de vida do desenvolvemento da seguridade é "proceso". Debes entender isto antes de pensar en mercar ferramentas.

Non basta con incluír ferramentas no proceso DevOps: é importante a comunicación e a comprensión entre os participantes do proceso.

As persoas son máis importantes que as ferramentas

Moitas veces, a planificación dun proceso de desenvolvemento seguro comeza coa elección e compra dunha ferramenta, e remata cos intentos de integrar a ferramenta no proceso actual, que seguen sendo intentos. Isto leva a tristes consecuencias, porque todas as ferramentas teñen as súas propias características e limitacións.

Un caso común é cando o departamento de seguridade escolleu unha ferramenta boa e cara cunha ampla gama de funcións e acudiu aos desenvolvedores para incorporala no proceso. Pero non funciona: o proceso está deseñado de tal xeito que as limitacións dun instrumento xa adquirido non encaixan no paradigma actual.

En primeiro lugar, describe o resultado que queres e como será o proceso. Isto axudará a comprender o papel da ferramenta e a seguridade no proceso.

Comeza co que xa está en uso

Antes de comprar ferramentas caras, mira o que xa tes. Cada empresa ten requisitos de seguridade que se aplican ao desenvolvemento, hai comprobacións, pentests; por que non transformar todo isto nunha forma comprensible e conveniente para todos?

Normalmente os requisitos son un Talmud de papel que se atopa nun estante. Houbo un caso cando chegamos á empresa para ver os procesos e pedirlles que mostrasen os requisitos de seguridade do software. O especialista que fixo isto estivo buscando durante moito tempo:

- Agora ben, nalgún lugar das notas había un camiño onde se atopa este documento.

Como resultado, recibimos o documento unha semana despois.

Para obter requisitos, verificacións e moito máis, crea unha páxina, por exemplo en Confluencia - é conveniente para todos.

É máis doado reformatear o que xa hai e usalo para comezar.

Use Security Champions

Normalmente, nunha empresa media para desenvolvedores 100-200, hai un oficial de seguridade que realiza varias funcións e non ten tempo fisicamente para comprobar todo. Aínda que faga o posible, el só non comprobará todo o código que xera o desenvolvemento. Para tales casos, desenvolveuse un concepto: Campións de seguridade.

Security Champions é unha persoa dentro do equipo de desenvolvemento que está interesada na seguridade do teu produto.

Campión de seguridade é un punto de entrada para o equipo de desenvolvemento e un evanxelista de seguridade todo nun só.

Normalmente, cando un oficial de seguridade chega ao equipo de desenvolvemento e sinala un erro no código, recibe unha resposta sorpresa:

- E ti quen es? véxote por primeira vez. Todo está ben comigo: o meu amigo maior puxo "aplicar" na revisión do código, ¡seguimos!

Esta é unha situación típica, porque hai moita máis confianza nos maiores ou só nos compañeiros de equipo cos que o desenvolvedor interactúa constantemente no traballo e na revisión do código. Se, en lugar dun garda de seguridade, o Campión de Seguridade sinala o erro e as consecuencias, entón a súa palabra terá máis peso.

Ademais, os desenvolvedores coñecen o seu código mellor que calquera tipo de seguridade. Para unha persoa que ten polo menos 5 proxectos nunha ferramenta de análise estática, adoita ser difícil recordar todos os matices. Os campións da seguridade coñecen o seu produto: o que interactúa co que e o que mirar en primeiro lugar: son máis eficientes.

Polo tanto, considere implementar Campións de seguridade e ampliar a influencia do equipo de seguridade. Para o propio campión, isto tamén é útil: o desenvolvemento profesional nun novo campo, a ampliación dos horizontes técnicos, o bombeo de habilidades técnicas, directivas e de liderado, o aumento do valor de mercado. Este é algún elemento da enxeñería social, os teus "ollos" no equipo de desenvolvemento.

Fases de proba

Paradigma 20 por 80 di que o 20% dos esforzos dan o 80% dos resultados. Este 20% son prácticas de análise de aplicacións que poden e deben automatizarse. Exemplos destas actividades son a análise estática − SAST, análise dinámica - DAST и control de código aberto. Contareivos máis cousas sobre as actividades, así como sobre as ferramentas, con que características adoitamos atopar cando se introducen no proceso e como facelo correctamente.

Principais problemas da ferramenta

Destacarei os problemas que son relevantes para todos os instrumentos que requiren atención. Analizareinos con máis detalle para non repetir máis.

Longo tempo de análise. Se todas as probas e montaxes tardan 30 minutos desde o compromiso ata o lanzamento para a produción, as comprobacións de seguridade da información levarán un día. Polo tanto, ninguén ralentizará o proceso. Considere esta característica e saque conclusións.

Falso negativo alto ou falso positivo. Todos os produtos son diferentes, todos usan marcos diferentes e o seu propio estilo de codificación. En diferentes bases de código e tecnoloxías, as ferramentas poden mostrar diferentes niveis de falso negativo e falso positivo. Así que mira o que hai do teu empresas e para o teu aplicacións mostrarán un resultado bo e fiable.

Non hai integracións coas ferramentas existentes. Mira as ferramentas en canto a integracións co que xa usas. Por exemplo, se tes Jenkins ou TeamCity, comprobe a integración das ferramentas con este software, e non con GitLab CI, que non utilizas.

Falta ou excesiva complexidade de personalización. Se a ferramenta non ten unha API, entón por que é necesaria? Todo o que se pode facer na interface debería estar dispoñible a través da API. O ideal é que a ferramenta teña a capacidade de personalizar as comprobacións.

Sen folla de ruta de desenvolvemento de produtos. O desenvolvemento non se para, sempre usamos novos marcos e funcións, reescribimos código antigo en linguaxes novas. Queremos asegurarnos de que a ferramenta que compramos admita novos marcos e tecnoloxías. Polo tanto, é importante saber que o produto ten un real e correcto Roadmap desenvolvemento.

Funcións do proceso

Ademais das características das ferramentas, considere as características do proceso de desenvolvemento. Por exemplo, interferir co desenvolvemento é un erro típico. Vexamos que outras funcións se deben considerar e a que debe prestar atención o equipo de seguridade.

Para non interromper o desenvolvemento e os prazos de publicación, crea regras diferentes e diferente mostrar tapóns - Criterios para deter o proceso de construción en presenza de vulnerabilidades. para diferentes ambientes. Por exemplo, entendemos que a sucursal actual vai a un stand de desenvolvemento ou UAT, polo que non nos paramos a dicir:

- Tes vulnerabilidades aquí, non irás máis lonxe!

Neste punto, é importante dicirlles aos desenvolvedores que hai problemas de seguridade que hai que ter en conta.

A presenza de vulnerabilidades non é unha barreira para probas posteriores: manual, integración ou manual. Por outra banda, temos que mellorar dalgún xeito a seguridade do produto, e para que os desenvolvedores non puntuen no que atopa a seguridade. Polo tanto, ás veces facemos isto: no stand, cando se lanza ao entorno de desenvolvemento, simplemente notificamos ao desenvolvemento:

- Rapaces, tes problemas, fainos caso, por favor.

Na fase de UAT, mostramos de novo avisos sobre vulnerabilidades, e na fase de saída do baile dicimos:

"Rapaces, avisámosvos varias veces, non fixestes nada, non vos deixaremos saír con isto.

Se falamos de código e dinámica, entón é necesario mostrar e advertir sobre as vulnerabilidades só daquelas características e código que se acaba de escribir nesta función. Se o programador moveu o botón 3 píxeles e dicímoslle que ten alí unha inxección SQL e que, polo tanto, hai que arranxalo con urxencia, isto está mal. Mira só o que está escrito agora e o cambio que se produce na aplicación.

Digamos que temos algún defecto funcional: o xeito no que a aplicación non debería funcionar: o diñeiro non se transfire, cando fai clic no botón, non hai transición á páxina seguinte ou o produto non se carga. Defectos de seguridade - estes son os mesmos defectos, pero non no contexto da aplicación, senón na seguridade.

Non todos os problemas de calidade do software son problemas de seguridade. Pero todos os problemas de seguridade están relacionados coa calidade do software. Sherif Mansour, Expedia.

Dado que todas as vulnerabilidades son os mesmos defectos, deberían situarse no mesmo lugar que todos os defectos de desenvolvemento. Así que esquece os informes e os PDF asustados que ninguén le.

Cando traballaba para unha empresa de desenvolvemento, recibín un informe de ferramentas de análise estática. Abrín, quedei horrorizado, fixen café, follei 350 páxinas, pecheino e púxenme a traballar. Os grandes informes son informes mortos. Normalmente non van a ningún lado, os correos electrónicos elimínanse, esquécense, pérdense ou a empresa di que está a correr riscos.

Que facer? Simplemente convertemos os defectos confirmados que atopamos nun formulario conveniente para o desenvolvemento, por exemplo, engádeo ao atraso en Jira. Os defectos son priorizados e elimínanse por orde de prioridade xunto cos defectos funcionais e os defectos de proba.

Análise estática - SAST

Esta é a análise de código para vulnerabilidades., pero non é o mesmo que SonarQube. Comprobamos non só os patróns ou o estilo. A análise utiliza unha serie de enfoques: por árbore de vulnerabilidade, por fluxo de datos, mediante a análise dos ficheiros de configuración. Iso é todo polo propio código.

Pros do enfoque: identificar vulnerabilidades no código nunha fase inicial de desenvolvementocando non hai postos e ferramentas preparadas, e capacidade de exploración incremental: escanea unha sección de código que cambiou, e só a función que estamos facendo actualmente, o que reduce o tempo de exploración.

Contra é a falta de apoio para as linguas requiridas.

Integracións necesarias, que debería estar nas ferramentas, na miña opinión subxectiva:

• Ferramenta de integración: Jenkins, TeamCity e Gitlab CI.
• Entorno de desenvolvemento: Intellij IDEA, Visual Studio. É máis conveniente para un programador non subir a unha interface incomprensible que aínda hai que lembrar, senón ver todas as integracións e vulnerabilidades necesarias que atopou no lugar de traballo no seu propio contorno de desenvolvemento.
• Revisión do código: SonarQube e revisión manual.
• Rastreadores de defectos: Jira e Bugzilla.

A imaxe mostra algúns dos mellores representantes da análise estática.

Non son as ferramentas as que importan, senón o proceso, polo que hai solucións de código aberto que tamén son boas para executar o proceso.

SAST Open Source non atopará un gran número de vulnerabilidades ou DataFlow complexo, pero poden e deben usarse ao construír un proceso. Axudan a comprender como se construirá o proceso, quen responderá aos erros, quen informará, quen informará. Se queres levar a cabo a fase inicial de construción da seguridade do teu código, utiliza solucións de código aberto.

Como se pode integrar isto se estás no inicio da viaxe, non tes nada: nin CI, nin Jenkins, nin TeamCity? Considere a integración de procesos.

Integración a nivel CVS

Se tes Bitbucket ou GitLab, podes facer a integración no nivel Sistema de versións simultáneas.

Por evento tirar solicitude, comprometer. Escaneas o código e mostras no estado de compilación que a comprobación de seguridade pasou ou fallou.

Comentarios. Por suposto, sempre é necesario o feedback. Se o fixeches polo lado da seguridade, o meteches nunha caixa e non lle contaches nada a ninguén e despois botaches unha morea de erros a finais de mes, isto non está ben e non é bo.

Integración co sistema de revisión de código

Unha vez, configuramos o usuario técnico de AppSec como o revisor predeterminado nunha serie de proxectos importantes. Dependendo de se se atoparon erros no novo código ou se non hai erros, o revisor pon o estado na solicitude de extracción para "aceptar" ou "necesita traballar" - ou todo está ben ou precisas finalizar e enlazar a que exactamente para finalizar. Para a integración coa versión que se está a lanzar, desactivamos a combinación se non se supera a proba de IS. Incluímos isto na revisión manual do código e o resto dos participantes do proceso viron os estados de seguranza deste proceso en particular.

Integración con SonarQube

Moitos teñen porta de calidade en canto á calidade do código. Aquí é o mesmo: podes facer as mesmas portas só para instrumentos SAST. Haberá a mesma interface, a mesma porta de calidade, só se chamará porta de seguridade. E ademais, se tes un proceso configurado usando SonarQube, podes integrar todo alí facilmente.

Integración a nivel CI

Aquí, tamén, todo é moi sinxelo:

• A par cos autotests, probas unitarias.
• División por fases de desenvolvemento: dev, proba, prod. Poden incluírse diferentes conxuntos de regras ou diferentes condicións de falla: paramos a montaxe, non paramos a montaxe.
• Inicio sincrónico/asíncrono. Estamos á espera de que rematen as probas de seguridade ou non estamos á espera. É dicir, só os lanzamos e seguimos adiante, e despois temos un estado de que todo é bo ou malo.

Todo está nun mundo rosa perfecto. Na vida real, este non é o caso, pero esforzámonos. O resultado da realización das comprobacións de seguridade debe ser similar aos resultados das probas unitarias.

Por exemplo, tomamos un proxecto grande e decidimos que agora escanearémolo con SAST - OK. Introducimos este proxecto en SAST, deunos 20 vulnerabilidades e tomamos unha decisión decidida de que todo está ben. 000 vulnerabilidades é a nosa débeda técnica. Poñeremos a débeda nunha caixa, pouco a pouco irémola recuperando e iniciaremos erros nos rastreadores de defectos. Contrata unha empresa, facemos todo nós mesmos ou fai que nos axuden os campións de seguridade, e a débeda técnica diminuirá.

E todas as vulnerabilidades que aparecen recentemente no novo código deben eliminarse do mesmo xeito que os erros nunha unidade ou nas probas automáticas. Relativamente falando, a montaxe comezou, marchou, caeron dúas probas e dúas de seguridade. OK - fomos, miramos o que pasou, corriximos un, corriximos o segundo, conducimos a próxima vez - todo está ben, non apareceron novas vulnerabilidades, as probas non fallaron. Se esta tarefa é máis profunda e necesitas entendela ben, ou corrixir vulnerabilidades afecta a grandes capas do que hai debaixo do capó: introdúcese un erro no rastreador de defectos, priorízase e soluciona. Desafortunadamente, o mundo non é perfecto e as probas ás veces fallan.

Un exemplo de porta de seguridade é un análogo dunha porta de calidade, en canto á presenza e número de vulnerabilidades no código.

Integramos con SonarQube: o complemento está instalado, todo é moi cómodo e xenial.

Integración do contorno de desenvolvemento

Opcións de integración:

• Iniciando unha exploración desde o ambiente de desenvolvemento mesmo antes da confirmación.
• Ver resultados.
• Análise de resultados.
• Sincronización co servidor.

Así se ve a obtención de resultados do servidor.

No noso entorno de desenvolvemento IDEA Intelixente só aparece un elemento adicional que di que se atoparon tales vulnerabilidades durante a exploración. Podes editar o código inmediatamente, ver recomendacións e gráfico de fluxo. Todo isto está situado no lugar de traballo do programador, o que é moi cómodo: non necesitas seguir o resto das ligazóns e ver algo extra.

Open Source

Este é o meu tema favorito. Todo o mundo usa bibliotecas de código aberto: por que escribir un montón de muletas e bicicletas cando podes levar unha biblioteca preparada na que xa está todo implementado?

Por suposto, isto é certo, pero as bibliotecas tamén son escritas por persoas, tamén inclúen certos riscos, e tamén hai vulnerabilidades que se denuncian periódicamente ou constantemente. Polo tanto, hai un seguinte paso na Seguridade das Aplicacións: esta é a análise dos compoñentes de código aberto.

Análise de código aberto - OSA

A ferramenta inclúe tres pasos principais.

Buscando vulnerabilidades nas bibliotecas. Por exemplo, a ferramenta sabe que estamos a usar algún tipo de biblioteca, e que en CVE ou nos rastreadores de erros hai algunhas vulnerabilidades que se relacionan con esta versión da biblioteca. Se tentas usalo, a ferramenta avisará de que a biblioteca é vulnerable e aconsellará que utilices outra versión na que non existan vulnerabilidades.

Análise da pureza da licenza. Isto aínda non é moi popular entre nós, pero se traballas cun país estranxeiro, podes recibir un ataque periódicamente por usar un compoñente de código aberto que non se pode usar nin modificar. Segundo a política da biblioteca con licenza, non podemos facelo. Ou, se o modificamos e o usamos, debemos publicar o noso código. Por suposto, ninguén quere publicar o código dos seus produtos, pero tamén pode protexerse disto.

Análise de compoñentes que se utilizan nun entorno industrial. Imaxina unha situación hipotética na que por fin completamos o desenvolvemento e publicamos a última versión do noso microservizo para o sector. Vive alí de marabilla: unha semana, un mes, un ano. Non o recollemos, non realizamos controis de seguridade, todo parece estar ben. Pero de súpeto, dúas semanas despois do lanzamento, sae unha vulnerabilidade crítica no compoñente Open Source, que utilizamos neste conxunto concreto, no ámbito industrial. Se non gravamos o que e onde usamos, entón esta vulnerabilidade simplemente non se verá. Algunhas ferramentas teñen a capacidade de supervisar as vulnerabilidades das bibliotecas que se usan actualmente no baile. É moi útil.

Características:

• Diferentes políticas para diferentes etapas de desenvolvemento.
• Monitorización de compoñentes nun entorno industrial.
• Control de bibliotecas no contorno da organización.
• Soporte para varios sistemas de compilación e linguaxes.
• Análise de imaxes de Docker.

Algúns exemplos de líderes no campo que se dedican á análise do código aberto.

O único gratuíto é Verificación de dependencia de OWASP. Podes acendelo nas primeiras etapas, ver como funciona e o que admite. Basicamente, todos estes son produtos na nube, ou on-premise, pero detrás da súa base aínda van a Internet. Non envían as túas bibliotecas, senón hash ou os seus valores que calculan, e pegadas dixitais ao seu servidor para recibir noticias da presenza de vulnerabilidades.

Integración de procesos

Control de biblioteca perimetralque se descargan de fontes externas. Contamos con repositorios externos e internos. Por exemplo, temos Nexus dentro de Event Central e queremos asegurarnos de que non hai vulnerabilidades cun estado "crítico" ou "alto" dentro do noso repositorio. Podes configurar o proxy usando a ferramenta Nexus Firewall Lifecycle para que estas vulnerabilidades queden eliminadas e non se inclúan no repositorio interno.

Integración de CI. Ao mesmo nivel con autotests, probas unitarias e división en fases de desenvolvemento: dev, test, prod. En cada etapa, pode descargar calquera biblioteca, usar calquera cousa, pero se hai algo difícil co estado "crítico", probablemente debería chamar a atención dos desenvolvedores sobre isto na fase de entrada ao baile de graduación.

Integración de artefactos: Nexus e JFrog.

Integración no contorno de desenvolvemento. As ferramentas que elixas deberían ter integración con contornos de desenvolvemento. O programador debe ter acceso aos resultados da exploración desde o seu lugar de traballo ou a capacidade de dixitalizar e comprobar o código para detectar vulnerabilidades antes de cometelo en CVS.

Integración de CD. Esta é unha característica interesante que me gusta moito e da que xa falei: o seguimento da aparición de novas vulnerabilidades nun ambiente industrial. Funciona así.

Temos Repositorios de compoñentes públicos - algunhas ferramentas fóra, e o noso repositorio interno. Queremos que só haxa compoñentes de confianza. Ao enviar unha solicitude por proxy, comprobamos que a biblioteca descargada non teña vulnerabilidades. Se cae en determinadas políticas que establecemos e necesariamente coordinamos co desenvolvemento, entón non o cargamos e recibimos un rexeitamento para usar unha versión diferente. En consecuencia, se hai algo realmente crítico e malo na biblioteca, entón o desenvolvedor non recibirá a biblioteca nin sequera na fase de instalación; déixalle usar unha versión superior ou inferior.

• Ao construír, comprobamos que ninguén esvareu nada malo, que todos os compoñentes están seguros e que ninguén trouxo nada perigoso na unidade flash.
• Só temos compoñentes de confianza no repositorio.
• Ao implementar, comprobamos de novo o propio paquete: war, jar, DL ou Docker imaxe para comprobar o feito de que cumpre coa política.
• Ao entrar no ámbito industrial, vixíamos o que está a suceder no ámbito industrial: aparecen ou non aparecen vulnerabilidades críticas.

Análise Dinámica - DAST

As ferramentas de análise dinámica son fundamentalmente diferentes de todo o que se dixo antes. Trátase dunha especie de imitación do traballo do usuario coa aplicación. Se se trata dunha aplicación web, enviamos solicitudes imitando o traballo do cliente, prememos nos botóns da parte frontal, enviamos datos artificiais desde o formulario: comiñas, corchetes, caracteres en diferentes codificacións para ver como funciona a aplicación e os procesos externos. datos.

O mesmo sistema permítelle comprobar as vulnerabilidades de modelos en código aberto. Dado que DAST non sabe que código aberto estamos a usar, simplemente arroxa patróns "maliciosos" e analiza as respostas do servidor:

- Si, aquí hai un problema de deserialización, pero aquí non.

Hai grandes riscos nisto, porque se realizas esta proba de seguridade no mesmo stand co que traballan os probadores, poden ocorrer cousas desagradables.

• Alta carga na rede do servidor de aplicacións.
• Sen integracións.
• A posibilidade de cambiar a configuración da aplicación analizada.
• Non hai soporte para as tecnoloxías necesarias.
• Dificultade de fixación.

Tivemos unha situación na que finalmente lanzamos AppScan: descoñecemos o acceso á aplicación durante moito tempo, recibimos 3 contas e quedamos encantados; por fin, comprobaremos todo. Lanzamos unha exploración e o primeiro que fixo AppScan foi entrar no panel de administración, perforar todos os botóns, cambiar a metade dos datos e despois matar o servidor por completo co seu propio formulario de correo- solicitudes. Desenvolvemento con probas dixo:

"Rapaces, estades bromeando?! Démosche contas, e ti puxeches o posto!

Considere os posibles riscos. O ideal é preparar un posto separado para probar a seguridade da información, que estará illado do resto do ambiente polo menos dalgún xeito, e comprobar condicionalmente o panel de administración, preferiblemente en modo manual. Este é un pentest: as porcentaxes restantes de esforzos que non estamos considerando agora.

Paga a pena ter en conta que pode usar isto como un análogo da proba de carga. Na primeira fase, podes activar o escáner dinámico en 10-15 fíos e ver o que pasa, pero normalmente, como mostra a práctica, nada bo.

Algúns recursos que utilizamos habitualmente.

Merece a pena destacar Suite Burp é o "coitelo suízo" para calquera profesional da seguridade. Todo o mundo o usa e é moi cómodo. Agora lanzouse unha nova versión de demostración da edición empresarial. Se antes era só unha utilidade autónoma con complementos, agora os desenvolvedores por fin están a facer un gran servidor desde o que será posible xestionar varios axentes. É xenial, recoméndoche que o probes.

Integración de procesos

A integración é bastante boa e sinxela: iniciar a exploración despois da instalación exitosa aplicacións no stand e dixitalización despois dunha proba de integración exitosa.

Se as integracións non funcionan ou hai stubs e funcións simuladas, é inútil e inútil; non importa o patrón que enviemos, o servidor seguirá respondendo do mesmo xeito.

• Idealmente, un banco de probas separado.
• Antes da proba, anote a secuencia de inicio de sesión.
• A proba do sistema de administración é só manual.

proceso

Un pouco xeneralizado sobre o proceso en xeral e sobre o traballo de cada ferramenta, en particular. Todas as aplicacións son diferentes: unha funciona mellor con análise dinámica, outra con análise estática, a terceira con análise OpenSource, pentests ou outra cousa en xeral, por exemplo, eventos con Waf.

Todo proceso debe ser controlado.

Para comprender como funciona o proceso e onde se pode mellorar, cómpre recompilar métricas de todo o que poida ter nas súas mans, incluíndo métricas de produción, métricas de ferramentas e rastreadores de defectos.

Calquera información é útil. Cómpre mirar en varias seccións onde se utiliza mellor esta ou aquela ferramenta, onde o proceso se deforma especificamente. Pode valer a pena mirar o tempo de resposta do desenvolvemento para ver onde mellorar o proceso en función do tempo. Cantos máis datos, máis cortes pódense construír desde o nivel superior ata os detalles de cada proceso.

Xa que todos os analizadores estáticos e dinámicos teñen as súas propias API, os seus propios métodos de lanzamento, principios, algúns teñen programadores, outros non - estamos escribindo unha ferramenta AppSec Orchestrator, que permite facer un único punto de entrada a todo o proceso desde o produto e xestionalo desde un punto.

Os xestores, desenvolvedores e enxeñeiros de seguridade teñen un punto de entrada desde o que poden ver o que se está a executar, configurar e executar análises, obter resultados de análise e enviar requisitos. Tentamos fuxir dos anacos de papel, traducir todo a un humano que utiliza o desenvolvemento: páxinas sobre Confluence con estado e métricas, defectos en Jira ou en varios rastreadores de defectos, ou incorporar nun proceso síncrono/asíncrono en CI/CD.

Lugares para levar

As ferramentas non importan. Pense primeiro no proceso e despois implemente as ferramentas. As ferramentas son boas, pero caras, polo que podes comezar co proceso e afinar a interacción e a comprensión entre desenvolvemento e seguridade. Desde o punto de vista da seguridade, non hai que "parar" todo seguido.Desde o punto de vista do desenvolvemento, se hai algo de alto mega super crítico, entón isto debe ser eliminado e non pechado ao problema. .

Calidade do produto - Obxectivo común tanto de seguridade como de desenvolvemento. Facemos unha cousa, intentamos garantir que todo funcione correctamente e que non haxa riscos reputacionais e perdas financeiras. É por iso que promovemos o enfoque de DevSecOps, SecDevOps para establecer comunicación e mellorar o produto.

Comeza polo que xa hai: requisitos, arquitectura, comprobacións parciais, adestramentos, directrices. Non é necesario aplicar inmediatamente todas as prácticas a todos os proxectos - moverse de forma iterativa. Non hai un único estándar experimento e probar diferentes enfoques e solucións.

Sinal de igualdade entre defectos IS e defectos funcionais.

Automatiza todoque se está movendo. Todo o que non se move, move e automatiza. Se algo se fai a man, esta non é unha boa parte do proceso. Quizais tamén paga a pena reconsideralo e automatizalo.

Se o tamaño do equipo do IB é pequeno - use Security Champions.

Quizais o que falei non che conveña e che inventes algo propio, e iso é bo. Pero escoller ferramentas en función dos requisitos do seu proceso. Non mire o que a comunidade di que esta ferramenta é mala e esta é boa. Quizais sexa ao revés no teu produto.

Requisitos da ferramenta.

• Baixo falso positivo.
• Tempo de análise adecuado.
• Facilidade de uso.
• Dispoñibilidade de integracións.
• Comprensión da folla de ruta do desenvolvemento do produto.
• Capacidade de personalizar ferramentas.

O informe de Yuriy foi elixido como un dos mellores na DevOpsConf 2018. Para familiarizarse con ideas e casos prácticos aínda máis interesantes, achégate a Skolkovo os días 27 e 28 de maio. DevOpsConf dentro festival RIT++. Aínda mellor, se estás disposto a compartir a túa experiencia, entón aplicar Envía o teu informe ata o 21 de abril.

Fonte: www.habr.com