Jeep hack recuerda a las personas que no confíen en la seguridad a través de la oscuridad

La seguridad ya no es una ocurrencia tardía, ni los líderes de TI pueden confiar en la seguridad a través de la oscuridad. Aquí se explica cómo incorporar la seguridad en los productos y programas de TI desde el principio.

La principal brecha de seguridad que ha estado en las noticias recientemente es Jeep Grand Cherokee agrietadoMucho menos abstracto que el robo de datos, contenido en cableado El artículo mostraba a dos ingenieros de buenos modales controlando remotamente un Jeep desde millas de distancia, con el desafortunado reportero al volante. La piratería comenzó levemente, con el sistema HVAC activado y la radio al máximo volumen, finalmente apagando el motor y desactivando los frenos en la carretera. Incluso para los menos expertos en TI, este video demuestra claramente el riesgo muy real de las brechas de seguridad.

Ver CNET: Fiat Chrysler retira del mercado 1,4 millones de vehículos tras hackeo remoto y Fiat Chrysler esperó 18 meses para informar a los reguladores sobre los riesgos de piratería

La seguridad es una ocurrencia tardía, no una característica

En la mayoría de las iniciativas de TI, la seguridad es en gran medida una idea de último momento. Si bien siempre se reconoce la necesidad de seguridad, la implementación real de esa seguridad a menudo se reserva para etapas posteriores del proyecto; en el peor de los casos, suponiendo que la plataforma está lo suficientemente lejos del alcance de un pirata informático como para que la seguridad pueda ignorarse o simplificarse en gran medida: la viejo concepto de seguridad a través de la oscuridad.

Parece haber una buena razón para esperar a implementar la seguridad hasta el final del proyecto.

• La seguridad es difícil y puede interferir con el desarrollo y las pruebas.
• La mayoría de los proyectos intentan conectar los sistemas y el código de la manera más fácil posible y mantener una conversación antes de preocuparse por asegurarlo.
• El equipo del proyecto asumió que el sistema propietario y la red representaban una seguridad «suficientemente buena» y, a medida que se acercaba la fecha límite, las buenas intenciones de aumentar la seguridad más adelante se excluyeron de la hoja de ruta.

El principal problema con este enfoque es que la seguridad se ve como una capa adicional, aplicada sobre un sistema probado y en funcionamiento, o empujada a futuras actualizaciones, porque la ambigüedad de la plataforma se considera seguridad en sí misma. La lógica es que haga que el sistema subyacente sea «correcto» y luego ponga la seguridad en la parte superior cuando sea posible, generalmente en la fase de prueba final. Este enfoque es claramente defectuoso, por lo que en lugar de tratar la seguridad como una capa separada, es mejor pensar en ella como una función de ruta crítica que debe implementarse temprano.

Prueba temprano y con frecuencia

Así como las características y la funcionalidad de las primeras plataformas implementadas suelen ser las más rigurosamente probadas, la seguridad de las primeras implementaciones se someterá a pruebas más rigurosas y se integrará más a fondo con el producto en general. Esto también reduce la necesidad de agregar más seguridad más adelante; si la seguridad es una función implementada en una etapa temprana, el producto no puede progresar hasta que se implemente el modelo de seguridad y se pruebe la unidad.

Las pruebas de seguridad generalmente se realizan como una de las etapas finales de la implementación y deben ser periódicas e incluirse en cada etapa de las pruebas del producto. Esto no solo mejora la seguridad general del producto, sino que, en última instancia, ahorra tiempo y dinero, ya que identificará fallas fundamentales en el modelo de seguridad que pueden afectar otras partes del producto. Relacionado o no con la seguridad, es mejor encontrar una falla fundamental en un sistema y corregirla temprano, en lugar de encontrarla en el último minuto y darse cuenta de que se deben modificar y volver a probar un montón de dependencias.

riesgo de comunicación

Durante mucho tiempo, la seguridad de TI se ha considerado un juego de gallinas, con alguien en el departamento de TI que expresa la necesidad de una mayor seguridad, mientras que otros revisan nerviosamente sus calendarios y los tiempos de entrega restantes. El problema con los enfoques anteriores es que se centran en los aspectos técnicos de la seguridad en lugar del impacto empresarial inmediato. Para Jeep, el video de arriba demuestra dolorosamente el impacto. Reparar fallas de seguridad que deshabilitaron los automóviles de los clientes o les impidieron frenar podría valer decenas de millones de dólares solo para evitar demandas.

Los líderes de TI deben comunicar el costo y el cronograma para integrar la seguridad como una función crítica, así como los diferentes niveles de seguridad que se pueden implementar y los riesgos comerciales que mitigan. Concéntrese menos en los escenarios del fin del mundo y más en la mitigación de riesgos del tiempo y el dinero extra. Hay un punto óptimo entre el costo y el riesgo que debe identificarse y acordarse.

Obtén un poco de ayuda de tus amigos

Muchas de estas vulnerabilidades han sido descubiertas por ingenieros externos y los llamados piratas informáticos de sombrero blanco, que intentan descifrar los sistemas para identificar fallas en lugar de causar daños. Algunos pueden buscar publicidad o el derecho a fanfarronear, mientras que otros pueden buscar dinero en efectivo. En cualquier caso, aprovechar estos recursos puede ser una excelente manera de mejorar los servicios de seguridad proporcionados internamente o por los proveedores, y dar como resultado un producto general mejor y más seguro.

Si bien no puede desarrollar sistemas automotrices, mantener datos financieros o almacenar información secreta del gobierno, es fundamental que la seguridad sea una característica de cualquier producto o proyecto impulsado por TI, no una ocurrencia tardía o un inconveniente. Si no lo hace, es posible que el automóvil no se desvíe de la carretera, pero sin duda impedirá que su carrera se mantenga encaminada.

Nota: CNET, ZDNet y Tecnopedia son propiedades interactivas de CBS.