En teoría, lo que su profesor propone es razonable. Pero hay un problema en la práctica. Usted nunca llega a una configuración estable. Siempre.
No hay software no trivial por ahí que no tenga errores desconocidos. Ninguna. Y algún porcentaje de esos errores son vulnerabilidades de seguridad.
¿Qué propone hacer el profesor si alguien encuentra una vulnerabilidad de ejecución remota de código en el sistema después de que se complete la certificación?
¿Realmente cree que es más seguro mantener un sistema implementado con una vulnerabilidad conocida de ejecución remota de código que correr el riesgo de un parche?
La respuesta (sorprendentemente) podría ser "sí". Y eso va al corazón de la seguridad del mundo real. La seguridad es realmente acerca de la gestión de riesgos. Cada pieza de software implementada tiene un cierto riesgo asociado con ese software. El software recién implementado podría romper una aplicación de línea de negocio existente. Podría introducir nuevas vulnerabilidades.
Básicamente, no hay forma de saber qué podría pasar. Por lo tanto, debe decidir cuál es su tolerancia al riesgo.
Para algunos sistemas (a menudo los sistemas en los que la vida de alguien depende del sistema), en realidad es mejor mantener el sistema sin cambios (incluso si existen vulnerabilidades conocidas) y mitigar las vulnerabilidades fuera del sistema (tal vez con un firewall). Para otros sistemas, todo lo que necesita hacer es asegurarse de que sus aplicaciones de línea de negocio continúen funcionando.
Aquí no hay una solución única para todos. Cada empresa debe tomar su propia decisión sobre las compensaciones de riesgo / recompensa asociadas con un parche de seguridad. Algunos aceptarán el riesgo, otros no.