Apéndice 13 - Arquitectura de Seguridad

Administracin General de Aduanas
Administracin Central de Planeacin y

Coordinacin Estratgica Aduanera
Proyecto de Integracin Tecnolgica Aduanera

Apndice 13.
Arquitectura de Seguridad
1. Requerimientos No Funcionales de Seguridad
1.1.
Alcance
El presente documento es de referencia y podr ser actualizado durante la

vigencia del contrato, de conformidad con los lineamientos institucionales del
SAT y proveedor PITA deber cumplir y ajustarse a su correspondiente
actualizacin.
1.2.
Propsito
El propsito del presente documento es establecer los requerimientos no

funcionales tcnicos de seguridad, los cuales son de observacin obligatoria en
la definicin de la arquitectura de seguridad y, en general, para el desarrollo de
(nuevas) soluciones tecnolgicas dentro del SAT.
El documento se centra en la decisin arquitectnica de seguridad relativa a
los requerimientos no funcionales de seguridad, los cuales deben ser
observados en el anlisis, diseo, determinacin de la arquitectura de la
aplicacin en materia de seguridad tecnolgica, en la definicin de la
arquitectura de seguridad y en la programacin, desarrollo e implementacin
de las (nuevas) soluciones tecnolgicas dentro del SAT, de modo que se sigan
lineamientos mnimos que garanticen la integridad, confidencialidad y
disponibilidad de la informacin. Las mencionadas (nuevas) soluciones
tecnolgicas incluyen: aplicativos, aplicaciones web, y en general cualquier
sistema de cmputo desarrollado para el SAT.
1.3.
Audiencia
Este documento est dirigido a todas las personas involucradas en el desarrollo

de proyectos del SAT:
Anexo Tcnico del Proyecto de Integracin Tecnolgica Aduanera (PITA)
Apndice 13
Pgina 1 de 23

Fbricas de Desarrollo de software.

Gobierno de las fbricas de desarrollo correspondientes.
Analistas y diseadores de software.
Arquitectos tecnolgicos y de integracin.
Arquitectos de seguridad.
Desarrolladores.
Lderes Tcnicos.
Entidades Externas que desarrollen nuevas soluciones tecnolgicas para
el SAT.
Programadores contratados por el SAT para el desarrollo de aplicaciones
web que requieran hacer uso de servicios web externos.
Instituciones que requieran integrarse a las soluciones tecnolgicas del
SAT.
1.4.
Trmino
AAS
ACSMC
AGCTI
CAPTCHA
HTTPS
MTR
SSL/TSL
Glosario.
Significado
Administracin de Arquitectura de Seguridad
Administracin Central de Seguridad Monitoreo y Control
Administracin General de Comunicaciones y Tecnologa de la
Informacin
Completely Automated Public Turing test to tell Computers and
Humans Apart (CAPTCHA), en espaol, Prueba pblica y
automtica de Turing para distinguir a los ordenadores de los
humanos es un tipo de medida de seguridad conocido como
autenticacin preguntarespuesta, que procura garantizar que un
ser humano es quien hace uso de las aplicaciones.
"Hypertext Transfer Protocol Secure (Protocolo seguro de
transferencia de hipertexto), La idea principal de https es la de
crear un canal seguro sobre una red insegura. Siempre que se
empleen mtodos de cifrado adecuados y que el certificado del
servidor sea verificado y resulte de confianza.
Marco Tecnolgico de Referencia. Estandarizacin de la tecnologa
y el uso de esta en el SAT, para el reso de componentes
tecnolgicos esto a travs de especificaciones, estndares,
directrices, dictmenes y arquitecturas de referencia tcnicas o
mejores prcticas.
Secure Sockets Layer (SSL), en espaol Capa de Conexin Segura y
su sucesor (Transport Layer Security (TLS)); en espaol seguridad
de la capa de transporte) son protocolos criptogrficos diseados
para proporcionar comunicacin segura por una red (comnmente
Internet) mediante la creacin de un canal seguro.

Apndice 13
Pgina 2 de 23

Requerimient
os
No
funcionales
de seguridad
Certificados
Sanitizacin
de formularios
web
1.5.
Son restricciones de los servicios o funciones ofrecidos por el

sistema. Incluyen restricciones de seguridad, sobre el proceso de
desarrollo y estndares. Los requerimientos no funcionales a
menudo se aplican al sistema en su totalidad. Normalmente apenas
se aplican a caractersticas o servicios individuales del sistema. Los
requerimientos no funcionales, como su nombre sugiere, son
aquellos requerimientos que no se refieren directamente a las
funciones especficas que proporciona el sistema, sino a las
propiedades emergentes de ste. De forma alternativa, definen las
restricciones del sistema en materia de seguridad.
Un certificado de clave pblica es un punto de unin entre la clave
pblica de una entidad y uno o ms atributos referidos a su
identidad. El certificado garantiza que la clave pblica pertenece a
la entidad identificada y que la entidad posee la correspondiente
clave privada.
Los certificados de clave pblica se denominan comnmente
Certificado Digital, ID Digital o simplemente certificado. La entidad
identificada se denomina sujeto del certificado o subscriptor (si es
una entidad legal como, por ejemplo, una persona o institucin).
Sanitizar entradas de formularios web es controlar que el valor que
contienen no pueda convertirse en una amenaza en nuestro
servidor.
Referencias.
[1] Decisin Arquitectnica Requerimientos funcionales Tcnicos de Seguridad
1.6.
Alternativas.
En el alcance del Marco Tecnolgico de Referencia, el cumplimiento de lo

establecido en el presente documento con respecto a los requerimientos no
funcionales de seguridad es de carcter obligatorio, por lo que debe ser
considerado en el desarrollo e implementacin de las (nuevas) soluciones
tecnolgicas dentro del SAT.
Sin embargo, en caso de existir alternativas tcnicas que constituyan alguna
opcin consistente a los requerimientos no funcionales de seguridad
establecidos en este documento, y que por ende, garanticen la integridad,
confidencialidad y disponibilidad de la informacin, la ACSMC podr analizarla
de forma particular y emitir la definicin correspondiente para su utilizacin.
Apndice 13
Pgina 3 de 23

1.7.
Solucin.
Como parte de las funciones que son competencia de la Administracin

Arquitectura de Seguridad (AAS) perteneciente a la (ACSMC), se emite
siguiente Decisin Arquitectnica con respecto a los requerimientos
funcionales de seguridad para las (nuevas) soluciones tecnolgicas que
desarrollen e implementen para el SAT.
1.8.
de
la
no
se
Requerimientos No Funcionales de Seguridad.
Apegarse a las especificaciones Tcnicas vigentes de Seguridad que

estn en el Marco Tecnolgico de Referencia del SAT.
Aplicacin de CAPTCHA en pginas web y mviles.
Para las soluciones tecnolgicas(portal Web o mvil) del SAT que son
pblicas y no requieren autenticacin (por usuario/contrasea, Fiel o
ambos u otro mecanismo de autenticacin), es obligatorio el uso de
mecanismos y componentes CAPTCHA a fin de garantizar que un ser
humano es quien hace uso de los sistemas SAT, evitando que robots
(bots) exploten ciertos servicios y con ello mitigar ataques DoS (Denial of
Service) o DDoS (Distributed Denial of Service) en ambientes web o
dispositivos mviles, como telfonos inteligentes o tabletas.
SHA256 (SHA2 256).
Se deben utilizar como algoritmos de integridad la funcin criptogrfica

hash SHA2 con una longitud (tamao del bloque) de al menos 256 bits
para el intercambio de informacin entre aplicaciones distribuidas,
centro de datos incluyendo los cloud computing, o intercambios de
informacin entre el SAT y otras instituciones.
SSL 2048
HTTPS es un protocolo de aplicacin basado en el protocolo HTTP, provee

un medio seguro de comunicaciones basado en SSL/TSL para crear un
canal seguro de comunicacin para el trfico de informacin. Se debe
utilizar para el cifrado asociada a HTTP, certificados de clave pblica de
al menos 2048 bits para el transporte SSL/TSL.

Apndice 13
Pgina 4 de 23

La informacin de negocio SAT siempre deber estar almacenada en la

capa de datos.
Eliminar (Information disclosure) de los nuevos sistemas, mensajes de

informacin a los errores provocados de http como 400 o 500 etc., que
proporcionan informacin de versiones de servidores web o de
aplicaciones.
Pruebas de vulnerabilidad (caja blanca, negra y de penetracin). Todas

las aplicaciones nuevas del SAT debern de someterse a pruebas de
vulnerabilidad y atender de manera inmediata las denominadas crticas
o de color rojo antes de salir a produccin.
Federacin de Identidades. Es obligatorio para los nuevos aplicativos que

requieran un SSO y un SLO SAT usar para la autenticacin por
Federacin de identidades, la cual se basa en protocolos estndar
SAML2, WS-Federation, Liberty Alliance, OAuth u OpenID para el
intercambio de autenticacin y autorizacin. Para lo cual es necesario
tener en cuenta lo siguiente:
Se requiere el intercambio de metadata entre los Ids (Identity

Providers) y los SPs (Service Providers). Los IdPs del SAT y los SPs
de los aplicativos El service provider perteneciente al aplicativo
debe utilizar y soportar alguno de los protocolos estndar para la
federacin.
Los atributos requeridos del aplicativo deben ser incluidos en el

paquete de la federacin, conforme a las necesidades de cada
aplicacin, los cuales sern configurados por el personal a cargo
de la administracin de identidades del aplicativo con la condicin
que estos existan en el directorio Institucional.
El sistema deber de mitigar y controlar ataques XSS (Cross Site

Scripting), deber adicionar medidas robustas (no solo limitando el
nmero de caracteres utilizando en el caso de java el atributo
maxlenght), la validacin de los parmetros recogidos de los
formularios deber realizarse siempre en el servidor (emplear, por
ejemplo, JavaScript en el cliente para validar campos de un formulario
antes de enviarlos incrementa usabilidad y no esperar a la respuesta del
servidor para temas de experiencia del usuario). Se deber sanitizar los
datos recogidos en un formulario para evitar que el atacante juegue con
el encoding de los caracteres que estara enviando. Se deber utilizar
libreras con soporte para sanitizar los parmetros del usuario, por
ejemplo OWASP.

Apndice 13
Pgina 5 de 23

La seguridad de los sistemas debe estar regida por el diseo de

Arquitectura de Seguridad del SAT.
Para la autorizacin los usuarios sern clasificados en varios tipos, es

decir, a travs de roles para el acceso a las opciones de trabajo definidas
para cada rol, debern los sistemas restringir acceso derivado del rol
obtenido de directorio de identidades institucional, es decir el control de
acceso implementado debe permitir asignar y control los perfiles para
cada uno de los roles identificados. Los roles debern generarse de
acuerdo a los que negocio SAT defina.
El sistema deber contar con mecanismos que permitan el registro de

actividades con identificacin de los usuarios que los realizaron.
El sistema debe contar con pistas de auditora de las actividades que se

realizan sobre el sistema con niveles razonables para su reconstruccin
e identificacin de los hechos
El sistema debe validar automticamente la informacin contenida en

los formularios de ingreso. En el proceso de validacin de la informacin,
se deben tener en cuenta aspectos tales como obligatoriedad y
coherencia.
El sistema con control de acceso debe estar restringido, usuario y

contrasea, fiel o ambos en base al mecanismo que defina Negocio.
El sistema deber de rechazar accesos o modificaciones no autorizadas.
El sistema deber generar pistas de auditora referentes a los procesos

del sistema. El sistema deber apegarse a las normas para la
construccin de aplicaciones con pistas de auditora emitidas por la
ACSMC, las cuales sern proporcionadas por la administracin monitoreo
y control.
Disponibilidad de funciones. Dentro de la interfaz, las funciones

disponibles que se mostraran sern aquellas para las cuales tiene
permiso el usuario de acuerdo a su perfil. Es responsabilidad de la
aplicacin la implementacin este control.
El aplicativo debe estar en un esquema de alta disponibilidad.

Apndice 13
Pgina 6 de 23

Ejecucin de pruebas en ambientes apropiados y proteccin de

informacin. Todas las actividades de pruebas debern separarse de los
sistemas de produccin.
Toda la informacin usada para probar los sistemas se deber proteger

de acuerdo con las polticas de SAT considerando los convenios de
confidencialidad y la responsabilidad sobre el uso de esta.
Anlisis forense de cambios, los cuales debern apegarse a las

definiciones que proporcione la ACSMC por medio de la administracin
de control y monitoreo.
Los aplicativos debern apegarse a las definiciones para la

implementacin de pistas de auditora que debern solicitar para su
implementacin a la Subadministracin de Auditora de TI, de la ACSMC.
Los aplicativos que quieran consultar informacin para identificacin del

contribuyente (IdC) debern utilizar el web service de SISE para el tema
de los proteccin de los contribuyentes polticamente y econmicamente
expuestos (PPEs).
Envo de pistas de auditora a correlacionador. Los servicios deben contar

con mecanismos para enviar la informacin de las pistas de auditora al
correlacionador. Los mecanismos y definiciones debern de solicitarse a
la Subadministracin De Auditora De TI de la ACSMC.
Administracin de roles y permisos por el directorio institucional vigente.

Esta es la herramienta que se usar para administrar los roles y
permisos, para centralizar y tener ms control de las identidades para la
autorizacin y proporcionar SSO Y SLO.
Los atributos que el directorio institucional puede proporcionar sern

solamente los obtenidos de las fuentes oficiales RH y RFC ampliado.
Para la autenticacin y autorizacin los sistemas debern integrarse a

los componentes de control de acceso y directorio institucional vigente,
con el fin de tener centralizada la autenticacin y tener ms control.
Establecimiento de controles de seguridad y confidencialidad. Las

aplicaciones deben proveer controles de seguridad y confidencialidad
apropiados, debern apegarse a las definiciones que brinde la ACSMC
por medio de la Administracin de Arquitectura de Seguridad.

Apndice 13
Pgina 7 de 23

Es responsabilidad del lder de proyecto notificar formalmente si la

aplicacin decide no integrarse al control de acceso y directorio
institucional. Mediante un documento formal deber de especificar quin
es el responsable de esas identidades y quin firmar las responsivas de
creacin de identidades como roles y perfiles de ese aplicativo fuera de
los estndares.
Control de acceso a aplicaciones por medio de roles. El control de acceso

a las aplicaciones y servicios debe ser establecido por medio de roles
con apego al directorio institucional.
Acceso autorizado a datos. Los servicios debern contar con

mecanismos para que los usuarios estn estrictamente limitados a los
elementos de los datos a los que tienen acceso autorizado, es
responsabilidad de la aplicacin control lo anteriormente mencionado.
Las aplicaciones, ya sea por el ciclo de software o productos de caja

(commercial
off-the-shelf
(COTS)),
debern
de
soportar
enmascaramiento de direcciones IP, es decir soportar, NAT (Network
Address Translation).
El responsable del aplicativo deber de vigilar el parcheo de

vulnerabilidades de los sistemas operativos que conforman su aplicativo
Evitar el uso de cuentas de administracin del sistema operativo para los

ambientes de ejecucin de productos y tecnologas. Se requiere que el
usuario utilizado para la administracin de los productos tecnolgicos de
la arquitectura no sea realizado con cuentas de administracin del
sistema operativo (SA, root, administrador). Se deber crear una cuenta
especfica para la administracin del producto restringida a sus
responsabilidades.
Se requiere la definicin de los servicios, puertos,

e IP's destino en cada una de las aplicaciones
liberarse a produccin, el cual deber de contar
arquitectura (modelo de sembrado fsico,
especificacin de arquitectura).
Las aplicaciones debern tener ambientes no productivos y productivos

para que estn en posibilidad de probar o actualizar su aplicacin sin
afectar produccin.
protocolos, IP's origen

o sistemas, previo a
con los artefactos de
flujos unifilares y

Apndice 13
Pgina 8 de 23

Las aplicaciones debern siempre pasar por el anlisis de

vulnerabilidades y atender los problemas de color rojo para poder salir a
produccin.
Se deber generar las configuraciones de los servidores para solamente

habilitar caractersticas que se utilizarn, generando un hardening en
sus servidores a utilizar.
Toda comunicacin que requiera autenticacin o que contenga

informacin sensible y/o confidencial deber estar cifrada. El rea de
negocio del SAT duea de la informacin ser la encargada de clasificar
el tipo de informacin.
Aquellos datos que se envan desde un portal web (cliente) hacia el

servidor web, deben de utilizar algn tipo de cifrado (enmascaramiento
de cookies) para evitar que se sobrescriban o se tenga una traslape de
dominios. Deber ser responsabilidad del control de acceso institucional
proporcionar esa funcionalidad y utilizar el protocolo de cifrado HTTPS.
Cifrado de cookies. Siempre que viaje una sesin de acceso vlida al

sistema o informacin sensible, el cifrado de cookies deber ser
generada por el aplicativo y deber siempre estar en HTTPS
Algoritmos de Cifrado de informacin utilizados en el SAT. Con base en la

clasificacin de la informacin proporcionada por Negocio SAT, por lo que
deber determinarse si la informacin debe ser cifrada, los Algoritmos
de Cifrado utilizados por el SAT son los siguientes:
Criptografa simtrica - tamaos de llave de 192 bits como mnimo

o superior.
Diffie Hellman. Mtodo para generar llaves simtricas de forma

aleatoria.
Criptografa asimtrica RSA - 2048 bits como mnimo o superior
Firmas digitales. Su razn principal es asegurar la integridad y no

repudio de las transacciones. Las debern utilizar los aplicativos que
deseen asegurar la integridad y no repudio de envi de informacin por
parte del contribuyente.
o
La Firma Electrnica Avanzada (Fiel) es un archivo digital con un

conjunto de datos y caracteres que permite
identificar al

Apndice 13
Pgina 9 de 23

contribuyente al realizar trmites por internet en el SAT e incluso

en otras dependencias del Gobierno de la Repblica, la cual
produce los mismos efectos jurdicos que la firma autgrafa.
o
La Fiel es nica, es un archivo seguro y cifrado que (equivale a la

firma caligrfica del contribuyente.
Por sus caractersticas, es segura y garantiza la identidad.
Se debern siempre asegurar que su diseo se base en el uso de

dos claves o llaves (cifrado asimtrico) para el envo de mensajes:
la llave privada, que slo deber de conocer y poseer el titular de
la Fiel, (la cual sirve para asegurarla integridad y no repudio por
parte del contribuyente) y la llave pblica, para consulta libre.
Digestin. Una funcin hash es un algoritmo que transforma ("digiere")

un conjunto arbitrario de elementos de datos, como puede ser un
archivo de texto, en un nico valor de longitud fija (el "hash"). El valor
hash calculado puede ser utilizado para la verificacin de la integridad
de copias de un dato original sin la necesidad de proveer el dato original.
Esta irreversibilidad significa que un valor hash puede ser libremente
distribuido o almacenado, ya que slo se utiliza para fines de
comparacin. Se deber utilizar el algoritmo SHA-2 a 256 como mnimo o
superior.
Para el cifrado se deber utilizar la biblioteca SgiCripto, , la cual se ocupa

en diversos proyectos SAT, y que est desarrollada para facilitar y
realizar actividades criptogrficas como:
o
o
o
o
o
o
Cifrado Asimtrico.
Cifrado Simtrico.
Conexin Cliente ARA.
Digestin.
Firma.
Sobres.
Las aplicaciones que requieran la firma electrnica para autenticacin

autnoma va firma electrnica avanzada (Fiel) o firmado de documentos
para asegurar el no repudio debern considerar la re-compilacin cada
determinado tiempo para soportar el crecimiento del tamao de los
certificados. Debern soportar llaves de 1024, 2048 y 4096 a partir de la
presente publicacin de este documento.

Apndice 13
Pgina 10 de 23

Los mecanismos de autenticacin y proteccin en Web Services debern

estar apegados a los utilizados en los XML Gateway que cuente la
institucin. Los web services debern considerar el uso de mecanismos
de autenticacin como WS-Security 1.1 con WS-Policy o mutual
autentication por certificados auto generados por el SAT.
Cifrado de usuario y password. Estos debern siempre viajar en un canal

seguro de comunicacin. Los datos de usuario y password deben viajar
encriptados o por un canal seguro cuando sean transmitidos por internet
o en red interna.
Utilizacin del protocolo de HTTPS para transacciones expuestas a

Internet.
Para las pginas web que son para el pblico en general que son de slo
consulta no existe el requerimiento de mecanismos de encriptacin o
canal seguro, solamente uso de CAPTCHA obligatorio.
Anlisis de vulnerabilidades sobre aplicaciones. Se requiere la ejecucin

de anlisis de vulnerabilidades y pruebas de seguridad exhaustivas
sobre las aplicaciones para validar que se est entregando una
aplicacin segura.
Alineacin a las reglas de construccin de contraseas definida por el

SAT, la ACSMC Y por la AMIF (Administracin de Manejo de identidades
y Fiel) Los protocolos de transmisin de datos aprobados por seguridad
de la informacin por canal seguro son:
o
o
o
o
o
o
o
Socket de seguridad.
SFTP.
HTTPS.
SMTP / (SSL / TLS).
(JMS MQ) / (SSL / TLS).
SSH (siempre y cuando sea por puerto diferente para el puerto 22
para la red productiva, para la red administrativa si es permitido el
puerto 22.
SSL.
Autorizacin de usuarios centralizada. Se requieren mecanismos para

realizar las autorizaciones de usuarios del sistema de forma centralizada
y por medio de la administracin central de seguridad monitoreo y
control.

Apndice 13
Pgina 11 de 23

Para el control de acceso en COTS (producto de caja) de MQ deber ser

restriccin IP homologada, listas de control de acceso (ACL) o
certificados y canal seguro SSL.
Para el esquema de intercambio de informacin por MQ se debe cifrar el

canal
por
SSL
bajo
el
algoritmo
de
cifrado
SSL_RSA_WITH_AES_128_CBC_SHA con FIPS.
La autenticacin para el intercambio de informacin por MQ se debe

realizar bajo un esquema de intercambio de certificados.
Utilizacin de Selladora Digital para transacciones exitosas a las

aplicaciones que requieran entregar un acuse por parte del SAT.
Actualmente en el SAT se utiliza la Selladora Digital de tal forma que
todos los acuses que salen del SAT implementan este servicio. Se
requiere evaluar la implementacin de este servicio para las
transacciones exitosas, en caso de que aplique.
Se deben de considerar perfiles para el acceso a los datos.
Criterios para aplicacin de controles de seguridad. Los requerimientos

de seguridad estarn basados sobre los requerimientos del negocio, no
sobre requerimientos tcnicos.
Aplicacin de mecanismos estndares de seguridad. Se requiere el uso

de mecanismos de seguridad estndares en la instrumentacin de los
sistemas de seguridad de la informacin.
Vigencia de mecanismos estndares de seguridad y aplicacin a

sistemas. Todos los sistemas deben trabajar con mecanismos estndares
actuales.
Acceso a sistemas por medio de autenticacin. Todo acceso a cualquier

sistema de cmputo deber ser autenticado y apegado a los
lineamientos vigentes de la arquitectura de seguridad institucional.
En caso de que se requieran hacer respaldos por medio de la red, se

deber utilizar una tarjeta de red especfica.
Las nuevas soluciones tecnolgicas debern de entregar los artefactos

de arquitectura e integrar y plasmar las definiciones que proporcione
arquitectura de seguridad con apego a Marco Documental vigente.

Apndice 13
Pgina 12 de 23

Lineamientos para algoritmos de Cifrado. El tipo de algoritmos de

Cifrado deber definirse en conjunto con Arquitectura de seguridad SAT,
tomando en consideracin la funcionalidad requerida, esquemas de
transferencia, almacenamiento y otros temas.
Seguridad de Comunicacin.
La seguridad de comunicaciones de los sistemas debe estar regida por el
diseo de la Administracin de Arquitectura de Seguridad del SAT y
Administracin de Seguridad Operaciones.
La seguridad perimetral de los sistemas o sitios alternos que estn fuera

de los centros de datos SAT deber ser definida y justificada. Si se
decide que una nueva solucin tecnolgica est hospedada en un lugar
distinto a los servicios de seguridad perimetral de los centros de datos
SAT, se deber proporcionar la Arquitectura de Red para que sea
revisada por la ACSMC por su Administracin de Seguridad Operaciones.
Mdulo de Acceso y Frontera de Seguridad Terceros. deber cumplir lo

siguiente:
o
o
o
o
o
o
o
o
Interconexin de los enlaces de comunicaciones de datos con los

proveedores autorizados de terceros o enlaces directos con las
distintas dependencias pblicas o privadas que requieran
consumir o proveer servicios con el Centro de Datos del SAT.
Protocolos de enrutamiento. Proveer controles de seguridad para
mitigar los riesgos de ataques e intrusiones informticas
provenientes de los proveedores que brindan servicios
especializados al SAT.
Fuentes conocidas.
Proteccin a nivel Capa 4 del modelo de OSI.
Enmascaramiento de direccionamiento privado.
Mecanismo de recepcin y proteccin mediante tneles de acceso
remoto (Gestin).
Redes perimetrales.
Proveer conectividad a aplicaciones especializadas.
Facilitar la comunicacin entre los distintos proveedores que
otorgan servicios especializados al SAT.
Todas las entidades externas que requieran un enlace dedicado con el

SAT en cualquiera de sus centros de datos, se debern apegar al
documento Normatividad de Conexin de Terceros.
Se deber utilizar mecanismos para la alta disponibilidad, tolerancia a

fallos y distribucin de carga, utilizando mecanismos como balanceos

Apndice 13
Pgina 13 de 23

fsicos o lgicos. Se requiere considerar que dentro del SAT se utilizan

algoritmos de balanceo fsicos tales como Round Robin o Least
Connections por medio de los balanceadores de carga a travs de una
VIP y su utilizacin deber de revisarse con arquitectura de seguridad
para su implementacin mediante la incorporacin de balanceadores
fsicos.
Restriccin de flujos para salvaguardar la informacin

o
o
o
o
o
o
o
o
o
No se permiten flujos de la capa de presentacin a la capa de

datos.
No se permiten flujos de la red interna (mpls/VPN/red interna SAT)
a la capa de datos.
No se permiten flujos de internet a la capa de datos.
No se permiten flujos por puertos indefinidos como any to any.
No se permiten flujos por los puertos 22, 3389 en la red
productiva.
Para servicios pblicos utilizar puertos well know.
No se permiten flujos entre diferentes ambientes, por ejemplo del
direccionamiento de desarrollo a UAT o viceversa o de UAT o
viceversa; de UAT a estrs o viceversa y/o de produccin a no
productivo.
Todos los flujos que sean requeridos para administracin y
configuracin remota a los servidores que se encuentran en los
centros de datos sern solamente a travs de las IP
administrativas y va perfil de VPN.
Para el que las entidades externas puedan consumir servicios web
del SAT debern de proporcionar IP homologada para restringirlos
a travs de sta, adicionalmente a los mecanismos de control de
acceso.
Los sistemas debern apegarse a la arquitectura de los centros
datos del SAT, y respetar su divisin de tres capas como mnimo,
las cuales debern estar divididas por una capa de seguridad, es
decir un firewall, y cada capa deber tener una VLAN asignada.
SSL 2048
HTTPS es un protocolo de aplicacin basado en el protocolo HTTP,
provee un medio seguro de comunicaciones basado en SSL/TSL
para crear un canal seguro de comunicacin para el trfico de
informacin. Se debe utilizar para la cifrado asociada a HTTP un
certificado de clave pblica de al menos 2048 bits para el
transporte SSL/TSL.
Distribucin en capas y manejo de IP virtuales Los servicios debern

considerar que deben estar diseados y distribuidos en capas de

Apndice 13
Pgina 14 de 23

seguridad y se debern manejar IP virtuales con manejo de NAT en

ambos sentidos.
Comunicacin entre equipos mediante FQDN. La comunicacin hacia

servicios debe ser por medio FQDN (Fully Qualified Domain Name), para
evitar ligar aplicaciones a IP y lograr que exista mayor movilidad en la
aplicacin.
Se requiere la definicin de los servicios, puertos, protocolos, IP origen e

IP destino en cada una de las aplicaciones o sistemas, previo a liberarse
a produccin, el cual deber de contar con los artefactos de arquitectura
(Modelo de sembrado fsico, flujos unifilares y especificacin de
arquitectura).
Las aplicaciones debern tener ambientes no productivos y productivos

para que estn en posibilidad de probar o actualizar su aplicacin sin
afectar produccin.
Separacin de trfico y uso de tarjetas de red independientes. La

configuracin de los equipos servidores debe considerar el uso de
tarjetas de red diferentes para produccin y administracin.
Restriccin de administracin remota va web. No se permite el uso de

administracin remota va internet, slo podr ser realizada va intranet
del SAT hacia las tarjetas administrativas y desde los servidores
previamente autorizados por el SAT.
Utilizacin de HTTPS para transacciones expuestas a Internet. Los

servicios relacionados con transacciones deben considerar la utilizacin
de HTTPS. Los protocolos de transmisin de datos aprobados por
seguridad de la informacin por canal seguro son:
o
o
o
o
o
o
o
Socket de seguridad.
SFTP.
HTTPS.
SMTP / (SSL / TLS).
(JMS MQ) / (SSL / TLS).
SSH (siempre y cuando sea por puerto diferente para el puerto 22
para la red productiva, para la red administrativa si es permitido el
puerto 22).
SSL.
Separacin de trfico y uso de tarjetas de red independientes. La

configuracin de los equipos servidores debe considerar el uso de

Apndice 13
Pgina 15 de 23

tarjetas de red diferentes para produccin, administracin y el IP

Storage. Este requerimiento est relacionado con la configuracin de las
VLANs.
Acceso remoto a aplicaciones e infraestructura del SAT. El acceso remoto

debe estar apegado a procedimientos y normatividad del SAT.
Configuracin de VLANS. Se requiere

configuracin de VLANs.
o
o
o
o
que el diseo maneje la
VLAN para administracin y mantenimiento de Servidores.

VLAN para ambiente productivo.
VLAN para respaldo.
Las VLAN debern ser por servicio y por capa, adicionalmente los
diferentes servidores debern tener VLAN independientes para
cada red (Produccin, Heart Beat, IP Storage, Gestin).
Comunicacin entre centros de datos. Se debern utilizar mecanismos

de cifrado. La comunicacin entre centros de daros debe ser cifrada,
utilizando socket de seguridad, https, SSL, SSH o IPSEC tunnel. Los
protocolos de cifrado debern utilizar siempre el enlace L2L.
Justificacin.
Todos los Servicios de Tecnologa de Informacin (TI) en algn punto de su ciclo
de vida, necesitan considerar los requerimientos no funcionales y las pruebas
asociadas a los mismos. Para algunos proyectos, estos requerimientos implican
una cantidad considerable de trabajo y esfuerzos, mientras que para otros no,
pero son necesarios para mitigar vulnerabilidades y controlar amenazas.
Excepcin.
No se tienen consideradas excepciones por el momento, sin embargo, se
analizarn los requerimientos y en caso de ser necesaria una excepcin, se
atender de forma particular.
Impacto.
Todas las soluciones tecnolgicas nuevas debern de cumplir con los
requerimientos no funcionales de seguridad que aplican para su solucin
tecnolgica. Todo desarrollo que se encuentre en fase de arquitectura, diseo o
en ambiente de desarrollo deber alinearse a esta decisin a partir de la fecha
de aplicacin de la presente decisin arquitectnica especificada en la cartula
del presente documento.
Implementacin.
Apndice 13
Pgina 16 de 23

La presente decisin se incorpora al Marco Tecnolgico de Referencia para su

publicacin formal y entrada en vigor, lo que permitir su consulta para guiar
su desarrollo e implementacin los nuevas soluciones tecnolgicas SAT,
permitiendo de forma proactiva que se conozcan los requerimientos no
funcionales de seguridad por parte de los participantes en el ciclo de vida de
software y que se implementen los controles de seguridad necesarios para
nuevos sistemas.
2. Requerimientos de Seguridad para PITA

Como parte de su propuesta tcnica y econmica el proveedor PITA, deber
definir y proporcionar un diseo de bajo y alto nivel en los que se incluya el
cumplimiento de los requerimiento de seguridad descritos en la presente
seccin, incluyendo al menos las vistas: sistemas; comunicaciones; hardware y
software (infraestructura tecnolgica procesamiento y almacenamiento-);
seguridad perimetral y aplicativa; y mecanismos para asegurar la
instrumentacin de las posiciones de servicio (carga, ligeros y video-vigilancia).
El proveedor PITA deber considerar como parte de la solucin PITA, de manera
enunciativa ms no limitativa, proveer la seguridad a travs de los siguientes
puntos (en todo momento cumpliendo con los Requerimientos no Funcionales
de Seguridad mencionados en el apartado 1 de este documento):
2.1.
Seguridad Perimetral
Firewalls, en esquemas de alta disponibilidad en los Centros de Datos y

Puntos Tcticos que integren la solucin PITA, con la finalidad de
satisfacer las necesidades de funcionalidad, proteccin y control de
trfico en la red de PITA (de manera almbrica e inalmbrica), a travs
de mecanismos de seguridad tales como: bloqueo de accesos no
autorizados; cifrado-descifrado de trfico; admisin y denegacin de
accesos; con el objetivo de garantizar la integridad, confidencialidad y
disponibilidad de la informacin e infraestructura tecnolgica, albergada
en los puntos tcticos de carga, vehculos ligeros y de video vigilancia,
de conformidad con la arquitectura de referencia, con los
Requerimientos No Funcionales de Seguridad y dems lineamientos del
SAT.
Sistema de Prevencin de Intrusos (IPS), en esquemas de alta

disponibilidad en los Centro de Datos y Puntos Tcticos que integran la
solucin PITA, con la finalidad de satisfacer las necesidades de
proteccin y filtrado de trfico en la red LAN de PITA, de modo que se

Apndice 13
Pgina 17 de 23

garantice la confidencialidad, integridad y disponibilidad de la

informacin e infraestructura tecnolgica albergada en los puntos
tcticos del proyecto PITA, y en los sistemas de tecnologas de
informacin contra ataques y amenazas; todo de conformidad con la
arquitectura de referencia, con los Requerimientos No Funcionales de
Seguridad y dems lineamientos del SAT.
Balanceo de cargas y cifrado TLS, en esquemas de alta

disponibilidad en los Centro de Datos y Puntos Tcticos en los que se
requiera para la solucin PITA, con la finalidad de satisfacer las
necesidades de balanceo de cargas de redes, servidores, etc. En
complemento se debe proporcionar comunicacin segura por la red de
PITA a travs de la creacin de un canal seguro mediante la seguridad de
la capa de transporte (TLS); todo lo anterior de conformidad con la
arquitectura de referencia, con los Requerimientos No Funcionales de
Seguridad y dems lineamientos del SAT.
2.2.
Consideraciones Generales
Como parte de la solucin PITA, el proveedor PITA deber satisfacer las

siguientes necesidades de seguridad, conforme a los Requerimientos No
Funcionales de Seguridad descritos anteriormente:
Todas las telecomunicaciones relativas a la solucin PITA tanto en los

Centros de Datos como en el Punto Tctico deben ser aseguradas
mediante mecanismos de cifrado.
La informacin que el SAT clasifique como confidencial deber ser

cifrada tanto en transporte como en el cuerpo del mensaje, en trnsito o
en reposo; a travs de mecanismos de secreto compartido,
administracin de llaves o las que se definan durante la fase de mesas
de planeacin de arranque.
Contar con proteccin y control para inspeccin de trfico incluyendo

cualquier tipo de mensaje y en los componentes e instrumentacin de
las posiciones de servicio (carga, ligeros y videovigilancia) de la solucin
PITA.
Contar con mecanismos de autenticacin y proteccin de Web Services,

incluyendo WS-Security mediante certificados que deben ser generados
por el SAT y que el proveedor PITA deber entregar el Certificate Signed
Request (CSR) y especificar su versin y uso.

Apndice 13
Pgina 18 de 23

Cada uno de los dispositivos deber generar bitcoras y pistas de

auditoria los cuales se debern integrar a donde el SAT lo determine.
Realizar el parcheo automtico de vulnerabilidades para Posiciones de

Monitoreo, Equipos Mviles, servidores y cualquier componente de la
solucin PITA que lo requiera.
Contar con Base Line de seguridad y realizar un hardening para las

Posiciones de Monitoreo, Equipos Mviles, servidores y cualquier
componente de la solucin PITA que lo requiera.
Realizar la inspeccin de contenido http o https y en general la

proteccin de los aplicativos web de la solucin PITA.
Realizar la proteccin de los aplicativos expuestos o con salida a internet

por red interna, el detalle se dar a conocer en las mesas de planeacin
de arranque.
El proveedor PITA debe llevar a cabo la integracin necesaria con el o los

DNS que el SAT indique, para la resolucin de nombres de dominio que
la solucin PITA requiera.
El proveedor PITA debe llevar a cabo la integracin necesaria con los

servidores NTP que el SAT indique, para la sincronizacin que la solucin
PITA.
El proveedor PITA en sus componentes deber generar SSL/TLS OFF

LOADING, el certificado WILDCARD para un subdominio SAT deber ser
solicitado y gestionado al SAT.
Se requiere que el proveedor PITA proporcione proteccin para

posiciones de monitoreo para Equipos Mviles
El proveedor PITA deber realizar pruebas de vulnerabilidad (caja blanca,

negra y de penetracin) en las aplicaciones desarrolladas por el
proveedor PITA para la solucin PITA, asimismo las vulnerabilidades que
se detecten se debern atender antes de salir a produccin y de manera
inmediata las denominadas crticas o de color rojo.

Apndice 13
Pgina 19 de 23

2.3.
Solucin de Proteccin
Como parte de la solucin PITA, el proveedor PITA deber satisfacer las

siguientes necesidades de seguridad ligadas a las soluciones de proteccin,
conforme a los Requerimientos No Funcionales de Seguridad descritos
anteriormente:
Proporcionar proteccin de Antivirus y Host IPS para las Posiciones

Monitoreo y Equipos Mviles de la solucin PITA, con la finalidad
brindar proteccin contra malware y amenazas que puedan poner
riesgo la funcionalidad o comprometer la seguridad en la actividad de
usuarios o la de la propia red de PITA o del SAT.
Proporcionar proteccin de Host IPS para servidores incluyendo: firewall

a nivel servidor; deteccin y prevencin de intrusos tambin a nivel
servidor; antimalware; monitoreo de cambios en archivos; monitoreo de
cambios de archivos y carpetas criticas del sistema y aplicaciones;
asimismo deber tener la capacidad para hacer inspeccin de las
bitcoras generadas por el sistema operativo y aplicaciones, a fin de
garantizar el correcto funcionamiento y proteccin de los servidores de
PITA.
Llevar a cabo toda actividad de remediacin en infecciones de virus,

malware, cdigo malicioso, etc. relacionados con la proteccin de las
Posiciones de Monitoreo y Equipos Mviles, as como de los servidores de
la solucin PITA, sern su responsabilidad, previa validacin y
autorizacin del SAT.
Entregar y desplegar de las actualizaciones contra antivirus, cdigo

malicioso, malware, etc. relacionados con la proteccin desde el nivel
central y de forma automatizada en cada uno de los Posiciones de
Monitoreo y Equipos Mviles, as como de los servidores de la solucin
PITA sin afectar la operacin del SAT.
Mantener actualizadas en todo momento las Posiciones de Monitoreo y

Equipos Mviles, as como de los servidores de la solucin PITA con la
ltima versin o actualizacin de antivirus, Host IPS liberada por el
fabricante.
Realizar la prevencin de perdida de informacin en las Posiciones de

Monitoreo y Equipos Mviles con el fin de detectar y evitar la fuga y/o
prdida de informacin sensible de los equipos, la cual debe estar
integrada a las Posiciones de Monitoreo y Equipos Mviles de la solucin
de
de
en
los

Apndice 13
Pgina 20 de 23

PITA, para una completa visualizacin y prevencin en distintas capas de

seguridad, considerando: medios de almacenamiento removibles,
storage, discos fsicos y virtuales, correo electrnico, aplicaciones de
mensajera instantnea, transferencia de archivos e impresin de
informacin.
o
Brindar el cifrado de dispositivos de almacenamiento de las

Posiciones de Monitoreo, Equipos Mviles y dems Dispositivos de
Almacenamiento de la solucin PITA.
Contener toda actividad sospechosa desde las soluciones de proteccin

consideradas.
Emitir alertas de incidentes y monitorear los eventos generados por los

el Antivirus y HOST IPS para Posiciones de Monitoreo y Equipos Mviles,
HOST IPS para los servidores de la solucin PITA.
Monitorear el cumplimiento de las polticas de uso de informacin

implementadas en la solucin PITA.
Notificar al gobierno del contrato de PITA sobre actividades sospechosas

relacionadas con la infeccin de Posiciones de Monitoreo y Equipos
Mviles, as como servidores de la solucin PITA.
Realizar el borrado seguro de informacin en las Posiciones de

Monitoreo, Equipos Mviles, servidores (fsicos o virtuales), y cualquier
medio de almacenamiento tales como storage, equipos de
almacenamiento en puntos tcticos, que integren la Solucin PITA en las
bajas o retiro de medios, y en general, cuando el SAT lo solicit y
determine. El borrado seguro debe garantizar el borrado completo e
irrecuperable de los datos.
El proceso de borrado deber generar un reporte verificable y protegido

contra una manipulacin no autorizada, contando con requisitos de
conformidad, regulacin y legalidad, proporcionando informacin tal
como estado del elemento a borrar, nmeros de serie y etiquetas de
activos relevantes, as como, quin ha llevado a cabo el proceso de
borrado.
Detectar y proteger contra amenazas avanzadas a la solucin PITA,

brindando una visibilidad de todos los dispositivos conectados a la red
PITA, aun cuando estos dispositivos sean de terceros, proporcionando un
anlisis del incidente, detectado y retroalimentando automticamente a
la infraestructura de seguridad relativas a Antivirus y Host IPS para

Apndice 13
Pgina 21 de 23

Posiciones de Monitoreo y Equipos Mviles, Host IPS para Servidores y

Prevencin de Prdida de Informacin.
Proporcionar proteccin a las bases de datos de la solucin PITA en

tiempo real, contra amenazas y ataques avanzados sobre las bases de
datos que el SAT determine, en el esquema en-lnea o fuera de lnea.
Enmascarar informacin de acuerdo a su clasificacin para ambientes de

prueba.
Los respaldos de informacin, deben estar cifrados.
Generar, administrar y explotar las bitcoras, hacer la integracin de

fuentes de informacin a la solucin de Correlacin de PITA y realizar la
correlacin de eventos, considerando que deber integrar los
dispositivos seguridad perimetral, bases de datos, sistemas operativos,
aplicativos, herramientas de proteccin, y toda fuente que el SAT
determine.
Proteccin de RFID a travs de la prevencin y contencin ataques por

interrupcin de comunicacin o aislamiento de etiquetas, suplantacin
mediante informacin falsa incluyendo spoofing, insercin de comandos
ejecutables en la memoria de datos de una etiqueta, repeticin de una
seal que reproduce la seal de una etiqueta vlida, denegacin de
servicio (DoS y DDoS) por saturacin del sistema, desactivacin o
destruccin de etiquetas mediante campos electromagnticos, clonacin
de tarjetas RFID, ataques mediante inyeccin de SQL o XML mediante la
comunicacin entre la etiqueta y el lector, cdigo malicioso (malware),
ataques man in the middle (MIM), entre otras, conforme a los estndares
internacionales vigentes de Seguridad sobre la materia.
Proteccin WLAN a travs de mecanismos de autenticacin y cifrado y

seguridad a la medida.
2.4.
Administracin de Identidades de la Solucin PITA
El proveedor PITA debe llevar a cabo la integracin con el sistema de

identidades del SAT (Autenticacin y Autorizacin) a nivel WEB
(empleados SAT).
Todos los componentes de infraestructura a nivel de autenticacin y

autorizacin de la solucin PITA sern responsabilidad del licitante

Apndice 13
Pgina 22 de 23

ganador conforme
confidencialidad.
los
niveles
de
servicio
al
convenio
de
El proveedor PITA deber proporcionar una solucin de control de acceso

para claves de usuarios que accedan a los servidores y a sus servicios
(Sistema Operativo, Base de Datos, por mencionar algunos), que se
definan en las mesas de planeacin de arranque, que permita el
monitoreo y auditoria sobre el acceso de usuarios.
Las Posiciones de Monitoreo y los Equipos Mviles debern estar

integradas al dominio institucional del SAT y con las polticas definidas a
nivel dominio.
2.5.
Solucin de Respaldo de Informacin
La informacin que aloja la solucin PITA deber contar con un solucin de

respaldos, los cuales debern estar cifrados con el algoritmo que el SAT defina
en las mesas de planeacin de arranque, por lo que proveedor PITA deber
contar con la solucin y con un procedimiento de respaldos que considere al
menos las fases de identificacin de la informacin a respaldar; tipo de
respaldo; periodicidad; generacin; validacin de integridad y funcionalidad; y
disponibilidad del respaldo.
Para el almacenamiento de los respaldos, el proveedor PITA deber habilitar y
acondicionar una cintoteca en el inmueble en donde se ubica el Centro de
Datos de la solucin a Nivel Central, el cual deber contar con las medidas de
seguridad fsicas y lgicas para asegurar la confidencialidad, integridad y
disponibilidad de la informacin almacenada en los respaldos.
El proveedor PITA deber determinar la arquitectura de la solucin de respaldo
y el medio de almacenamiento fsico que defina y autorice el SAT, en funcin a
la cantidad y criticidad de informacin de la solucin PITA.

Apndice 13
Pgina 23 de 23

Apéndice 13 - Arquitectura de Seguridad

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apéndice 13 - Arquitectura de Seguridad

Enviado por

Direitos autorais:

Formatos disponíveis

Administracin General de Aduanas

Administracin Central de Planeacin y

Proyecto de Integracin Tecnolgica Aduanera

El presente documento es de referencia y podr ser actualizado durante la

El propsito del presente documento es establecer los requerimientos no

Este documento est dirigido a todas las personas involucradas en el desarrollo

Administracin General de Aduanas

Fbricas de Desarrollo de software.

Anexo Tcnico del Proyecto de Integracin Tecnolgica Aduanera (PITA)

Administracin General de Aduanas

Son restricciones de los servicios o funciones ofrecidos por el

[1] Decisin Arquitectnica Requerimientos funcionales Tcnicos de Seguridad

En el alcance del Marco Tecnolgico de Referencia, el cumplimiento de lo

Administracin General de Aduanas

Como parte de las funciones que son competencia de la Administracin

Requerimientos No Funcionales de Seguridad.

Apegarse a las especificaciones Tcnicas vigentes de Seguridad que

Aplicacin de CAPTCHA en pginas web y mviles.

SHA256 (SHA2 256).

Se deben utilizar como algoritmos de integridad la funcin criptogrfica

HTTPS es un protocolo de aplicacin basado en el protocolo HTTP, provee

Anexo Tcnico del Proyecto de Integracin Tecnolgica Aduanera (PITA)

Administracin General de Aduanas

La informacin de negocio SAT siempre deber estar almacenada en la

Eliminar (Information disclosure) de los nuevos sistemas, mensajes de

Pruebas de vulnerabilidad (caja blanca, negra y de penetracin). Todas

Federacin de Identidades. Es obligatorio para los nuevos aplicativos que

Se requiere el intercambio de metadata entre los Ids (Identity

Los atributos requeridos del aplicativo deben ser incluidos en el

El sistema deber de mitigar y controlar ataques XSS (Cross Site

Anexo Tcnico del Proyecto de Integracin Tecnolgica Aduanera (PITA)

Administracin General de Aduanas

La seguridad de los sistemas debe estar regida por el diseo de

Para la autorizacin los usuarios sern clasificados en varios tipos, es

El sistema deber contar con mecanismos que permitan el registro de

El sistema debe contar con pistas de auditora de las actividades que se

El sistema debe validar automticamente la informacin contenida en

El sistema con control de acceso debe estar restringido, usuario y

El sistema deber de rechazar accesos o modificaciones no autorizadas.

El sistema deber generar pistas de auditora referentes a los procesos

Disponibilidad de funciones. Dentro de la interfaz, las funciones

El aplicativo debe estar en un esquema de alta disponibilidad.

Anexo Tcnico del Proyecto de Integracin Tecnolgica Aduanera (PITA)

Administracin General de Aduanas

Ejecucin de pruebas en ambientes apropiados y proteccin de

Toda la informacin usada para probar los sistemas se deber proteger

Anlisis forense de cambios, los cuales debern apegarse a las

Los aplicativos debern apegarse a las definiciones para la

Los aplicativos que quieran consultar informacin para identificacin del

Envo de pistas de auditora a correlacionador. Los servicios deben contar

Administracin de roles y permisos por el directorio institucional vigente.

Los atributos que el directorio institucional puede proporcionar sern

Para la autenticacin y autorizacin los sistemas debern integrarse a

Establecimiento de controles de seguridad y confidencialidad. Las

Anexo Tcnico del Proyecto de Integracin Tecnolgica Aduanera (PITA)

Administracin General de Aduanas

Es responsabilidad del lder de proyecto notificar formalmente si la

Control de acceso a aplicaciones por medio de roles. El control de acceso

Acceso autorizado a datos. Los servicios debern contar con

Las aplicaciones, ya sea por el ciclo de software o productos de caja

El responsable del aplicativo deber de vigilar el parcheo de

Evitar el uso de cuentas de administracin del sistema operativo para los

Se requiere la definicin de los servicios, puertos,