Además de la respuesta de Johnmark Glaze, donde menciona varias causas, me gustaría ofrecer algunas más:
- Algunas partes del código son extremadamente complejas : las rutinas que están diseñadas para implementar ciertos protocolos o estándares pueden ser abrumadoras para que todas, excepto algunas personas, comprendan. A veces, el protocolo en sí mismo podría introducir vulnerabilidades que los desarrolladores, sin culpa de sí mismos, transmiten al software / hardware que construyen. Cualquier software de seguridad, implementación de cifrado u otras funciones de criptología relacionadas, es fácil de equivocar. Y a veces solo se necesita un pequeño error para abrir una puerta grande.
- Algunos softwares ahora se usan en un contexto diferente al de su entorno original . Esto es cierto para muchas rutinas en el núcleo de Unix y sistemas similares a Unix. Cuando esas rutinas se escribieron originalmente, no había World Wide Web y se escribieron para redes pequeñas donde se podía confiar en cualquier otro sistema. Estas rutinas ahora se utilizan para conectarse a una red enorme donde no se puede confiar en otros dispositivos.
- Los protocolos y, en última instancia, los dispositivos que condujeron a Internet de hoy dependen de la confianza . Si los sistemas informáticos se hubieran dejado a sus inventores originales (personas con mentalidad militar y corporativa), algunas de las revoluciones que tuvieron lugar e hicieron realidad la informática personal no hubieran ocurrido. Estas revoluciones involucraron a personas que tenían la generosa idea de compartir universalmente la información y los recursos informáticos. El altruismo y la confianza fueron la base del diseño de lo que hace que Internet sea lo que es hoy. No privacidad o secreto. Debido a eso, los protocolos actuales exponen la arquitectura de sus redes subyacentes. Información que es valiosa para la mejora de la red y la resolución de problemas, pero también para los malos actores inclinados a paralizar o penetrar esas redes.
- No existen estándares para la codificación segura en ningún nivel . Este punto es una espada de doble filo, al menos en mi opinión. Lo que llamamos codificación segura implica mucha paranoia. Requiere que el desarrollador crea que todas y cada una de las entradas en su software pueden, y serán , utilizadas para subvertirlo y potencialmente apoderarse de todo el sistema donde se ejecuta ese software. Es una visión muy oscura del mundo que va completamente en contra de la persona promedio, que es optimista y cree en los usuarios afables. Un buen ejemplo de esta vista oscura es la Guía de codificación segura de Apple (https://developer.apple.com/library/ios/documentation/Security/Conceptual/SecureCodingGuide/). A pesar de que todo lo que dicen es cierto y Apple tiene experiencias de la vida real para apoyarlos, la persona promedio siempre dirá algo como “No me va a pasar”, “¿Quién podría encontrar mi aplicación e intentar explotarla?” o “Realmente no necesito preocuparme por ahora, tal vez cuando crezca”. Y esto me lleva al siguiente punto
- La seguridad no puede ser una ocurrencia tardía . Uno no puede asegurar fácilmente una aplicación existente. La seguridad debe implementarse y diseñarse antes de escribir la primera línea de código. Incluso pequeños fragmentos de información filtrados por una aplicación aparentemente inocua pueden ayudar a romper un sistema o crear una imagen de un usuario que espera ser privado. Sin embargo, muchos sistemas se han construido sobre la premisa de la confianza y el intercambio de información y ahora se están adaptando para confiar solo en unos pocos usuarios autenticados. Este proceso hacia atrás es una muy buena receta para puertas traseras y vulnerabilidades no descubiertas.
- La mayoría del software se basa en otras piezas de software . Incluso el proyecto de software más consciente de la seguridad debe confiar en otras piezas de software, ya sea el sistema operativo o las rutinas básicas de muy bajo nivel (acceso a archivos y memoria, comunicación de red, etc.). Si alguna de estas rutinas base tiene una vulnerabilidad, el proyecto de software se ve comprometido.
- No hay buenas fuentes para aprender sobre seguridad informática . Este es (al menos hoy a principios de 2015) el reino de los expertos que hablan en un idioma extraño y que parecen hablar solo de pesimismo. Se necesita una cantidad considerable de esfuerzo para que un desarrollador determinado aprenda y se sienta lo suficientemente cómodo como para aplicar conceptos de seguridad a su aplicación. El resultado son aplicaciones que cortan esquinas o que aplican incorrectamente conceptos de seguridad. Un excelente ejemplo de esto son las revisiones de las aplicaciones de administrador de contraseñas para dispositivos móviles: en 2012, los expertos en seguridad revisaron las 6 mejores aplicaciones de administrador de contraseñas y descubrieron que a pesar de que anunciaban cifrado de grado militar, estaba mal implementado y, por lo tanto, podría romperse fácilmente todos menos uno de ellos. (http://www.darkreading.com/risk-management/security-fail-apple-ios-password-managers/d/d-id/1103401). El revisor en realidad estaba usando una de esas aplicaciones para fines personales y tuvo que detenerse después de lo que descubrió.
- Tendemos a ser complacientes . Desafortunadamente, como descubrimos en 2013 y 2014, algunas organizaciones gubernamentales que contribuyeron significativamente a los estándares de seguridad ampliamente utilizados y sus implementaciones de software habían debilitado intencionalmente esos estándares. Presumiblemente con el objetivo de facilitarles la comunicación a través de esos protocolos. Independientemente de cualquiera de las implicaciones o puntos de vista políticos de uno, tal cosa se opone completamente a los expertos en seguridad, que deberían haber desarrollado una “paranoia profesional”. Incluso la corporación más rica se vería en apuros para competir con las habilidades y la experiencia de la NSA, pero al igual que cualquier otro estándar de seguridad, sus comentarios deben ser cuestionados y evaluados. Esto se considera desconfianza saludable y se aplica a cualquier persona. Los expertos pueden tener una razón para favorecer o contrarrestar un estándar particular, y lo más importante, los expertos también pueden cometer errores. Al tener tanto en juego como al proponer un estándar, tales errores pueden ser devastadores, por lo que la verificación doble y triple de cada entrada es normal para el curso. Sin embargo, creo que es ahora después de todo lo que sucedió.
- Los desarrolladores son flojos . Obviamente estoy bromeando sobre esto, pero es notable la cantidad de piezas de software que se escribieron porque su creador estaba atrapado en un trabajo sin sentido haciendo algo muy tedioso. Decidieron entonces escribir un código para hacer cualquier tarea por ellos y luego se sorprendieron por su adopción y popularidad generalizadas. Estas personas se negaron a seguir haciendo algo muy tedioso y consiguieron una computadora para hacerlo por ellos. Después de eso, ¿qué es lo mejor? ¡Poder hacerlo cuando ni siquiera estás sentado en tu escritorio! Muchas piezas de software tienen puertas traseras o complementos para permitir el monitoreo o control remoto del programa. Estas puertas traseras generalmente están protegidas por la oscuridad en lugar de la seguridad real y se convierten en vulnerabilidades graves.
Entonces, como puede ver (si todavía está leyendo;)), hay muchas razones válidas por las cuales cualquier fragmento de código podría tener vulnerabilidades de seguridad. No existe un sistema “inquebrantable” y esto seguirá siendo cierto.
Pero no todo son malas noticias. Estaba escuchando una entrevista en la radio hace un tiempo, donde un autor del libro mencionó que aprendió a abrir las cerraduras de las puertas como parte de su investigación para escribir el libro que ahora estaba promocionando. El entrevistador le preguntó qué tan difícil fue y el autor respondió “¡es realmente fácil, da miedo!” Una vez que tenga las herramientas adecuadas, puede abrir la mayoría de las cerraduras sin mucho esfuerzo. Todos pueden hacerlo, dijo. Eso no significa que todos debemos apresurarnos a comprar la cerradura de mayor resistencia que podamos encontrar y reemplazar la cerradura de la puerta de nuestra casa. En realidad, solo necesitamos obtener una cerradura que sea lo suficientemente buena como para disuadir a los posibles ladrones. Cualquier otra cosa es una pérdida de dinero y en realidad podría atraer atención no deseada. La misma filosofía se aplica a la seguridad informática. No tenemos que ir por la borda para obtener sistemas seguros. Solo necesitan estar lo suficientemente seguros . Pero al igual que tomamos precauciones para proteger los objetos de valor que llevamos (llaves, talonario de cheques, tarjetas de crédito, etc.), debemos tomar precauciones con los elementos privados que almacenamos en nuestros dispositivos y salir de casa (o en un lugar protegido y confiable) las cosas que realmente no necesitamos llevar en todo momento.
- Hice una búsqueda en Google recientemente y leí un artículo de dos años que el Departamento de Seguridad Nacional de los EE. UU. Me recomendó no instalar Java o eliminarlo por completo porque era la causa de una serie de problemas de seguridad. ¿Siguen existiendo los problemas?
- ¿Qué debo aprender (idiomas, etc.) para una carrera en Seguridad Cibernética?
- ¿Cómo se usan las estadísticas, el aprendizaje automático y la ciencia de datos en ciberseguridad?
- ¿Cuáles son los mejores programas antivirus?
- ¿Es seguro deshabilitar la protección CSRF en un área solo de administrador en una aplicación Django?
