Riesgos de seguridad de ejecutar una aplicación php en PHP 5.4

Regla uno: cubre tu trasero: asegúrate de tener un registro externo de que reportes un riesgo de seguridad para tu CTO y su respuesta.

Más allá de eso, si existe el riesgo de que la actualización rompa la autenticación, el primer paso es caracterizar ese riesgo. Soy consciente de los cambios en la implementación de Blypt de Blypt en 5.3.7, pero son compatibles con versiones anteriores y actualmente está en 5.4

Lo más importante que puede hacer para garantizar la seguridad de sus aplicaciones es mantener sus parches actualizados. En 2015 y 2016, US-CERT informó que el 85% de los compromisos se pudieron prevenir (aplicando los parches) . El compromiso de Equifax de 2017 fue el resultado de un software sin parches en una aplicación web. No tienes que buscar mucho para encontrar más ejemplos.

Enumerar las vulnerabilidades actuales en su pila realmente no ayuda con el problema, debe tener procesos implementados para mantener su software actualizado. No necesita enumerar las vulnerabilidades conocidas actualmente.

Es razonable tomar la decisión de no aplicar un parche si la organización puede probar que las pérdidas resultantes serían significativamente menores que el costo de la actualización. Pero, ¿se ha hecho realmente ese análisis?

Si bien puede optar por pasar su CTO al propietario / parte interesada, a menos que sea una empresa que cotice en bolsa, es poco probable que entiendan sus inquietudes o favorezcan su versión de los eventos sobre la de la CTO. Cualquier organización competente debe mantener un registro de riesgos: debe documentar su comprensión de la situación actual, el peligro de encontrarse en una situación en la que no puede actualizar fácilmente y solicitar que se agregue al registro de riesgos corporativo.

Estoy con tu CTO.

Los registros de cambios para PHP 5 y FFF:

https://secure.php.net/ChangeLog-5.php
https://github.com/bcosca/fatfree/issues?utf8=%E2%9C%93&q=is%3Aissue+security

tienen mucho en ellos para excitar a un atacante / teamer rojo. Pero nunca es tan simple.

Es probable que realizar una actualización única de la plataforma y el marco tenga muy poco impacto en la postura general de seguridad de su aplicación.

Por supuesto, parchear los puntos finales visibles de los atacantes y mantenerse actualizados en las dependencias a nivel de aplicación son hábitos organizativos importantes / críticos. Pero tienen que ser hábitos, no proyectos.

Tratarlos como proyectos es como ir a una dieta de choque. Tres a seis meses después, estás de vuelta en el mismo lugar.

Recomiendo un curso de acción diferente. Dos acciones:

1. documente un modelo de amenaza para su aplicación
2. documente un plan para defender el modelo de amenaza centrándose en las líneas de código y configuración de las que usted es responsable, de modo que puedan compararse con defensas similares ejecutadas a través de actualizaciones de la plataforma o infraestructura

Un modelo de amenaza es solo un término extravagante para documentar en un lenguaje sencillo:

• lo que hace su aplicación, en el contexto de su negocio e industria
• de las características y funciones que ofrece, que son sensibles (y por qué, y a quién) y cuáles no
• qué tipo de atacantes estarían interesados en los bits sensibles
• qué protecciones existen actualmente para advertir o defenderse de esos atacantes
• qué mitigaciones existen para qué tipo de compromisos (seguros, etc.)

Quizás ya tenga algo así como un modelo de amenaza de la auditoría de seguridad de la aplicación web, aunque es más probable que sea solo una lista de deficiencias, no algo que analice la aplicación en el contexto del ecosistema. Las listas de deficiencias no son tan útiles porque todas las plataformas son explotables, dado el tiempo, los recursos y la atención suficientes. Incluso los puntajes de alto riesgo son genéricos, no necesariamente aplicables a una situación particular.

Las defensas más importantes para enfocarse, dado el tiempo y la atención limitados de cada uno, son aquellas que abordan las áreas de mayor riesgo para su organización de las que su aplicación tiene responsabilidad funcional. Esta priorización debe provenir de un modelo de amenaza.

Como mantenedor, sabe lo que hace la aplicación y probablemente conozca el contexto del ecosistema. Probablemente tenga una idea de qué características / funciones / datos son sensibles y cuáles no. Puede que no tenga el contexto completo, pero esa es un área importante para desarrollar la comprensión. Probablemente no sepa qué tipos de atacantes podrían estar interesados en qué tipo de exposición, qué protecciones existen actualmente en otras capas de la pila de tecnología y qué mitigaciones a nivel de organización existen. (Cada organización tiene una lista de "riesgos conocidos". No se defienda contra algo que se considera un riesgo conocido).

En cualquier área, debería poder aprender lo que no sabe de conversaciones relativamente cortas con su equipo de seguridad y / u otros en la jerarquía de su organización. Un documento de primer paso que resuma estos aprendizajes no debe tener más de 2 páginas.

Una vez que tenga un modelo de amenazas que encuentre amenazas para las cuales puede haber una mitigación insuficiente, las propuestas para mitigar los cambios en el código de la aplicación o mediante otros enfoques (como las actualizaciones de la plataforma) pueden compararse entre sí en cuanto al costo y la efectividad. Y ahora estás hablando el lenguaje de tu CTO.

Después de seguir estos dos pasos, puede llegar a un lugar donde un proyecto único para actualizar PHP y FFF, dada la dificultad (las actualizaciones de PHP 5 no son divertidas), no llega a 4 o 5 en la lista de las prioridades de seguridad. Está bien. Un mejor proyecto es construir la automatización que permita mantenerse actualizado para ser un hábito.

Espero que sea útil, aunque quizás no sea la respuesta que estás buscando. Buena suerte.