Imagina dos círculos superpuestos. Una es la ciberseguridad, la otra es el desarrollo de software, la intersección es lo que tienen en común.
Comenzaré con la intersección, porque es relativamente pequeña.
Para ser seguro, el sistema debe aplicar ciertas políticas en el software. Esto afecta el desarrollo de software porque un componente dado no puede usar una instalación a la que no tiene derechos y cada componente debe tener la política más restrictiva que aún permita que el software se ejecute. La modularidad del software determina qué tan fino puede ser esto, aunque casi nadie supera el límite.
- Cómo elegir el camino correcto, cuando te encuentras en una encrucijada en la vida
- ¿Qué debo saber antes de comenzar una carrera como especialista?
- ¿Cuál tiene un mejor futuro BSC (ag) en OUAT o BDS a través del AIPMT?
- ¿Cuáles son las diferentes opciones de carrera en el campo de comercio?
- ¿Por qué no puedo decidir un camino?
El principio aquí es que los errores en un módulo nunca deberían permitir que alguien haga algo que el módulo no debe hacer. Si un módulo está destinado a leer archivos, no debería haber nada que nadie pueda hacer, incluso si “rompen” el código, que puede resultar en escribir en un archivo. No debería haber privilegios innecesarios que harían innecesaria la escalada de privilegios. Idealmente, no debería haber privilegios que hagan posible la escalada de privilegios, pero eso no es algo de lo que sea fácil estar seguro.
Los sandboxes son una forma de implementar esto, pero existen otros métodos. A menudo, debido a las limitaciones en las implementaciones, terminas con una mezcla.
Además de estar escrito en dicho modelo, el software debe contener algunas características importantes.
El más importante de estos es la robusta E / S. Esto solo concierne a los módulos que se ocupan de interfaces fuera del sistema. Una vez que se garantiza la integridad allí, no debe haber implicaciones de seguridad para la comunicación interna. Fiabilidad e integridad de datos, pero no seguridad.
Las entradas deben ser validadas. Esto significa que todos los tipos de datos y rangos de valores deberían aplicarse, los caracteres no válidos deberían rechazarse y las estructuras de datos inexistentes deberían rechazarse. Los tokens de autenticación deben verificarse como válidos y apropiados para la entrada.
Las longitudes máximas del búfer deben aplicarse, los desbordamientos nunca deben aceptarse. Nunca se debe acceder al espacio de búfer no utilizado. Las instrucciones consideradas “inseguras” nunca deben usarse en esta parte del código. Puede haber problemas con el uso de comandos seguros en el programa, pero está bien porque los datos inseguros no pueden llegar allí.
La autenticación en sí misma debería ser una operación distinta. Involucra todo lo anterior, ya que involucra E / S, pero debe verificar en una base de datos que la autenticación es válida tanto en datos como (si está restringido) en el punto de origen, y debe crear una estructura de datos adecuada para representar al usuario y qué están autorizados para hacerlo. El acceso a la base de datos es demasiado lento para el uso general y siempre conlleva el potencial de acceso incorrecto para realizar lecturas o escrituras no autorizadas. Se debe acceder a los datos maestros con la menor frecuencia posible, una copia de trabajo es una solución más segura.
Para eliminar la información contextual que podría usarse para romper el cifrado, toda la comunicación debe cifrarse (nula si la ley lo prohíbe). En entornos seguros, como las instalaciones de DoD, esto es obligatorio por ley porque es el enfoque correcto. Si el cifrado no es posible / legal, estás atascado. Hacer que la autenticación sea segura no es adecuada, incluso las contraseñas seguras a menudo tienen una relación con el contexto. La detección de intrusiones se basa en que los ciberdelincuentes tienen el menor trabajo posible.
Ahora llegamos al círculo exterior, la ciberseguridad.
Esto cubre:
Cortafuegos (siempre bloquean exploradores de puertos, tráfico de sitios incluidos en listas negras, de sitios que sabe que nunca deberían conectarse a la red, a puertos que no desea exponer, de tipos que no deberían estar presentes y de hosts internos que no tienen comunicación comercial) con el mundo exterior) Tenga cuidado, algunos cortafuegos evitan el TCP de múltiples rutas, que absolutamente desea para la confiabilidad de la red. No todos los ataques tienen que ver con la intrusión, algunos tratan de obstruir las cosas. Cuanto más pueda difundir las cosas por Internet, menos se verá afectado por lo que a veces se llama Internet Weather.
Topología (los servidores que no necesitan ser alcanzados por el mundo exterior no deberían estar en un segmento que pueda ver el mundo exterior). La topología con conmutación por error es buena porque se reducen los problemas de congestión (maliciosos o no). Las redes a menudo tienen puntos de acceso y esas son vulnerabilidades.
Detección de intrusiones en la red (los escáneres activos deben ser mínimos para evitar falsos positivos, en paralelo para minimizar el impacto en la red y deben programar el firewall para bloquear conexiones hostiles automáticamente; los NIDS bayesianos que buscan un comportamiento anormal sin usar ningún patrón específico pueden ser buenos, pero YMMV – si el comportamiento es muy variable, puede que no sea lo que desea).
Host Intrusion Detection (esto cubre la detección de malware, detección de modificación de archivos, detección de escaneo de puertos, comportamiento anormal por usuario).
Controles de acceso obligatorios (hay muchos tipos, algunos de los cuales se pueden usar en combinación; diferentes tipos de situaciones necesitan diferentes configuraciones).
Controles de acceso discrecionales (sus permisos de archivo regulares).
(Nota: las listas de control de acceso POSIX pueden ser MAC o DAC, aunque, francamente, nunca he visto a nadie usarlas).
IPSec (túneles encriptados, siempre deben usarse para extranets, usuarios privilegiados fuera del sitio y comunicación entre empresas, todos los cuales deben usar túneles validados, preferiblemente basados en certificados; fue diseñado para conexiones ad-hoc a servidores autenticados, un genérico alternativa a SSL que no necesitaba cambios de software; es un buen uso y debería usarse más).
Captura de paquetes (si se trata de una red segura, no debería obtener información sin los certificados; los atacantes son muy capaces de usar rastreadores y la DMZ especialmente debería ser ininteligible).
DNSSec (sus servidores nunca deberían necesitar DNS externo, es un protocolo peligroso que está abierto a muchas vulnerabilidades; las máquinas cliente deben acceder a un servidor DNS seguro que use DNSSec para obtener datos confiables y agilizarlos).
BGP4 + (si se está conectando a una WAN, necesita BGP; si está usando BGP, evite el envenenamiento de la tabla del enrutador mediante el cifrado entre sistemas autenticados).
OSPF o ISIS (necesita un protocolo de enrutamiento interno, RIP no lo corta para topologías complejas, nuevamente debe protegerlo contra el envenenamiento de la tabla del enrutador, esto no es opcional).
Escáneres de vulnerabilidad (barre regularmente los sistemas para detectar fallas y puertos abiertos innecesarios).
Honeypots (máquinas virtuales diseñadas únicamente para atrapar y monitorear a los intrusos; solo son útiles si realmente están seguras contra la intrusión, no son útiles para procesar a nadie, ya que son trampas pero son muy útiles para detectar nuevos métodos de intrusión).
En Desarrollo de Software.
Una vez que haya validado a los usuarios, se haya asegurado de que las operaciones estén autorizadas, las entradas seleccionadas y las salidas no expongan información inesperada, el desarrollo de software no tiene nada más que ver con InfoSec. De aquí en adelante, es robustez y rendimiento.
Usted logra robustez al verificar los códigos de retorno de las operaciones que podrían causar un bloqueo del software, asegurándose de que las funciones sean válidas en todo el rango de entradas proporcionadas, nunca usando globales o efectos secundarios (efectos de una función que no sea a través de la interfaz de la función) y usando tipos de datos que sean lo más restrictivos posible.
Entonces, si pasa una función de raíz cuadrada a un tipo de datos con signo, es mejor que devuelva un número complejo. De lo contrario, no tiene por qué utilizar un tipo de datos firmado. Son datos realmente sin firmar o el software producirá basura o se bloqueará. Estos dos últimos no son particularmente deseables en software robusto.
Malloc es el problema secundario, ya que Linux y algunos otros sistemas operativos no verifican si la memoria está disponible y siempre devuelven EOK. Nunca puede confiar completamente en la memoria dinámica, ya que no tiene idea de cuánta memoria está disponible. Eso depende de lo que esté utilizando el mismo grupo de memoria, incluidos otros subprocesos si está utilizando LWP. Recomiendo usar un malloc de reemplazo que use un grupo de memoria preasignado y reservado. Será más rápido y seguro, aunque impone límites más estrictos a lo que puede colocar en el montón.
Los efectos secundarios y las variables globales dificultan la verificación de la corrección. Peor aún, en un programa multiproceso, no tienes idea de en qué orden se hacen las cosas. Al imponer límites rígidos alrededor de cada función, de modo que solo se muestre la interfaz, tienes un control mucho mayor sobre lo que está sucediendo.
Power of Ten tiene muchas buenas ideas como estilo de codificación. Definitivamente apruebo las funciones que se ajustan en una pantalla, evitando el anidamiento excesivo, etc. Esto ayuda a reducir los errores.
MISRA tiene algunas buenas ideas, pero también muchas malas. Eso sí, eso es cierto para la mayoría de los estándares. Lamentablemente, tratar de pasar por todos los estándares para extraer las partes sensibles no solo violaría los acuerdos, sino que también produciría Otro estándar incompatible con buenas ideas y malas ideas.
Fault Tolerance es la capacidad de un programa para continuar al detectar un error. Requiere algunas técnicas de recuperación muy buenas, todas las cuales hacen que el código sea imposible de validar de manera confiable por software. Dado que probablemente no desee errores en primer lugar, probablemente escribiría primero las funciones y luego haría tolerante a fallas aquellas funciones que no pueden validarse de todos modos.
Las máquinas de estado entran en este punto. El software puede considerarse como una transición de una máquina imaginaria de un estado a otro. Los errores ocurren cuando intenta ingresar a un estado que no está allí. Es una puerta al borde de un precipicio. La recuperación es tu paracaídas / traje de alas, pero solo es útil si funciona. Su recuperación debe pasar de este estado desconocido e inválido a no solo un estado válido, sino al siguiente estado válido en el que el sistema esperaba estar.
Eso es realmente un gran desafío, pero ¿de qué sirve un controlador de excepciones que genera errores y excepciones? Corre el riesgo de obtener una distorsión acumulativa del estado y eso es mucho peor que estrellarse.
Hay dos opciones Primero, puede considerar la acción como una transacción y simplemente regresar a un punto seguro, como justo antes de obtener la información que produjo la acción con errores. Perfectamente buen método. A veces esto se llama Intolerancia a fallas, ya que a menudo se implementa como un controlador diseñado para bloquearse por error y solo confirmar cambios al finalizar. No está atrapando la falla, está matando el proceso que contiene la falla.
La segunda opción es tener un valor válido para cualquier parte del estado que represente lo desconocido. Las operaciones en un valor desconocido siempre deben dar como resultado ningún cambio en ese valor. Las incógnitas que modifican un conocido no deberían producir ningún cambio si eso es razonable; de lo contrario, el valor se vuelve desconocido. No sabe cuál debería ser el estado, los datos subsiguientes solucionarán el problema, así que contenga el error y procese lo que pueda. Esto a veces se hace con software en tiempo real cuando también debe ser tolerante con la mala recopilación de datos.
Esto no suele hacerse en aplicaciones, pero es un enfoque para el modo de espera activa por canal. Si varias entradas van a una salida, sobrescribir un valor consigo mismo no daña nada e ignorar los valores de error tampoco daña nada. Entonces, si está recolectando de múltiples sensores más redundantes, los sensores pueden fallar en cualquier momento sin corrupción de lo que recolecta y sin tiempo de cambio.