Los 10 errores más idiotas que un administrador de red puede cometer

Hoy encontré éste interesante artículo, el cual se basa en un estudio realizado por Verizon Business, donde se detectó que 90 brechas de seguridad representan 285 millones de los registros de sistemas comprometidos.
Según Carolyn Duffy Marsan (el autor del artículo) no seguir los ítems de esta lista sería, simplemente, estúpido.
A continuación planteo los puntos citados por Carolyn, complementandolos con mis comentarios.

1. No cambiar el password default de todos los dispositivos de red.
Muy a menudo las compañías tienen un server, un switch, un router o cualquier aparato de red con el password default, usualmente "password" o "admin".
Cambiar los passwords default es vital, éstos son conocidos por todo el mundo (si tenes acceso a google, tenes acceso a los passwords), con lo que cualquier persona, ya sea intencionalmente o "jugando", rompa configuraciones, obtenga datos sencibles o logre un dennial of service. Incluso, en muchos casos, este tipo de problemas es muy difícil de detectar (por ejemplo, quién se va a imaginar que cambiaron alguna configuración de un switch que está andando bien).
Increíblemente más de la mitad de los registros de sistemas comprometidos el año pasado se deben al uso de passwords defaults en dispositivos de red!

2. Compartir passwords entre múltiples dispositivos de red.
Usualmente se utilizan los mismos passwords en distintos servers, y muchas personas conocen el password. Este puede ser un buen password, pero una vez que se comparte entre varios sistemas, todos los sistemas están en riesgo.
Si el password es descubierto por un hacker, éste tendrá acceso a todos los sistemas y generar gravísimos daños.
Un password que es utilizado en múltiples dispositivos conlleva a ser conocido por múltiples personas, y mientras más personas lo sepan, más suceptible es a la ingeniería social, o incluso a terminar escrito en un papel pegado en un monitor... por más bueno que sea el password (digamos que tiene 50 caracteres con letras, números, y caracteres locos), termina siendo suceptible a ser descubierto.

3. Fallo al encontrar errores en código SQL.
El ataque más común, representando el 79% de todos los registros obtenidos, es sobre base de datos SQL conectadas a servidores Web. Los hackers logran acceder a estos sistemas ingresando comandos SQL a través de un formulario Web. Si el formulario está codificado de forma correcta, no debería aceptar comandos SQL, pero muchas veces los desarrolladores crean los llamados errores de SQL Injection.
Según Peter Tippett (quien colaboró en la creación del artículo), la forma más eficaz de prevenir estos errores es ejecutando un firewall de aplicación en modo "aprendizaje" para que pueda observar la forma en que los usuarios ingresan datos en los campos, y luego ponerlo en modo "operacional" para que comandos SQL no puedan ser inyectados en un campo.

4. No configurando sus listas de control de acceso.
Segmentar la red usando listas de control de acceso es la forma más fácil de asegurar que los sistemas se comuniquen sólo con los sistemas que deban.
El ejemplo más claro de esto son los accesos de terceras partes a nuestra red a través de VPN. Si este acceso estuviera limitado sólo a los sistemas que ese tercero necesita, el resultado de un ataque se limitaría a esos sistemas. Pero en general, un usuario que tiene acceso VPN tiene acceso a todos los sistemas de la red.
Según el reporte de Verizon, el 66% de los registros de sistemas comprometidos se podrían haber evitado si se hubieran tenido listas de control de acceso configuradas correctamente.

5. Permitiendo acceso remoto y software de administración no seguro.
Es muy común que se permitan accesos a nuestra red a través de software como SSH, VNC o PCAnywhere, los cuales suelen estár mal configurados, con passwords débiles.
Es importante rastrear todos estos accesos externos y agregarles medidas de seguridad extra como tokens o certificados en adición a los passwords.
Este problema es lo suficientemente común para sumar el 27% de los registros de sistemas comprometidos.

6. Fallo al testear aplicaciones no críticas en búsca de vulnerabilidades.
Casi el 80% de los ataques son el resultado de agujeros de seguridad en aplicaciones Web, según el reporte de Verizon. Los administradores saben esto, y por ello ponen todo su esfuerzo en testear dichas aplicaciones. El problema es que casi no se testean sistemas no críticos, convirtiéndolos en el punto de ataque para muchísimos hackers.
Por esto es importante que todas las aplicaciones sean testeadas en busca de vulnerabilidades básicas.
Según Tippett "la gente se focaliza en los sistemas críticos, pero los malos no saben que es crítico o no, ellos van a por lo fácil".

7. No proteger adecuadamente sus servidores de malware.
El malware en servidores se lleva el 38% de todas las brechas de seguridad. La mayoría del malware es instalado por atacantes remotos y es usado para capturar datos. Típicamente el malware es personalizado por lo que no suele ser descubierto por software antivirus. Una forma en que los administradores pueden descubrir keyloggers o spyware en sus servidores es ejecutando software de detección de intrusos (IDS) en cada server, no sólo en los críticos.
Tippett sugiere "cerrar" los servidores para que no se pueda instalar ni ejecutar ninguna aplicación nueva en ellos, y sólo abrirlos cuando haga falta instalar algo nuevo.

8. Fallo al configurar routers para prohibir tráfico saliente no deseado.
Una forma popular de malware involucra poner un backdoor o command shell en un servidor. Una forma de prevenir que un hacker tome ventaja de esto, es segmentando la red usando listas de control de acceso (ACL). De esta forma, se puede prevenir que los servidores no envíen datos que no deberían enviar. Por ejemplo, un servidor de e-mail debe enviar tráfico de e-mail, no SSH!. Otra forma es configurar los routers para negar todo tráfico saliente por default, dejando que salga sólo lo permitido.
Por suerte sólo 2% de las compañías cometen éste error.

9. No saber dónde se almacenan datos de tarjeta de crédito u otros datos de clientes.
La mayoría de las compañías creen saber dónde se almacenan datos críticos, y fortalecen estos servidores con los mayores niveles de seguridad. Pero a menudo estos datos están almacenados en algún otro lugar como un sitio de backup o en el departamento de desarrollo de software.
Son estos servidores secundarios, no críticos los cuales suelen ser atacados y llevan a la mayoría de los datos filtrados. Una forma fácil de saber dónde se almacenan datos críticos es realizando un descubrimiento de red, típicamente usando un sniffer.

10. No siguiendo los estándares de seguridad de datos en métodos de pago con tarjeta.
PCI DSS establece 12 controles para proteger los datos del dueño de una tarjeta, pero la mayoría de las personas no se preocupan en cumplir éstos estándares. Algunas veces las compañías siguen estos controles en los servers que saben que almacenan información de tarjetas, pero no en los servidores desconocidos que almacenan estos datos.
Si bien el 98% de los registros se corresponden con sistemas de pago con tarjeta, sólo el 19% de las organizaciones con brechas de seguridad siguen estos estándars.