Como parte das súas actividades profesionais, os desenvolvedores, os pentesters e os especialistas en seguridade teñen que xestionar procesos como a Xestión de Vulnerabilidade (VM), o SDLC (Seguro).
Debaixo destas frases atópanse diferentes conxuntos de prácticas e ferramentas empregadas que se entrelazan, aínda que os seus usuarios difiren.
O progreso técnico aínda non chegou ao punto en que unha ferramenta pode substituír a unha persoa para analizar a seguridade da infraestrutura e do software.
É interesante entender por que isto é así e a que problemas se enfronta.
Os procesos
O proceso de xestión de vulnerabilidades está deseñado para a monitorización continua da seguridade da infraestrutura e a xestión de parches.
O proceso Secure SDLC ("ciclo de desenvolvemento seguro") está deseñado para manter a seguridade das aplicacións durante o desenvolvemento e a operación.
Unha parte semellante destes procesos é o proceso de Avaliación de Vulnerabilidade: avaliación de vulnerabilidades, dixitalización de vulnerabilidades.
A principal diferenza entre a dixitalización dentro da máquina virtual e a SDLC é que, no primeiro caso, o obxectivo é detectar vulnerabilidades coñecidas en software de terceiros ou na configuración. Por exemplo, unha versión desactualizada Windows ou a cadea de comunidade predeterminada para SNMP.
No segundo caso, o obxectivo é detectar vulnerabilidades non só en compoñentes de terceiros (dependencias), senón principalmente no código do novo produto.
Isto crea diferenzas en ferramentas e enfoques. Na miña opinión, a tarefa de buscar novas vulnerabilidades nunha aplicación é moito máis interesante, xa que non se reduce a pegadas dixitais versións, recoller banners, forzar contrasinais, etc.
Para a dixitalización automatizada de alta calidade das vulnerabilidades das aplicacións, son necesarios algoritmos que teñan en conta a semántica da aplicación, o seu propósito e as ameazas específicas.
Un escáner de infraestrutura adoita ser substituído por un temporizador, como digo eu . A cuestión é que, meramente estatísticamente, pode considerar vulnerable a súa infraestrutura se non a actualiza, por exemplo, durante un mes.
Ferramentas
A dixitalización, como a análise de seguridade, pódese realizar mediante unha caixa negra ou unha caixa branca.
Black Box
Ao escanear a caixa negra, a ferramenta debe poder traballar co servizo a través das mesmas interfaces a través das que os usuarios traballan con el.
Os escáneres de infraestrutura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) buscan portos de rede abertos, recollen "banners", determinan versións do software instalado e buscan na súa base de coñecemento información sobre vulnerabilidades destas versións. Tamén tentan detectar erros de configuración como contrasinais predeterminados ou acceso a datos abertos, cifrados SSL débiles, etc.
Os escáneres de aplicacións web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) tamén poden identificar compoñentes coñecidos e as súas versións (por exemplo, CMS, frameworks, bibliotecas JS). Os pasos principais do escáner son o rastrexo e o fuzzing.
Durante a exploración, o escáner recolle información sobre as interfaces de aplicacións existentes e os parámetros HTTP. Durante o fuzzing, os datos mutados ou xerados insírense en todos os parámetros detectados para provocar un erro e detectar unha vulnerabilidade.
Estes escáneres de aplicacións pertencen ás clases DAST e IAST - Probas de seguridade de aplicacións dinámicas e interactivas, respectivamente.
Caixa branca
Hai máis diferenzas coa dixitalización da caixa branca.
Como parte do proceso de VM, os escáneres (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) adoitan ter acceso aos sistemas mediante a realización dunha exploración autenticada. Así, o escáner pode descargar versións de paquetes instalados e parámetros de configuración directamente do sistema, sen adiviñalos dos banners do servizo de rede.
A exploración é máis precisa e completa.
Se falamos de dixitalización de caixas brancas (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) das aplicacións, entón estamos a falar normalmente de análise de código estático e do uso de ferramentas adecuadas da clase SAST - Probas de seguridade de aplicacións estáticas.
Problemas
Hai moitos problemas coa dixitalización! Teño que tratar coa maioría deles persoalmente como parte da prestación dun servizo para construír procesos de dixitalización e desenvolvemento seguro, así como cando realizo traballos de análise de seguridade.
Destacarei 3 grupos principais de problemas, que se confirman mediante conversas con enxeñeiros e xefes de servizos de seguridade da información en diversas empresas.
Problemas de dixitalización de aplicacións web
- Dificultade de implementación. Os escáneres deben ser despregados, configurados, personalizados para cada aplicación, asignado un ambiente de proba para as exploracións e implementados no proceso CI/CD para que isto sexa efectivo. En caso contrario, será un procedemento formal inútil que só producirá falsos positivos
- Duración da exploración. Incluso en 2019, os escáneres fan un mal traballo de deduplicación de interfaces e poden pasar días escaneando mil páxinas con 10 parámetros en cada unha, considerándoas diferentes, aínda que o mesmo código é o responsable delas. Ao mesmo tempo, a decisión sobre a implantación na produción dentro do ciclo de desenvolvemento debe tomarse rapidamente
- Recomendacións pobres. Os escáneres dan recomendacións bastante xerais e o programador non sempre pode comprender rapidamente como reducir o nivel de risco e, o máis importante, se hai que facelo agora mesmo ou aínda non dá medo.
- Impacto destrutivo na aplicación. Os escáneres poden levar a cabo un ataque DoS a unha aplicación e tamén poden crear un gran número de entidades ou cambiar as existentes (por exemplo, crear decenas de miles de comentarios nun blog), polo que non deberías lanzar un escaneo en produción sen pensar.
- Baixa calidade da detección de vulnerabilidades. Os escáneres adoitan usar unha matriz fixa de cargas útiles e poden perder facilmente unha vulnerabilidade que non encaixa no escenario de comportamento coñecido da aplicación.
- O escáner non comprende as funcións da aplicación. Os propios escáneres non saben o que son "banca por Internet", "pago", "comentario". Para eles, só hai ligazóns e parámetros, polo que unha enorme capa de posibles vulnerabilidades da lóxica empresarial permanece completamente descuberta; non se lles ocorrerá facer unha dobre cancelación, espiar os datos doutra persoa por ID ou aumentar o saldo mediante o redondeo.
- O escáner non entende a semántica das páxinas. Os escáneres non poden ler as preguntas frecuentes, non poden recoñecer os captchas e por si só non descubrirán como rexistrarse e logo volver iniciar sesión, que non pode facer clic en "Saír" e como asinar solicitudes ao cambiar o parámetro valores. Como resultado, a maior parte da aplicación pode non ser dixitalizada en absoluto.
Problemas ao escanear o código fonte
- Falsos positivos. A análise estática é unha tarefa complexa que implica moitas compensacións. Moitas veces hai que sacrificar a precisión, e incluso os escáneres empresariais caros producen un gran número de falsos positivos
- Dificultade de implementación. Para aumentar a precisión e integridade da análise estática, é necesario refinar as regras de dixitalización e escribir estas regras pode ser demasiado laboriosa. Ás veces é máis fácil atopar todos os lugares do código con algún tipo de erro e solucionalos que escribir unha regra para detectar estes casos
- Falta de apoio á dependencia. Os grandes proxectos dependen dunha gran cantidade de bibliotecas e frameworks que amplían as capacidades da linguaxe de programación. Se a base de coñecemento do escáner non ten información sobre os "sumidoiros" nestes marcos, converterase nun punto cego e o escáner simplemente nin sequera entenderá o código
- Duración da exploración. Buscar vulnerabilidades no código é unha tarefa complexa en termos de algoritmos. Polo tanto, o proceso pode levar moito tempo e requirir recursos informáticos importantes.
- Baixa cobertura. A pesar do consumo de recursos e do tempo de dixitalización, os desenvolvedores de ferramentas SAST aínda teñen que facer compromisos e analizar non todos os estados nos que pode estar o programa.
- Reproducibilidade dos achados. Apuntar á liña específica e á pila de chamadas que leva a unha vulnerabilidade é xenial, pero en realidade, moitas veces o escáner non proporciona información suficiente para comprobar a presenza dunha vulnerabilidade desde o exterior. Despois de todo, a falla tamén pode estar nun código morto, que é inalcanzable para un atacante
Problemas de dixitalización de infraestruturas
- Inventario insuficiente. Nas grandes infraestruturas, especialmente nas separadas xeograficamente, adoita ser o máis difícil saber que hosts escanear. Noutras palabras, a tarefa de dixitalización está intimamente relacionada coa tarefa de xestión de activos
- Mala priorización. Os escáneres de rede adoitan producir moitos resultados con fallos que non se poden explotar na práctica, pero formalmente o seu nivel de risco é alto. O consumidor recibe un informe difícil de interpretar e non está claro o que hai que corrixir primeiro.
- Recomendacións pobres. A base de coñecemento do escáner contén moitas veces só información moi xeral sobre a vulnerabilidade e como solucionala, polo que os administradores terán que armarse con Google. A situación é un pouco mellor cos escáneres de caixa branca, que poden emitir un comando específico para corrixir
- Feito a man. As infraestruturas poden ter moitos nodos, o que significa potencialmente moitos fallos, informes sobre os cales deben ser analizados e analizados manualmente en cada iteración.
- Mala cobertura. A calidade da exploración da infraestrutura depende directamente do tamaño da base de coñecemento sobre vulnerabilidades e versións de software. onde, , mesmo os líderes do mercado non teñen unha base de coñecemento completa, e as bases de datos de solucións gratuítas conteñen moita información que os líderes non teñen
- Problemas co parcheo. Na maioría das veces, parchear vulnerabilidades da infraestrutura implica actualizar un paquete ou cambiar un ficheiro de configuración. O gran problema aquí é que un sistema, especialmente un legado, pode comportarse de forma imprevisible como resultado dunha actualización. Esencialmente, terás que realizar probas de integración na infraestrutura en directo en produción.
Aproximacións
Como pode ser iso?
Contareivos máis sobre exemplos e como tratar moitos dos problemas enumerados nas seguintes partes, pero de momento indicarei as principais direccións nas que pode traballar:
- Agregación de varias ferramentas de dixitalización. Co uso correcto de varios escáneres, pódese conseguir un aumento significativo da base de coñecemento e da calidade da detección. Podes atopar aínda máis vulnerabilidades que o total de todos os escáneres lanzados por separado, mentres que podes avaliar con máis precisión o nivel de risco e facer máis recomendacións
- Integración de SAST e DAST. É posible aumentar a cobertura de DAST e a precisión de SAST intercambiando información entre eles. A partir das fontes podes obter información sobre as rutas existentes, e usando DAST podes comprobar se a vulnerabilidade é visible desde o exterior
- Machine Learning™. En 2015 I (e ) sobre o uso das estatísticas para dar aos escáneres a intuición dun hacker e aceleralos. Este é definitivamente un alimento para o desenvolvemento de análises de seguridade automatizadas no futuro.
- Integración de IAST con autotests e OpenAPI. Dentro da canalización CI/CD, é posible crear un proceso de dixitalización baseado en ferramentas que funcionan como un proxy HTTP e probas funcionais que funcionan sobre HTTP. As probas e contratos OpenAPI/Swagger darán ao escáner a información que falta sobre os fluxos de datos e permitirán escanear a aplicación en varios estados.
- Configuración correcta. Para cada aplicación e infraestrutura, cómpre crear un perfil de dixitalización axeitado, tendo en conta o número e a natureza das interfaces e as tecnoloxías utilizadas.
- Personalización do escáner. Moitas veces non se pode dixitalizar unha aplicación sen modificar o escáner. Un exemplo é unha pasarela de pago, na que cada solicitude debe estar asinada. Sen escribir un conector para o protocolo de pasarela, os escáneres bombardearán sen pensar con solicitudes coa sinatura incorrecta. Tamén é necesario escribir escáneres especializados para un tipo específico de defecto, como
- Xestión de riscos. O uso de diversos escáneres e a integración con sistemas externos como Asset Management e Threat Management permitirán utilizar moitos parámetros para avaliar o nivel de risco, de xeito que a dirección poida obter unha imaxe adecuada do estado actual de seguridade do desenvolvemento ou da infraestrutura.
Estade atentos e imos interromper a exploración de vulnerabilidades.
Fonte: www.habr.com
