Mostrando entradas con la etiqueta Unidad 4. Mostrar todas las entradas
Mostrando entradas con la etiqueta Unidad 4. Mostrar todas las entradas

sábado, 28 de mayo de 2016

3.7 DISEÑO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL

El software de tiempo real está muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema.
Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseño del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las características del sistema operativo, por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño.
Globalmente, un sistema de tiempo real enfrenta al ingeniero de sistemas con difíciles decisiones sobre el software. Una vez que el elemento software ha sido asignado, se establecen los requisitos detallados del software y debe desarrollarse un diseño fundamental de software.
Cada diseño de tiempo real relativo al software debe ser aplicado en el contexto del rendimiento de sistema. En la mayoría de los casos, el rendimiento de un sistema de tiempo real se mide con una o más características relativas al tiempo, pero también se utilizan otras medidas, tales como la tolerancia al fallo.

Tipos de sistemas de tiempo real
Un sistema de tiempo real blando (soft) es un sistema cuyo funcionamiento se degrada si los resultados no se producen de acuerdo con los requerimientos temporales especificados. Un sistema de tiempo real duro (hard) es un sistema cuyo funcionamiento es incorrecto si los resultados no se producen de acuerdo con la especificación temporal.
Una respuesta a tiempo es un factor importante en todos los sistemas, pero en algunos casos, no necesita una respuesta rápida. Por ejemplo, el sistema de bombeo de insulina es un sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de glucosa a intervalos periódicos no es necesario responder muy rápidamente a los eventos externos.

Estimulos en sistemas de tiempo real
Una forma de ver un sistema de tiempo real es como un sistema de estímulo/respuesta. Dando un determinado estimulo de entrada, el sistema debe producir la correspondiente salida. Se puede, por lo tanto, definir el comportamiento de un sistema de tiempo real haciendo una lista de los estímulos recibidos por el sistema, las respuestas asociadas y el tiempo en que dichas respuestas deben producirse.
Los estímulos pueden pertenecer a dos clases:
  • Estímulos periódicos. Ocurren a intervalos de tiempo predecibles. Por ejemplo, si el sistema debe examinar un sensor cada 50 milisegundos y realizar una acción (respuesta) dependiendo del valor de ese sensor (estímulo).
  • Estímulos aperiódicos. Ocurren de forma regular. Normalmente son provocados utilizando el mecanismo de interrupciones de la computadora. Un ejemplo de dicho estímulo podría ser una interrupción para indicar que una transferencia de E/S se ha completado y que los datos están disponibles en el búfer.

Los estímulos periódicos en un sistema de tiempo real son generados normalmente por sensores asociados al sistema. Estos proporcionan información sobre el estado del entorno del sistema. Las respuestas son dirigidas a un conjunto de actuadores que controlan algún equipo como una bomba, que influye en el entorno del sistema.
Los estímulos aperiódicos pueden generarse por actuadores o por sensores. A menudo indican alguna condición excepcional como un fallo en el hardware, que debe ser manejado por el sistema. Este modelo sensor-sistema actuador de un sistema de tiempo real embebido.

Un sistema de tiempo real tiene que responder a estímulos que ocurren en diferentes instantes de tiempo. Por lo tanto, se tiene que organizar su arquitectura para que, tan pronto como se reciba un estímulo, el control sea transferido al manejador adecuado. Esto no es práctico en programas secuenciales. Por consiguiente, los sistemas de tiempo real se diseñan como un conjunto de procesos concurrentes que cooperan entre sí. Con el objetivo de soportar la gestión de estos procesos, la plataforma de ejecución para la mayoría de los sistemas de tiempo real incluye un sistema operativo de tiempo real. Las facilidades que proporciona este sistema operativo son accedidas a través  del sistema de soporten tiempo de ejecución (run-time system) para el lenguaje de programación de tiempo real utilizado.


Bibliografía:

Cartman, E. (28 de Mayo de 2016). cartmanese.wordpress.com. Obtenido de https://cartmanese.wordpress.com/diseo-y-arquitectura-de-productos-de-software/

Cervantes Ramírez, Á. M. (28 de Mayo de 2016). Openboxer. Obtenido de http://www.openboxer.260mb.com/pdf/is/apuntesIngSW.pdf?ckattempt=1

4.4 INGENIERÍA DE SEGURIDAD

La Ingeniería de la seguridad es una rama de la ingeniería, que usa todo tipo de ciencias para desarrollar los procesos y diseños en cuanto a las características de seguridad, controles y sistemas de seguridad. La principal motivación de esta ingeniería ha de ser el dar soporte de tal manera que impidan comportamientos malintencionados.

El campo de esta ingeniería puede ser muy amplio, podría desarrollarse en muchas técnicas:
  • Equipos: Como el diseño de cerraduras, cámaras, sensores,...
  • Procesos: políticas de control, procedimientos de acceso,...
  • Informático: control de passwords, criptografía,...

Un sistema puede tener mecanismos criptográficos que sean considerados completamente seguros pero puede adolecer de debilidades que hagan que sea necesario atacar al sistema criptográfico.
Ejemplos de esto son:
  • Sistemas que fallan debido a problemas en el código, como en la mayoría de los ataques conocidos como de “buffer overflow”, en los cuales el no considerar aspectos de excepción asociados a los sistemas pueden representar que un atacante suficientemente hábil pueda asumir funciones del administrador. Si en un determinado sistema alguien asume las funciones del administrador puede tener muy fácil acceso a claves y sistemas criptográficos haciendo inútil la fortaleza del sistema criptográfico que lo protege.
  • Algunos ataques aprovechan fallas de diseño en los sistema. Si una determinada aplicación ejecuta sin evaluar un determinado comando, los atacantes del sistema pueden conseguir información vital sin necesidad de romper las claves criptográficas que lo protegen. 
  • La existencia de sistemas de comunicación móvil, basados en transmisión inalámbrica facilita actividades de fisgoneo en la señal.
  • Algunas veces lo que se conoce como ataques de ingeniería social pueden resultar muy efectivos a la hora de atacar sistema supuestamente seguros.
  • El sistema de doble registro, ancestralmente usado para proteger sistemas de seguridad se ve violentado por sistemas “que obligan” al cuadre entre cuentas lo cual facilita el ataque a sistemas de esta naturaleza.


4.3 CONFIABILIDAD DEL SOFTWARE



La  confiabilidad  de  software  significa  que  un  programa  particular  debe  de  seguir  funcionando  en  la presencia  de  errores.  Los  errores  pueden  ser  relacionados  al  diseño,  a  la  implementación,  a  la programación, o el uso de errores.
Así como los sistemas llegan a ser cada vez más complejos, aumenta la probabilidad  de  errores.

Las organizaciones que desarrollan productos basados en software requieren de prácticas efectivas que permitan mejorar la calidad del producto. La Ingeniería de la Confiabilidad de Software es una práctica cuantitativa que puede ser implementada en organizaciones de cualquier tamaño bajo distintos modelos de desarrollo.


La calidad, las fallas y la confiabilidad de Software
La calidad es un atributo percibido por los usuarios o clientes de cualquier producto o servicio. En el caso de productos basados en software, la percepción de la calidad está en función de las fallas que el cliente percibe del mismo durante su operación.
La confiabilidad es un atributo que mide el grado en que un producto opera sin fallas bajo condiciones establecidas por un periodo de tiempo determinado. La confiabilidad es un atributo cuantitativo que ha sido ampliamente analizado, estudiado y usado en otras industrias para caracterizar la calidad de los productos o servicios.
Una falla es la manifestación percibida por el cliente de que algo no funciona correctamente e impacta su percepción de la calidad. Un defecto es el problema en el producto de software que genera una falla.
  • Se dice que un Software es confiable si realiza lo que el usuario desea, cuando así lo requiera.
  • No es confiable si así no lo hiciera.  A nuestros fines un Software no es Confiable cuando falla.
  • Las fallas se deben a errores en el Software.  Si corregimos estos errores sin introducir nuevos, mejoramos la Confiabilidad del Software.

4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones propias para su gestión de negocio. Como todo software, estas aplicaciones pueden contener fallas de seguridad y a diferencia del software comercial, no se dispone de actualizaciones o parches liberados en forma periódica por el fabricante. El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte de la organización que las desarrolla.

Por lo general, en el mejor de los casos, se coordina un testeo de seguridad una vez que la aplicación ya está desarrollada. Aquí muchas veces se encuentran errores que requieren el rediseño de parte de la aplicación, lo cual implica un costo adicional en tiempo y esfuerzo.


Seguridad en el análisis de requerimientos
En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrán impacto en  los aspectos de seguridad de  la aplicación. Algunos de ellos son: requerimientos de compliance con normativas locales o internacionales (ej: PCI, SOX, “A” 4609, etc.), tipo de información que se transmitirá o procesará (ej: Información pública o confidencial, datos personales, datos financieros, contraseñas, datos de pago electrónico, etc.) y requerimientos de registros de auditoría (ej: Qué debe registrar la aplicación en sus Logs).

Seguridad en el diseño
Antes de comenzar a escribir líneas de código, hay numerosos  aspectos de seguridad que deben ser tenidos en cuenta durante el diseño de la aplicación.
Algunos de ellos son:  Diseño de autorización (ej: Definir los roles, permisos y privilegios de la aplicación), diseño de autenticación (aquí se debe diseñar el modo en el que los usuarios se van a autenticar, contemplando aspectos tales como los mecanismos o factores de autenticación con contraseñas, tokens, certifcados, etc. posibilidades de integrar la autenticación con servicios externos como LDAP, Radius o Active Directory y los mecanismos que tendrá la aplicación para evitar ataques de diccionario o de fuerza bruta (ej: bloqueo de cuentas, implementación de “captchas”, etc.), diseño de los mensajes de error y advertencia, para evitar que los mismos brinden demasiada información y que ésta sea utilizada por atacantes y diseño de los mecanismos de protección de datos (aquí se debe contemplar el modo en el que se protegerá la información sensible en tránsito o almacenada; según el caso, se puede definir la implementación de encriptación, hashes o truncamiento de la información).


Seguridad en la codificación
Una vez concluido el diseño, le toca a los desarrolladores el turno de codificar los distintos componentes de la aplicación. Es en este punto en donde suelen incorporarse, por error u omisión, distintos tipos de vulnerabilidades. Estas vulnerabilidades podríamos dividirlas en dos grandes grupos a saber: vulnerabilidades clásicas y vulnerabilidades funcionales. Las primeras son bien conocidas y categorizadas.

En la etapa de codificación, una de las reglas de oro es verificar todos los valores de entrada y de salida. Esto es, asumir siempre que el valor pudo haber sido manipulado o ingresado maliciosamente antes de ser procesado. 



4.1 SEGURIDAD DE SOFTWARE

El concepto de la seguridad en los sistemas de software es un área de investigación que ha pasado a ser vital dentro de la Ingeniería de Software. Con el crecimiento de Internet, y otras aplicaciones sobre redes, como el comercio electrónico, correo electrónico, etc., la posibilidad de ataques se ha incrementado notablemente, como también lo han hecho las consecuencias negativas de estos ataques.
En la actualidad prácticamente todo sistema debe incorporar cuestiones de seguridad para defenderse de ataques maliciosos. El desarrollador ya no sólo debe concentrarse únicamente en los usuarios y sus requerimientos, sino también en los posibles atacantes.
Esto ha motivado cambios importantes en el proceso de diseño y desarrollo de software para incorporar a la seguridad dentro de los requerimientos críticos del sistema.

Estos cambios son los primeros pasos en la concientización de los ingenieros de software acerca de la importancia de obtener un software seguro. Como todo gran cambio, no se logra de un día para otro, sino que es un proceso gradual que requiere tiempo y maduración. Todavía la Ingeniería de Software no ha dado una respuesta eficaz, coherente y aplicable que satisfaga plenamente a la comunidad informática, sino que las aproximaciones actuales están plagadas de fallas y debilidades fruto de que todavía es un proceso que se encuentra en su infancia.

Tipos de software de seguridad
Sin duda, el tipo de software de seguridad más conocido son los programas antivirus, que se encargan de detectar y eliminar virus informáticos. Un buen programa antivirus dispone de un archivo de firmas de virus que se actualiza automáticamente y detecta virus nuevos. Este tipo de actualización se realiza periódicamente, varias veces al día.
El software de seguridad suele venderse en las denominadas suites. Son paquetes compuestos de:
  • Programa antivirus
  • Cortafuegos
  • Filtro antispam
  • Software para filtrar contenidos
  • Software contra publicidad no deseada
  • Control de sitios web

Actualmente, la seguridad es un concepto que todo sistema debe incorporar.  La Ingeniería del Software todavía no es capaz de brindar un mecanismo para implementar adecuadamente la seguridad: los lenguajes tienen primitivas inseguras, el código relativo a la seguridad es siempre un código confuso y complejo debido a técnicas de abstracción insuficientes, etc.

UNIDAD 4 SEGURIDAD EN INGENIERÍA DE SOFTWARE

La seguridad de software aplica los principios de la seguridad de información al desarrollo de software. Information security (La seguridad de información) se refiere a la seguridad de información comúnmente como la protección de sistemas de información contra el acceso desautorizado o la modificación de información, si está en una fase de almacenamiento, procesamiento o tránsito.

También la protege contra la negación  de  servicios  a  usuarios  desautorizados  y  la  provisión  de  servicio  a  usuarios  desautorizados, incluyendo las medidas necesarias para detectar, documentar, y contrariar tales amenazas.

Muchas preguntas con respecto a la seguridad, son relacionadas al ciclo vital de software. En particular, la  seguridad del código y el proceso de software; deben de ser considerados durante  la  fase del diseño y  desarrollo. Además,  la  seguridad  debe  de  ser  preservada  durante  la  operación  y  el mantenimiento  para  asegurar la integridad de una parte (pedazo) de software.