Metodologia de Programacion segura

La metodología para la programación segura es un suplemento de la metodología de seguridad OSSTMM (Open Source Security Testing Methodology Manual) que facilita una serie de estándares en vistas al desarrollo de código que deberá encontrarse accesible en Internet. Por tanto se parte desde un principio con la idea de que este código debe estar preparado para sobrevivir en un entorno altamente hostil.

El desarrollo de un programa que resuelva un problema dado es una tarea compleja, ya que es necesario tener en cuenta de manera simultánea muchos elementos. Por lo tanto, es indispensable usar una metodología de programación.

Una metodología de programación es un conjunto o sistema de métodos, principios y reglas que permiten enfrentar de manera sistemática el desarrollo de un programa que resuelve un problema algorítmico. Estas metodologías generalmente se estructuran como una secuencia de pasos que parten de la definición del problema y culminan con un programa que lo resuelve.

A continuación se presenta de manera general los pasos de una metodología:

El Diálogo: Con la cual se busca comprender totalmente el problema a resolver.

La Especificación: Con la cual se establece de manera precisa las entradas, salidas y las condiciones que deben cumplir.

Diseño: En esta etapa se construye un algoritmo que cumpla con la especificación.

Codificación: Se traduce el algoritmo a un lenguaje de programación.

Prueba y Verificación: Se realizan pruebas del programa implementado para determinar su validez en la resolución del problema.

La programación segura es una rama de la programación que estudia la seguridad del código fuente de un software cuyo objetivo es encontrar y solucionar los errores de software, esto incluye: Utilización de funciones seguras para proteger de desbordamientos de pila, declaración segura de estructuras de datos, control del trabajo con el flujo de datos, análisis profundo de otros errores de software mediante testeos del software en ejecución y creación de parches para los mismos, diseño de parches heurísticos y metaheurísticos para proveer un cierto grado de seguridad proactiva, utilización de criptografía y otros métodos para evitar que el software sea crackeado.

La programación defensiva es algunas veces referida como programación segura por los científicos de computación los cuales ubican este enfoque minimizando errores de software.

Técnicas de programación defensiva

Aquí están algunas técnicas de programación defensiva sugeridas por algunos de los científicos líderes de computación para evitar crear problemas de seguridad y errores de software. Estos científicos afirman que aunque este proceso pueda mejorar la calidad el código, no es suficiente para asegurar la seguridad.

Reducir complejidad del código fuente: Nunca hacer el código más complejo que lo necesario. La complejidad genera bugs, incluyendo problemas de seguridad. Esta meta pude tener conflicto con el objetivo de escribir programas que puedan recuperarse de cualquier error y manejar cualquier entrada de datos. Manejar todas las ocurrencias inesperadas en un programa requiere que el programador adicione código extra, el cual pudiera también tener bugs.

Revisiones del código fuente: Una revisión de código es donde alguien diferente al autor original realiza una auditoría de código. Una auditoría de código hecha por el mismo creador es insuficiente. La auditoría la debe hacer alguien que no sea el autor, como cuando se escribe un libro, debe ser revisado por alguien que no sea el autor.Simplemente haciendo el código disponible para que otros lo lean (software libre) es insuficiente, pues no hay garantía que el código sea efectivamente revisado, no dejando que sea rigurosamente revisado.

Pruebas de software: Las pruebas de software deberán ser para tanto que el software trabaje como debe, como cuando se supone que pase si se realice deliberadamente malas entradas. Las herramientas de prueba pueden capturar entradas de teclado asociadas con operaciones normales. Luego las cadenas de texto de estas entradas capturadas pueden ser copiadas y editadas para ensayar todas las permutaciones y combinaciones, luego ampliarlas para tests posteriores después de cualquier modificación-. Los defensores de la clave de registro afirman que los programadores que usan este método deberán asegurar que las personas a las cuales se les están capturando las entradas estén al tanto de esto, y con que propósito?, para evitar acusaciones de violación de privacidad .

Reutilización inteligente del código fuente: Si es posible, reutilizar código. La idea es capturar beneficios de un bien escrito y bien probado código fuente, en vez de crear bugs innecesarios. Sin embargo, reutilizar código no siempre es la mejor manera de progresar, particularmente cuando la lógica del negocio esta involucrada. Reutilizar en este caso puede causar serios bugs en los procesos de negocio.

Los problemas de legado: Antes de reutilizar viejo código fuente, bibliotecas, APIs, configuración y demás, debe ser considerado si el trabajo anterior es válido para reutilizar, o si es propenso a problemas de legado.Los problemas de legado son problemas inherentes cuando se espera que viejos diseños trabajen con los requerimientos actuales, especialmente cuando estos viejos diseños no fueron desarrollados o probados con estos requerimientos en mente.

Entrada segura / manejo de la salida: Los crackers tienden a inventar nuevos tipos de representaciones de datos incorrectasPor ejemplo, si se revisa si un archivo pedido o es “/etc/passwd”, un cracker puede pasar otra variante de este nombre de archivo como “/etc/,/passwd” Para evitar bugs debido a entradas no adecuadas, emplear los Canonicalization API’s

Principio del menor privilegio:

Emplear el principio del menor privilegio, Evitar tener software corriendo en un modo privilegiado:

Nunca hacer programas UNIX setuid a menos que se este realmente seguro que se esta protegiendo la seguridad.

Nunca hacer programas de Windows correr como servicios de sistema local a menos que se este realmente seguro que se está protegiendo la seguridad.

No conceder más permisos que los necesarios a grandes grupos de usuarios o público/cualquiera.

No conceder más permisos que los necesarios a grupos pequeños de usuarios o usuarios específicos.

Preferir conceder permisos a grupos pequeños de usuarios o usuarios específico, en vez de concederlos a grandes grupos de usuarios o público/cualquiera. Es mejor que unos pocos usuarios tengan mas permisos, que muchos usuarios tengan mayor permiso.

Baja tolerancia contra errores potenciales: Asumir que el código construido que parece ser propenso a problemas (similares a conocidas vulnerabilidades, etc), son errores (bugs) o potenciales fallos de seguridad. La regla básica es: “No estoy al tanto de todos los tipos de explotaciones de seguridad” Debo proteger en contra de lo que conozco y así tengo que ser proactivo”

Fuente: JOrgelinaGomez

Comentarios

Entradas populares de este blog

Descienden las detecciones de malware en Android y crecen en iOS

Explotan el día cero de la VPN de Fortinet para robar credenciales

Microsoft dice que la interrupción masiva de Azure fue causada por un ataque DDoS