SSL es absolutamente la primera sugerencia correcta aquí, pero SSL solo no lo protege de:
-
Ataques directos como XSS, inyección SQL, inclusión remota de archivos
Si su aplicación es vulnerable a un ataque XSS, el código javascript se puede entregar a través de su conexión SSL al cliente, donde puede enviar los datos confidenciales a otro servidor controlado por un atacante y al mismo tiempo permitir que se realicen las solicitudes normales a través de SSL. enlace, o podría robar las credenciales del cliente e iniciar sesión como ellos. La inyección de SQL podría permitir al atacante recuperar los datos directamente de la base de datos u omitir la autenticación e iniciar sesión como el usuario en cuestión. RFI podría otorgarle al atacante una cuenta shell en su sistema que permitiría cualquiera o todos los anteriores.
-
Ataques fuera de banda, como registradores de claves y virus, tanto en los sistemas cliente como en el servidor.
Si está ejecutando un servicio vulnerable no relacionado en su sistema, como un servidor de correo desactualizado, un atacante podría atacar eso y obtener una cuenta de shell en su sistema. Un virus en su escritorio de trabajo podría robar sus credenciales la próxima vez que inicie sesión en su servidor. Un keylogger en el sistema del cliente podría robar sus credenciales, y aunque este no es técnicamente culpa suya, el cliente seguramente lo culpará de todos modos y le será difícil demostrar que no fue robado de usted.
-
Ataques de nuevo desarrollo contra SSL como BEAST, CRIME y Lucky Thirteen.
Es inevitable que haya un período de tiempo en el que seas vulnerable a este tipo de ataques. Su trabajo al proteger los datos de su cliente es:
- Mantente al tanto de los nuevos ataques conocidos que afectan a cualquier producto que uses.
- Evalúe cada uno lo antes posible y tome una decisión sobre si continuar ejecutando el servicio afectado o apagarlo hasta que haya un parche disponible. (Es posible que pueda delegar esta decisión a sus clientes).
- Actualice y / o parche lo antes posible.
Parece que eres un único administrador de sistemas que se preocupa por la seguridad, en lugar de un empleado dedicado exclusivamente a la seguridad, lo que significa que todo lo anterior es probablemente bastante desalentador. Una buena manera de enfocar esto sería clasificar cada una de las sugerencias que reciba en términos de valor e intentar implementar una cada mes aproximadamente. Establezca un marco de tiempo realista e intente ajustarse a él.
- Auditoría de código / pruebas de penetración del código que escribió su organización.
- Detección de intrusiones.
- Detección anormal del comportamiento del cliente (dirección IP desconocida, agente de usuario desconocido, etc.).
- Actualizaciones regulares y rápidas del sistema y del producto.
- Minimice la superficie de ataque (elimine los servicios innecesarios de su servidor).
- Cifrado de los datos cuando se almacenan en su base de datos y en cualquier copia de seguridad.
- Registro de cualquier tipo de acceso a los datos. Un buen software de base de datos y los controles apropiados del sistema operativo pueden imponer esto Esto puede ayudar a absolver la culpa si una infracción no fue su culpa y rastrear quién es el culpable y cómo ingresaron si fue su culpa.
- Seguridad generalizada en toda su organización.
El PCI-DSS contiene una buena lista de cosas que pueden mejorar su resistencia general a los ataques.
¿Cuál de estos implementos realmente dependerá del análisis de costo / beneficio y riesgo?
- ¿Cuánto valen los datos (o el cliente)?
- ¿Cuál es la probabilidad de una violación?
- ¿Cuánto cuesta la medida de seguridad?
- ¿Cuánto reduce la probabilidad de una infracción?