CLASE 2

Índice de Contenidos

• Repaso Sesión Anterior

• Criterios Mínimos para el Desarrollo y Adquisición de Software
• Diseño de Software Seguro
• Cultura Organizacional y Capacitación
• Responsabilidades
• Trabajo

2
 Repaso Sesión Anterior

3
 Repaso Sesión Anterior

• Introducción a DevSecOps
• Desarrollo Seguro de Software
• Propiedades del Software Seguro
• Confidencialidad
• Integridad
• Disponibilidad
• Rendición de Cuentas
• No Repudio
• Fiabilidad
• Previsibilidad
• Tamaño y Complejidad

4
 Repaso Sesión Anterior

• Principios de Seguridad
• Mínimo Privilegio
• Fortalecer el Eslabón Más Débil
• Seguridad en Caso de Fallos
• Defensa en Profundidad
• Participación Universal
• Simplicidad
• Accesibilidad
• La Seguridad no se obtiene a través de la Oscuridad

5
 Criterios Mínimos para el Desarrollo y
Adquisición de Software

6
 Criterios Mínimos para el Desarrollo de Software

Existen algunos criterios de seguridad mínimos que cualquier organización

debe contemplar en los requerimientos para el desarrollo y adquisición de
software e implementación con software de terceros.

Estos criterios son aplicables al software

desarrollado internamente y/o
adquirido a proveedores externos. Es
importante recalcar que acá estamos
hablando de estándares "mínimos
deseados" (es decir, el desde), lo cual no
quita que pueda ser complementado
con otros criterios propios que defina
cada organización.

7
 Criterios Mínimos para el Desarrollo de Software

Soporte y Gestión Continua del Software

1. Todo el software desarrollado debe contar con soporte del fabricante. Al
momento de la adquisición se debe establecer claramente el tiempo de vida
mínimo que se requiere para el software o sistema, y el fabricante debe ofrecer
un tiempo de soporte igual o superior a dicho tiempo de vida.

2. En caso de que no sea posible contar con

soporte de software del fabricante, el modelo
de licenciamiento y la disponibilidad del
código fuente debe ser tal que permita a la
organización asumir dicho soporte.

8
 Criterios Mínimos para el Desarrollo de Software

Soporte y Gestión Continua del Software

3. El fabricante o servicio de soporte debe tener un canal de comunicación y/o
mecanismo de reporte de vulnerabilidades o bugs, de manera a que el cliente
pueda contactarlo en caso de descubrimiento de vulnerabilidades. En caso de
que el reporte ocurra dentro de la ventana de tiempo de vida solicitado, el
fabricante o servicio de soporte debe ser capaz de proporcionar una corrección
a la vulnerabilidad de manera oportuna, según el SLA especificado en el
contrato.

4. El software debe poder ser inventariado

por herramientas estándar de inventario,
debiendo incluir como mínimo la información
del nombre, versión, autor y fecha de
instalación del mismo.

9
 Criterios Mínimos para el Desarrollo de Software

Gestión de Usuarios, Sesiones y Privilegios

1. El software debe permitir una gestión de usuarios de acuerdo a los
requerimientos de la organización, con niveles de privilegios de acuerdo a los
roles que éstos requieran (administrador, editor, usuario, etc.), basados en el
principio de mínimo privilegio.

2. El software debe permitir la revocación de

acceso de usuarios, mediante un estado
"desactivado" o similar. Puede parecer una
obviedad, pero muchos softwares no
permiten dar de baja a los usuarios creados.

10
 Criterios Mínimos para el Desarrollo de Software

Gestión de Usuarios, Sesiones y Privilegios

3. Debe ser posible establecer una fecha de expiración para las cuentas de
usuarios, a partir de la cual la cuenta deberá entrar a un estado “desactivado” o
similar, hasta tanto se apruebe la continuidad de la misma. El parámetro de
fecha de expiración podrá ser fijo o configurable por la organización, de
acuerdo a sus requerimientos de negocio.

4. Así también el software debe contemplar

la expiración de sesiones de acuerdo a
parámetros temporales. Estos parámetros
pueden ser fijos o configurables por la
organización, de acuerdo a sus
requerimientos de negocio.

11
 Criterios Mínimos para el Desarrollo de Software

Autenticación y Gestión de Credenciales

1. El software debe permitir la gestión individual eficaz de credenciales,
debiendo permitir que cada usuario sea capaz de cambiar su propia contraseña.
Se debe contemplar también mecanismos de recuperación de contraseñas, ya
sea a través de un usuario de mayores privilegios o de mecanismos de
autogestión por parte del usuario. Preferentemente, debe ser posible que al
momento de la creación de cuentas permita forzar el cambio de contraseña
luego del primer inicio de sesión.

2. El software debe permitir establecer

políticas de contraseña, que incluyan, como
mínimo, la posibilidad de establecer los
siguientes parámetros: longitud, complejidad,
frecuencia de forzado de cambio.

12
 Criterios Mínimos para el Desarrollo de Software

Autenticación y Gestión de Credenciales

3. Las contraseñas no deben almacenarse en texto claro, sino mediante la
aplicación de funciones hash o funciones resumen. Para el almacenamiento de
las contraseñas se debe utilizar funciones criptográficas seguras no reversibles
de hash combinadas con salt aplicadas a las contraseñas.

4. De manera alternativa, se pueden cifrar las

contraseñas utilizando técnicas criptográficas
reversibles únicamente en aquellos casos en
que la clave secreta y/o privada de cifrado
quede bajo el poder exclusivo del usuario
dueño de la contraseña.

13
 Criterios Mínimos para el Desarrollo de Software

Gestión de Registros de Auditoría

1. El software debe ser capaz de generar registros de auditoría de todos los
eventos relevantes, con los detalles suficientes para permitir una trazabilidad
adecuada, que abarque como mínimo los siguientes eventos:

▪ Inicios de sesión de usuarios (exitosos y

fallidos).
▪ Modificación de parámetros del sistema.
▪ Gestión de usuarios (cambio de contraseña,
creación/eliminación/modificación de
usuarios y/o grupos).
▪ Acciones críticas llevadas a cabo por
usuarios.

14
 Criterios Mínimos para el Desarrollo de Software

Cifrado
1. El software debe cifrar toda la información sensible en tránsito,
especialmente aquella información de carácter confidencial y/o cuya integridad
deba asegurarse. Para ello se deberán utilizar protocolos de red cifrados, tales
como HTTPS, SSH, SCP, SFTP/FTPS, etc.

2. Para sistemas basados en web, se

adoptará el modelo TLS para el cifrado
del tráfico. Se deben seleccionar suites
de cifrado robustos; una guía de
referencia es:
https://www.owasp.org/index.php/TLS_Cipher_String_Cheat_Sheet

15
 Criterios Mínimos para el Desarrollo de Software

Codificación del Software

1. Se deben utilizar estándares de buenas prácticas seguras de programación,
las cuales deben ser seleccionadas e implementadas de acuerdo al lenguaje de
programación y el entorno de desarrollo utilizado. En este punto se deben
considerar también directrices de desarrollo seguro.

2. El software debe contemplar un manejo

seguro de errores. Se debe realizar y
documentar la verificación explícita de
errores para todas las entradas,
comprobando el tamaño, el tipo de datos, los
rangos de valores y/o formatos aceptables
de modo a que éstos sean válidos para la
operación que están por realizar.

16
 Criterios Mínimos para el Desarrollo de Software

Codificación del Software

3. Todos lo componentes de terceros utilizados para el desarrollo del software
deben estar actualizados a la última versión estable disponible, contar con
soporte por un periodo igual o superior al exigido para el proyecto y ser de
confianza. Esto es aplicable, pero no limitante, a librerías, frameworks , scripts ,
funciones, plugins , plantillas, generadores de código, compiladores, entre
otros.

4. Se debe realizar y documentar las

pruebas de vulnerabilidades de código,
incluyendo análisis estático y dinámico
para verificar que se cumplan los
estándares mínimos de codificación
segura, utilizando herramientas y/o guías
de testing de seguridad estándar y
aceptados por la industria.
17
 Diseño de Software Seguro

18
 Diseño de Software Seguro

Sociedad del Conocimiento

Podemos definir la sociedad del conocimiento como aquélla en que los
ciudadanos disponen de un acceso prácticamente ilimitado e inmediato a la
información, y en la que ésta, su procesamiento y transmisión actúan como
factores decisivos en toda la actividad de los individuos, desde sus relaciones
económicas hasta el ocio y la vida pública.

Surge como consecuencia de los cambios que

inducen en la sociedad una serie de
innovaciones tecnológicas desarrolladas en
tres sectores convergentes: la informática,
las telecomunicaciones y en especial Internet
y los medios de comunicación. Algunos
autores incluyen también la ingeniería
genética.
19
 Diseño de Software Seguro

Sociedad del Conocimiento

El desarrollo de la industria de la informática se junta con las
telecomunicaciones, creando el llamado sector de las Tecnologías de la
Información y Comunicación (TIC). La digitalización permite asimismo a estas
tecnologías confluir con los medios de comunicación y sus contenidos. A
consecuencia de ello, las industrias pueden converger en lo que llamamos el
“Sector de la Información”.

En los últimos años, este sector ha llegado

a ser el más pujante y su impacto
económico es enorme, tanto en el nivel
macroeconómico como en el empresarial,
siendo conocido como “Nueva Economía”
o “Economía Digital”.

20
 Diseño de Software Seguro

Sociedad del Conocimiento

Finalmente, estas innovaciones tecnológicas y económicas afectan y producen
un cambio revolucionario en el conjunto de la sociedad. Esta sociedad
transformada es la Sociedad de la Información o Sociedad del Conocimiento.

Desde su génesis, la sociedad del

conocimiento es hija de polos opuestos. Nace
de la simbiosis entre los grandes contratos de
Defensa norteamericanos, que están en el
origen de la informática y de Internet, con el
potencial creativo, innovador e individualista
de Silicon Valley.

21
 Diseño de Software Seguro

El software es un elemento catalogado de seguridad nacional en los países que

tienen un plan de desarrollo orientado hacia la sociedad del conocimiento. La
preocupación en esos países se basa en el hecho de que la Ingeniería de
software no ha logrado que los desarrollos de software cumplan con la
característica denominada “trustworthy”, es decir, digno de confianza.

Los países orientados a conformar sociedad del conocimiento y que tienen en el

desarrollo de software un compromiso como industria (por ejemplo: USA),
consideran que su país es una nación bajo riesgo de consecuencias inaceptables
por las fallas del software.

Estas fallas pueden crear serios problemas en varios riesgos, enumerando

específicamente la infraestructura nacional, la economía, la vida de las
personas, la pérdida de confianza pública, de la identidad y liderazgo.

22
 Diseño de Software Seguro

Si bien Chile no se compara con la capacidad productiva de software que tiene

EEUU es de mucha utilidad conocer sus planes de protección y mejora, pues de
todas maneras las tecnologías informáticas tienen un carácter global. Siendo
innegable la importancia del software, así como su penetración en la vida
cotidiana se ve la necesidad de revisar el estado de la Ingeniería de software.

La Ingeniería de software, en sus 50 años

de existencia aún no ha podido resolver el
riesgo de que un avión se caiga por culpa
de un fallo en una variable. Entonces,
parece que no son tan exagerados los
esfuerzos que se hacen en pro de un
desarrollo seguro por parte de naciones
más desarrolladas.

23
 Diseño de Software Seguro

Al menos dos accidentes registrados en 2018 y 2019 tuvieron un factor en

común: una aparente falla en el software instalado en el modelo 737 MAX de
Boeing.

Este modelo de Boeing ha sido tristemente célebre a causa de dos mortales

accidentes que cobraron la vida de 317 personas y en los que se involucra un
elemento en común: el software utilizado para las maniobras de aterrizaje.

El MCAS (Maneuvering Characteristics Augmentation System), sistema de

seguridad utilizado por el Boeing, que se activa cuando los sensores del avión
exceden ciertos parámetros para el aterrizaje, entre ellos, lo que se conoce el
24 "ángulo de ataque".
 Diseño de Software Seguro

25
 Diseño de Software Seguro

El MCAS es un sistema que se activa automáticamente al detectar un ángulo de

ataque inadecuado, haciendo que el avión eleve la cola y baje la nariz para
nivelar el avión. En ambos accidentes se detectó que los aviones habían iniciado
un proceso de vuelo con nariz hacia abajo, debido a que la recepción de
información errónea en los sensores en el computador de a bordo activó el
MCAS.
https://www.primicias.ec/noticias/tecnologia/millonarias-multas-para-boeing-causa-error-software/
26
 Diseño de Software Seguro

Software digno de confianza (trustworthiness)

Se introduce el término "trustworthiness" o la cultura sobre las características
que debe cumplir el software para ser digno de confianza. Estas características
se resumen en 4 grandes pilares que revisaremos más adelante.

Un desarrollo de software digno de confianza

tiene múltiples atributos, con un amplio
espectro de adversidades y compromisos. La
inclusión del factor humano en estas
taxonomías dan que pensar en cuanto a la
formación integral de los profesionales, en
donde los aspectos de tipo ético cobran aún
más valor.

27
 Diseño de Software Seguro

Software digno de confianza (trustworthiness)

Una estrategia adecuada contempla en primer lugar la necesidad de que a la
fuerza de trabajo (no solo a los desarrolladores), se les eduque
permanentemente y se les defina una estructura salarial adecuada y
competitiva.

No son las buenas intenciones las que

lograrán crear software digno de confianza,
sino una formación profesional y una
intención permanente que debe ser
involucrada en el ejercicio profesional. Esto
no debe ser una opción, sino una necesidad.
Lo anterior requiere entonces de mejores
diseños en las métricas de calidad, en el
proceso evaluativo y en las metodologías a
utilizar.
28
 Diseño de Software Seguro

Seguridad
Se refiere a la exposición de los programas a peligros no intencionados en sus
especificaciones; es decir, que no se dan por mala Ingeniería de software o
malas prácticas en la programación, sino por aspectos de índole externo.

Cabe hablar aquí de código malicioso y

malintencionado como son los virus,
troyanos, puertas traseras, spam lo que no
sólo crea problemas reales de disminución
de confianza, sino que bajan la
productividad porque el tiempo de control y
revisiones de los daños es muy grande,
pudiendo usarse en otras labores más
productivas.

29
 Diseño de Software Seguro

Confianza
La vida normal de las personas transcurre con el uso de elementos o artefactos
que dependen del software y que su uso debe generar confianza para una
tranquilidad de índole social.

El software inseguro puede llegar a hacer

daño a las personas y a la propiedad en
ambientes de uso cotidiano como la aviación,
la medicina, la exploración espacial, la banca y
en general el transporte. Obsérvese cómo en
estas actividades está en peligro la vida de las
personas, no sólo una funcionalidad con
repercusiones económicas.

30
 Diseño de Software Seguro

Fiabilidad
En algunos casos el software participa de soluciones de gran escala que pueden
afectar de manera masiva a la sociedad, como la defensa nacional, las
telecomunicaciones, la energía, el espacio y los sistemas financieros. El hecho
de utilizar satélites para las telecomunicaciones y el transporte de los datos nos
puede afectar.

Supervivencia
Este término se define como una
característica que asegure que el
software se debe mantener en continuo
funcionamiento, aún en situaciones
adversas y no sólo en ambientes
benignos.

31
 Cultura Organizacional y Capacitación

32
 Cultura Organizacional y Capacitación

Hoy en día hay un concepto que está tomando fuerza y que hace pocos años no
estaba en el radar de las necesidades dentro de una compañía; este es el
desarrollo seguro de software.

Por cultura, falta de conciencia y de capacitación, el desarrollo y la

implementación de software en las organizaciones, tanto para las que tienen en
esta actividad su core de negocio como aquellas que simplemente son usuarios,
estuvo por mucho tiempo enfocado a entregables limitados a temas de calidad
en cuanto a funcionalidad, pero no se tenía en cuenta la manera en que se podía
llegar a desarrollar un software, técnicas o metodologías que ayudaran a
minimizar lo más posible la exposición y debilidades que el mismo presentaría
ante un ataque.
33
 Cultura Organizacional y Capacitación

La evolución misma de las amenazas, de los ataques informáticos y el impacto

de estos, han generado una conciencia en las empresas sobre la necesidad de
desplegar software sin vulnerabilidades potenciales que puedan ser parte de
vectores de ataque hacia la compañía misma.

Junto con el despertar de las

organizaciones sobre este tema,
también han surgido grupos de
trabajo enfocados a promover y
homologar de alguna manera el
trabajo que se debe desempeñar por
cada uno de los desarrolladores en
aras de poder entregar software con
especificaciones de seguridad que
dificulten la tarea de los atacantes
informáticos, como por ejemplo:
OWASP.
34
 Cultura Organizacional y Capacitación

Son muchas los métodos o sugerencias que pueden surgir para poder llegar al
objetivo de desarrollar software seguro en una organización. A continuación se
enunciaran como guía algunos de estas alternativas que se pueden
implementar, sin que por ello deban limitarse las organizaciones solamente a
las opciones que se mostrarán a continuación:

35
 Cultura Organizacional y Capacitación

Implementar Framework de Seguridad

Más allá de sugerir la implementación de un marco de trabajo, o incluso de
llegar a combinar aspectos destacados de cada uno estos, lo realmente
relevante en este punto es la importancia de contemplar la adopción de una
metodología de análisis y gestión del riesgo dentro de las empresas, que incluya
un sistema completo de gestión de seguridad de la información donde se
implementen todos los aspectos prioritarios del mismo.

En este punto se puede identificar como

crítico la adopción y adherencia del marco de
trabajo sobre el cual se va a trabajar la
seguridad de la información, y que se adapte
a las necesidades puntuales de la
organización, tales como: ITIL, COBIT, ISO
27000, SANS Security Policy Project, NIST
Cybersecurity Framework (CSF), etc.
36
 Cultura Organizacional y Capacitación

Implementar Framework de Seguridad

Desde el punto de vista del desarrollo de software seguro, se hace relevante
que para cualquier framework de seguridad implementado se contemple el
desarrollo de las aplicaciones en todo su ciclo de vida, desde la especificación
de requerimientos del mismo, hasta su despliegue o instalación.

Hoy en día se puede observar que las

organizaciones por las necesidades y
presiones que impone los negocios y la
tecnología misma, están adoptando
framework de seguridad, destacándose
entre los más utilizados la ISO 27001 y
el Framework de Ciberseguridad de la
NIST.

37
 Cultura Organizacional y Capacitación

Aplicar Modelos de Defensa en Profundidad

Este término está enfocado principalmente a implementar la seguridad en
general desde distintas capas (Firewall, IPS, IDS, etc) de la infraestructura de
una compañía, no deja de ser útil y adaptable el concepto a un software
resultante más seguro.

Este punto hace referencia a que independiente

del marco de seguridad de la información que
esté siendo aplicado, debe abordarse el tema de
mitigar las vulnerabilidades de software desde
varios frentes, es decir, que no solo la aplicación
de técnicas y guías para un desarrollo de
software seguro es suficiente para salvaguardar
al mismo ante los ataques o amenazas a las que
se expone.

38
 Cultura Organizacional y Capacitación

Aplicar Modelos de Defensa en Profundidad

Una fase que se podría establecer como un punto de control sería la revisión de
código en sus distintas variantes, sea análisis de código estático o dinámico,
permitiendo así validar la efectividad de los métodos y técnicas utilizadas para
la construcción de las aplicaciones respecto a la remediación o eliminación de
las vulnerabilidades más comunes dentro de su código fuente.

Otra etapa dentro de este concepto de

capas de seguridad para las aplicaciones
son las herramientas, plataformas o
agentes de seguridad (endpoints,
antimalware, IDS o IPS en cualquiera de
sus variantes, etc.) que realicen el
monitoreo y control sobre
comportamiento del software una vez
desplegado y en ejecución.
39
 Cultura Organizacional y Capacitación

Cultura Organizacional y Capacitación

Quizás este es el punto más importante y sobre el cual se requiere mayor
esfuerzo. Acá hablamos básicamente de dos necesidades clave.

Una es capacitar al personal sobre la

importancia, métodos, guías y normas para el
desarrollo seguro de software, y la otra es la
obligación de crear una cultura
organizacional en torno a este tema. La
importancia de trabajar estos dos puntos
radica en que si no se llegan a fortalecer,
probablemente no dará resultados la
implementación de un framework o fases de
seguridad para el software, o cualquier otra
opción que se pretenda implementar.

40
 Cultura Organizacional y Capacitación

Cultura Organizacional y Capacitación

Si no se cumplen con dichos requisitos posiblemente la adopción de cualquier
alternativa no tendrá la suficiente aceptación dentro de la organización, y por
ende, carecerá de apoyo de cada uno de las áreas y jerarquías establecidas
dentro de la misma, siendo estos requisitos fundamentales para el éxito de
cualquier implementación que se llegue a hacer.

Respecto a la capacitación, es necesario

que esta sea trabajada desde dos frentes:
uno técnico y otro como generador de
conciencia. La razón por la que se
contemplan dos frentes es porque ambos
se requieren para poder obtener los
resultados esperados y son complemento
uno del otro.

41
 Cultura Organizacional y Capacitación

Cultura Organizacional y Capacitación

La parte técnica se puede suplir con capacitaciones o cursos en donde se
eduque sobre temas de seguridad informática, vulnerabilidades, metodologías
y/o guías existentes. Esta es la parte menos compleja de la ecuación.

Como complemento de la capacitación técnica,

está la labor de concientización a distintas áreas
sobre los riesgos, impactos y requerimientos
asociados a la seguridad en el desarrollo de
software. Esta tarea no solo va dirigida a equipos
de desarrollo o personal de seguridad informática,
sino que tiene alcance en todo el equipo de
trabajo que puede llegar a estar involucrado
dentro del ciclo de vida del software, abarcando
incluso los altos directivos que aprueban los
proyectos y su presupuesto.
42
 Cultura Organizacional y Capacitación

Cultura Organizacional y Capacitación

En lo que concierne a la cultura organizacional, se requiere un cambio de
mentalidad y orientación en la manera como se maneja la puesta en marcha de
productos, software y servicios en las compañías, es decir, que debe
considerarse la seguridad desde la concepción misma de los proyectos y no solo
contemplando funcionalidad sobre el resultado de los mismos.

Todos en la organización deben tener la

misma orientación y entendimiento
respecto a la seguridad, en el sentido que
cada una de las áreas entienda las
necesidades, retos y objetivos de
seguridad que debe perseguir la
organización, adicional al rol y tareas que
cada una de las partes desempeña dentro
de este objetivo común.
43
 Cultura Organizacional y Capacitación

Cultura Organizacional y Capacitación

Además del entrenamiento para los funcionaros de la empresa, también es
necesario construir y oficializar una política de seguridad que contemple todos
estos aspectos, por lo que se requiere generar convicción, apoyo y compromiso
desde la misma junta directiva.

Desde los mismos directivos y dueños de

las empresas es necesario aprobar,
generar y hacer seguimiento a los
lineamientos que en materia de seguridad
deben aplicarse y sobre los cuales cada
uno de los funcionarios tiene que regirse
en su actuar.

44
 Responsabilidades

45
 Responsabilidades

Si una constructora edifica un inmueble con defectos y este se derrumba,

seguramente habrá consecuencias para quien lo construyó. Lo mismo pasa con
un automóvil defectuoso que causa un accidente grave. ¿Pero qué pasa con el
software? Nada, con el software seguramente no pasa nada.

Parece que a las debilidades

informáticas de los softwares no se les
da el debido trato de “defecto”. Más de
una licencia de software establece que
no hay responsabilidad del fabricante
por este tipo de “carencias”, que son
vulnerabilidades que pueden permitir a
un atacante alterar el funcionamiento
del software o al menos hacer que deje
de operar.

46
 Responsabilidades

Tomemos como ejemplo un sistema operativo, el cual seguramente está siendo

parchado frecuentemente para solucionar problemas de seguridad. Si bien el
fabricante envía estos parches para solucionar los problemas, no hay
responsabilidad alguna por cualquier consecuencia que el cliente puede haber
sufrido a causa de este defecto. ¿El atacante logró robar dinero, enviar spam,
tomar control de una cuenta de red social o espiar comunicaciones
supuestamente protegidas? Ese es problema del cliente; que él lidie con eso.

No hay responsabilidad por las

consecuencias o impactos sufridos por
cualquier defecto en el software. Quizás el
fabricante se disculpe; seguramente lo
corregirá con un parche; pero no pagará
ningún monto por las consecuencias de que
un atacante haya explotado la vulnerabilidad
exitosamente.
47
 Responsabilidades

Si no existe una responsabilidad asociada, probablemente la empresa de

desarrollo no haga nada (o poco) para introducir seguridad en su metodología
de desarrollo de software, y no solamente por falta de voluntad, sino porque
cuesta dinero hacerlo. Pero las consecuencias de las debilidades en el software
pueden ser más serias que solo adueñarse de cuentas de redes sociales.

Muchas empresas tienen una larga y

exitosa evolución en materia de
seguridad física de sus productos (por
ejemplo: autos y aviones), pero todavía
están en pañales en cuestión de
seguridad informática.

48
 Responsabilidades

En el FTF (Future Trends Forum) de 2019: Ciberseguridad un Desafío Mundial,

varios expertos propusieron un conjunto de 10 acciones para mejorar la
seguridad informática global.

1. Reducir los costes globales del

cibercrimen. Que exista la posibilidad de
iniciar procesos judiciales contra los
cibercriminales para la recuperación de las
pérdidas ocasionadas.

2. Promover desde el diseño la seguridad y

privacidad en el software. Los expertos del
FTF proponen que se sugiera a las empresas
cumplir unos estándares claros de seguridad
que se prueben antes de salir al mercado.

49
 Responsabilidades

3. Generalizar la autenticación de doble factor. La autenticación de doble

factor es una tecnología que verifica dos veces la identidad digital para
aumentar la seguridad informática. Es recomendable su implantación para la
industria financiera y los pagos digitales.

4. Educar a los ciudadanos en ciberseguridad básica. Podrían organizarse

campañas de concienciación global para que los ciudadanos estén informados y
ayuden a presionar a las entidades correspondientes para su implementación.

5. Concienciar al consumidor digital en seguridad. Debería existir una “ciber”

entidad para educar a los ciudadanos a tomar precauciones frente a ciertas
prácticas de riesgo.

50
 Responsabilidades

6. Proteger los datos nacionales. Colaboración entre países y empresas para

conseguir preservar los datos que sean de su propiedad.

7. Exigir responsabilidad penal a los responsables de software inseguro. Los

expertos en seguridad informática proponen crear unos estándares legales en
cuanto a seguridad del software, impulsados por una autoridad para la
ciberseguridad, y que se persiga legalmente su incumplimiento.

8. Avanzar hacia un software de

calidad. Se insta a estandarizar
unos requisitos y especificaciones
concretas sobre calidad del
software.

51
 Responsabilidades

9. Impulsar una estrategia de ciberseguridad global. Se exige un mandato claro

del compromiso de los gobiernos acerca de ciberseguridad, con el objetivo de
atajar la falta de confianza en el ciberespacio.

10. Colaboración público-privada. La

cooperación sería clave para mejorar el
intercambio de información sensible. Esta
cooperación sería liderada por el sector
privado como víctima de pérdidas millonarias
por el ciberdelito, acompañado de los grandes
vendedores de software, y con la
colaboración del sector público.

52
 Responsabilidades

Exigir responsabilidad penal a los responsables de software inseguro

El objetivo de esta medida es animar a que se legisle sobre responsabilidad
penal en el caso del software. Se propone seguir el ejemplo de otras industrias
en cuanto a responsabilidad legal en temas de seguridad. Los expertos
reconocen que es especialmente complicada su regulación por la complejidad
para establecer parámetros globales de estandarización de lo que sería un
software seguro y por la falta de coordinación internacional en este objetivo.

¿Cómo debería legislarse? Los intervinientes

instan a mirar como ejemplo a otras
industrias. Recuerdan que en ámbitos como
la seguridad de los autos o en temas de
contaminación, la gente va a la cárcel cuando
incumple ciertas exigencias de seguridad en
procesos de fabricación.
53
 Responsabilidades

Exigir responsabilidad penal a los responsables de software inseguro

Se necesitan métricas que permitan determinar y establecer objetivos para
determinar con rigor si un software es realmente bueno o no y su seguridad.
Asimismo, estándares legales frente a ciertos comportamientos. No tanto
estándares técnicos sino “mejores prácticas”, aunque los expertos admiten que
es complicado determinar cuál debería ser el punto de referencia que marque
la frontera entre lo seguro o no en el ámbito del software.

Los “tests” actuales para comprobar su

calidad “son insuficientes” y asimismo son
“escasas” las verificaciones que se realizan
antes de ser lanzados los programas al
mercado o integrarse en nuevos sistemas
dentro del llamado “Internet de las Cosas”.

54
 Responsabilidades

Exigir responsabilidad penal a los responsables de software inseguro

Una legislación que exigiera responsabilidades penales en temas de seguridad
del software contribuiría a reducir vulnerabilidades en los sistemas
informáticos y su uso por grupos como los cibercriminales en beneficio propio.

Se augura un largo camino en el mundo de

la ingeniería del software, con intensos
debates sobre aspectos metodológicos,
desarrollo de ciclo de vida de los programas
o distintos lenguajes de programación.

Se habla de cierta complacencia por parte de los profesionales del software y

de la informática, quienes probablemente disfrutan mucho con conferencias y
están haciendo una muy buena investigación, pero sin embargo, no se interesan
del mismo modo en lo que se refiere a crear legislación.
55
 Recuerde utilizar los foros de cada módulo
56
CLASE 2