Secure Code

La Necesidad de Sistemas Seguros

• Un producto seguro: un producto que protege la confidencialidad, integridad y disponibilidad de la información de los clientes, y la integridad y la disponibilidad de recursos de procesamiento, bajo el control del propietario del sistema o de administrador.

• Una vulnerabilidad de seguridad: una falla en un producto que hace que sea inviable, incluso cuando se utiliza el producto adecuadamente, para evitar que un atacante usurpar privilegios en el sistema del usuario, que regula su funcionamiento, poniendo en peligro los datos en él, o de asumir la confianza sin permitirla.

Secure Code

A medida que Internet crece en importancia, las aplicaciones se están convirtiendo en muy interconectadas. En los "buenos viejos tiempos", las computadoras eran usualmente islas de funcionalidad. En aquellos días, no importaba si su aplicación era insegura, lo peor que podría hacer era atacar te a ti mismo, y siempre y cuando una aplicación realiza su tarea con éxito, la mayoría de la gente no se preocupa por la seguridad.

Los tiempos han cambiado. En la era de Internet, prácticamente todos los ordenadores servidores, computadoras personales de escritorio, y, más recientemente, teléfonos celulares, dispositivos de bolsillo y otros dispositivos de factor de forma, como el PC Auto e integrados sistemas están interconectados.

Secure Code

El punto está hecho: los ataques pasan. Algunos atacantes están altamente cualificados y muy inteligente. Tienen un conocimiento profundo y amplio de las computadoras. Ellos tienen el tiempo y la energía para investigar y analizar las aplicaciones informáticas para las vulnerabilidades de seguridad. Los mejores white-hats trabajan de cerca con los proveedores de software, como Microsoft, para descubrir y remediar problemas de seguridad graves previas al proveedor emitir un boletín de seguridad que obliga al usuario a tomar medidas mitigación, tales como la aplicación de una solución de software o cambiar un ajuste. Este enfoque ayuda a evitar que la comunidad de Internet de ser dejado sin defensa si el fallo de seguridad se descubrió por primera vez por los vándalos que montan ataques generalizados.

Secure Code

Muchos atacantes son vándalos simplemente tontos; se les llama script kiddies. Script kiddies tienen poco conocimiento de la seguridad y pueden atacar sistemas inseguros solamente usando scripts escritos por los atacantes con más conocimientos que se encuentran, de documentos, y escribir código de explotación de los errores de seguridad que encuentran. Un exploit (a menudo llamado un Sploit) es una manera de irrumpir en un sistema.

Secure Code

Los usuarios finales demandan aplicaciones que funcionan como se anuncia y la forma en que ellos esperan cada vez que les lanzan. Los usuarios no quieren que su información de tarjeta de crédito esté publicada en Internet, no quieren que sus datos médicos sean hackeado, y ellos no quieren que sus sistemas sea infectados por virus. Los dos primeros ejemplos conducen a problemas de privacidad para el usuario, y los último conduce a tiempos de inactividad y la pérdida de datos. Es su trabajo para crear aplicaciones que ayudan a sus usuarios a obtener el máximo provecho de sus sistemas informáticos, sin temor a la pérdida de datos o la invasión de la privacidad.

La seguridad es una prioridad

Esta tiene que ser una sentencia corporativa, ya que, como hemos visto, la necesidad de enviar software seguro es mayor que nunca. Los usuarios exigen que se construye aplicaciones seguras que vea este tipo de sistemas como un derecho, no un privilegio. Además, la fuerza de ventas de su competidor le susurran a sus clientes potenciales que su código es arriesgado y peligroso. Así que ¿por dónde empezar infundir seguridad en su organización? El mejor lugar es en la parte superior, que puede ser un trabajo duro. Es difícil porque tendrá que demostrar un impacto la línea de fondo a su empresa, y la seguridad es generalmente considerado como algo que "se interpone en el camino" y cuesta dinero al tiempo que ofrece poco o ningún retorno financiero.

Proceso de Desarrollo

Estimación del $ en el Proceso de Desarrollo

Es difícil determinar el costo en dólares para una solución porque hay muchos intangibles, pero el precio de hacer uno incluye lo siguiente:

• El costo de la coordinación solución. 

• El costo de los probadores de prueba la corrección.

• El costo de la prueba de la configuración de la solución.

• El costo de crear y probar las versiones internacionales.

• El costo de la pérdida de productividad. 

• El costo para sus clientes a aplicar la corrección. 

• Por último, el costo potencial de la pérdida de ingresos, de probables clientes la decisión de posponer o dejar de usar su producto.

El mundo de la defensa no es agradable

El mundo de la defensa

El mundo de la defensa no es agradable. Como defensores, los desarrolladores de software deben crear aplicaciones y soluciones que son constantemente vigiladas, pero los atacantes siempre derrotaran al software inseguro. En resumen, tenemos que trabajar con más inteligencia para derrotar a los atacantes. George Mallory (1886-1924) responde a la pregunta, "¿Por qué quieres escalar el monte Everest?": "Porque está ahí". Sin embargo, podemos subir el listón considerablemente, hasta el punto en que los atacantes encontrarán software más difíciles de atacar y utilizar sus habilidades para otros fines.

El Goal

Seguridad Proactiva

Veamos primero algunas de las razones por las cuales la gente elige no construir sistemas seguros y por qué muchas personas perfectamente inteligentes cometen errores de seguridad. Algunas de las razones son las siguientes:

• La seguridad es aburrido.

• Seguridad es a menudo visto como un neutralizador por funcionalidad, como algo que se interpone en el camino.

• La seguridad es difícil de medir.

• Por lo general de Seguridad no es la habilidad principal o intereses de los diseñadores y desarrolladores que crean el producto.

• Seguridad significa no hacer algo emocionante y nuevo.

Seguridad Proactiva

Seguridad Proactiva

La seguridad es muy importante y trabajar en la parte de seguridad se deberían tomar muchos aspectos, al momento de desarrollar una solución se deben tomar en cuenta evaluar la siguiente lista de preguntas:

• ¿Quién es la audiencia de la aplicación?

• ¿Qué estás intentando proteger?

• ¿Quién se encargará de la aplicación? El usuario o un administrador de TI de las empresas?

• ¿Cuáles son las necesidades de comunicación del producto? Es el producto interno a la organización o externo, o ambos?

• ¿Qué seguridad servicios de infraestructura de hacer el sistema operativo y el entorno ya proporciona que puede aprovechar?

• ¿Cómo qué necesita el usuario para protegerse de sus propias acciones?

Principios de Seguridad

Principios de Seguridad

La seguridad en las aplicaciones debe ser diseñado y construido en sus soluciones desde el principio. Si un sistema es seguro por diseño, significa que ha tomado las medidas apropiadas para asegurarse de que el diseño global del producto es sólido desde el principio. Los pasos que recomiendan los grupos de desarrollo toman para lograr esto incluyen los siguientes:

• Asigne un "ir a persona" para sus problemas de seguridad. 

• Exigir la capacitación para todo el personal. 

• Hacer modelos de amenazas estén en su lugar para el momento en la fase de diseño se ha completado. 

• Adherirse a diseñar y directrices de codificación. 

• Corregir todos los errores que se desvían de las directrices tan pronto como sea posible. 

• Asegúrese de que las directrices evolucionen. 

• Desarrollar pruebas de regresión para todas las vulnerabilidades previamente fijados. 

• Simplificar el código y simplificar su modelo de seguridad.

Principios de Seguridad

La seguridad no es algo que pueda ser aislado en una determinada área del código. Al igual que el rendimiento, la escalabilidad, capacidad de administración y la legibilidad del código, la seguridad es una disciplina que cada diseñador de software, desarrollador, y el probador tiene que conocer. El proceso de desarrollo de sonido, que de hecho puede construir sistemas seguros:

• Aprender de los errores

• Minimice su superficie de ataque

• Utilice la defensa en profundidad

• Utilice privilegios mínimos

• Emplear impagos seguras

• Recuerda que la compatibilidad hacia atrás siempre le dará pena

• Suponga sistemas externos son inseguros

• Plan en la insuficiencia

• Dejar de un modo seguro

• Recuerde que las Características de seguridad != Características seguras

• Nunca dependa de seguridad por oscuridad solo

• No mezclar código y datos

• Solucionar los problemas de seguridad correctamente

La Saturación del Buffer

La saturación del Buffer

La saturación del Buffer

Miles de administradores de sistemas tienen que poner en horas adicionales para aplicar el parche. Los administradores de seguridad tienen que encontrar una manera de identificar los sistemas que faltan los parches y notificar a los propietarios de los sistemas. Lo peor de todo, algunos clientes se van a poner sus sistemas comprometidos por los atacantes. El costo de un solo compromiso puede ser astronómicos, dependiendo de si el atacante es capaz de infiltrarse, además, un sistema y acceder a información valiosa, como números de tarjetas de crédito. Un error descuidado de su parte puede terminar costando millones de dólares, sin contar con que la gente de todo el mundo van a decir cosas malas sobre ti. Va a pagar por sus pecados si usted causa tanta miseria. Las consecuencias son, evidentemente, graves; Todo el mundo comete errores, pero algunos errores puede tener un gran impacto.

La saturación del Buffer

Los desbordamientos de búfer son responsables de muchos errores de seguridad altamente perjudiciales. Algunas de las funciones de manejo de cadenas, más comunes y cómo estas funciones contribuyen al código no seguro. Algunas soluciones también se presentan-adecuado uso de las clases de cuerda o la Strsafe.h pueden ayudar a que su código sea más robusta y confiable. Por último, siempre vale la pena entender las limitaciones de sus herramientas. Stack-comprobando opciones del compilador ofrecen una red de seguridad, pero no son un sustituto de la escritura sólida, código de seguridad en el primer lugar.

Control de Acceso Apropiado

Control de Acceso Apropiado

La determinación de los requisitos de control de acceso es tan simple como escribir el control de acceso a las reglas de nuevo, basado en las reglas de negocio para la aplicación y luego en busca de verbos y sustantivos en los requisitos. A continuación, puede determinar qué tecnologías de control de acceso son apropiadas y cómo configurar los mecanismos para cumplir con la política de control de acceso.

Control de Acceso Apropiado

Ejemplo: Entrevistas con el cliente revelan el siguiente escenario cuando un médico actualiza los registros médicos del paciente: Tras la consulta, el médico busca, lee, y luego actualiza la información médica del paciente con los nuevos hallazgos, y una entrada de auditoría se escribe en el registro de auditoría. Enfermeras, cobran enfermeras y los médicos pueden leer récord medicina de un paciente, y cargar las enfermeras y los médicos pueden actualizar medicamentos del paciente. Cualquier acceso a los medicamentos del paciente también es auditada. Solamente los auditores pueden leer el registro de auditoría, y los médicos nunca deben ser auditores y por lo tanto nunca se deben leer desde el registro ni actualizar el registro.

Control de Acceso Apropiado

Se determina en este caso que buscar es lo mismo que leer . De esto deriva la siguiente política de acceso de los datos del paciente:

• Los médicos (Read, Update) 

La siguiente es la política de acceso para los datos de la medicina del paciente:

• Los médicos (Read, Update)

• Enfermeras de carga (Read, Update)

• Enfermeras (Leer)

Y la siguiente política de acceso se deriva para el registro de auditoría:

• Los médicos (Denegar Read, Deny Update)

• Cuentas (All Access)

• Todo el mundo (escritura)

Protección de datos secretos

Protección de datos secretos

Protección de datos secretos

El almacenamiento de información-datos secretos como claves de cifrado, claves de firma y contraseñas en el software de una manera completamente segura es imposible con el hardware de PC actual. Una persona con una cuenta de suficientes privilegios en el equipo o alguien con acceso físico a la computadora puede acceder fácilmente a los datos. Almacenamiento de información secreta de forma segura en el software también es difícil de hacer, y por lo tanto es generalmente desalentada. A veces, sin embargo, debe, por lo que este capítulo va a ayudar a hacerlo. El truco consiste en elevar el nivel de seguridad lo suficientemente alto como para que sea muy difícil para alguien que no sea usuarios adecuados para acceder a los datos secretos.

Divulgación de Información

Protección de datos secretos

Los datos Secreto son susceptibles a dos amenazas principales: la divulgación de la información y la manipulación.Otras amenazas se hacen evidentes en función de la naturaleza de los datos comprometidos. Por ejemplo, si la contraseña de Blake se da a conocer a un usuario malicioso, la contraseña puede ser reproducido por el atacante para suplantar la identidad de Blake. Por lo tanto, en este ejemplo, una amenaza de divulgación de información se convierte en una amenaza de suplantación.

¿Dónde almacenar la clave de cifrado? En el registro? ¿Cómo almacenar y proteger esa llave?

Protección de datos secretos

Si guarda un secreto con el fin de verificar que otra entidad también conoce el secreto, es probable que no necesita almacenar el propio secreto. En su lugar, se puede almacenar un verificador , que a menudo toma la forma de un hash criptográfico del secreto. Por ejemplo, si una aplicación necesita para verificar que un usuario conoce la contraseña, puede comparar el hash del secreto introducida por el usuario con el hash del secreto guardado por la aplicación. En este caso, el secreto no es almacenada por la aplicación de sólo el hash se almacena. Esto presenta menos riesgo porque incluso si el sistema se ve comprometida, el propio secreto no puede ser recuperada (que no sea por la fuerza bruta) y sólo se puede acceder a el hash.

https://www.hackerearth.com/notes/hashing/?utm_source=facebook-event&utm_medium=cm-notes&utm_campaign=cm-hashing

Protección de datos secretos

La manera más segura de almacenar y proteger los secretos es conseguir que el secreto de un usuario cada vez que se utiliza el secreto. En otras palabras, si usted necesita una contraseña del usuario, obtener de usuario, usarlo, y lo descarta. Sin embargo, el uso de datos secretos de esta manera a menudo puede llegar a ser inviable para la mayoría de usuarios. Cuantos más elementos de información que realice un usuario recuerde, mayor es la probabilidad de que el usuario empleará la misma contraseña una y otra vez, la reducción de la seguridad y la facilidad de uso del sistema.

Protección de datos secretos

Almacenamiento de la información secreta de forma segura en el software es una tarea difícil de lograr. De hecho, es imposible alcanzar la perfección con la tecnología actual. Para reducir el riesgo de comprometer la información secreta, asegúrese de tomar ventaja de la funcionalidad de seguridad del sistema operativo y también asegurarse de almacenar información secreta sólo si usted no tiene que hacerlo. Si no guarda secretos, no pueden verse comprometidos. Determine un "suficientemente bueno" solución basada únicamente en la amenazas y los datos de sensibilidad.

Todas las entradas son malvadas!

Entradas Malvadas!

Si alguien que no sabía llegó a su puerta y le ofreció algo de comer, ¿te lo comen? No, por supuesto que no.Entonces, ¿por qué tantas aplicaciones aceptan datos de extraños sin antes evaluarla? Es seguro decir que la mayoría de los exploits de seguridad implican la aplicación de destino de comprobar de forma incorrecta los datos de entrada o, en algunos casos, no en todos. Así que permítanme ser claro en esto: usted no debe confiar en los datos hasta que se valida los datos. De no hacerlo, hará que su aplicación vulnerable. O, dicho de otra manera: todas las entradas es malo hasta que se demuestre lo contrario. Esa es la regla número uno. Por lo general, el momento en que se olvida esta regla es el momento en que es atacado.

Entradas Malvadas!

Regla número dos es: Los datos deben ser validados cuando cruza la frontera entre entornos no confiables y de confianza Por definición, los datos de confianza es que los datos o una entidad que de manera explícita la confianza tiene completo control sobre; los datos no son de confianza se refiere a todo lo demás. En resumen, los datos presentados por un usuario es inicialmente de datos no es de confianza.

Entradas Malvadas!

No busque los datos "malos" en la solicitud. Usted debe buscar buenos datos, bien formados y rechazar la solicitud si los datos no cumple sus criterios de aceptación. Recuerde: usted escribió el código para acceder y manipular sus recursos; usted sabe lo que constituye una solicitud correcta. Usted no puede saber todas las posibles solicitudes no válidas, y eso es una de las razones que usted debe buscar sólo para datos válidos. La lista de solicitudes correctas es finito, y la lista de solicitudes no válidas es potencialmente infinito o, al menos, muy, muy grande.

Conclusión