[LCFC] wml://security/audit/auditing.wml
Sin cambios desde el RFR.
Saludos
Laura Arjona
https://wiki.debian.org/LauraArjona
#use wml::debian::template title="Realizar una auditorÃa"
#use wml::debian::recent_list
#use wml::debian::translation-check translation="1.19" maintainer="juanma"
<p>Esta página le proporciona un vistazo somero de los pasos que son necesarios
para afrontar la auditorÃa de un paquete.</p>
<p>El primer paso es elegir un paquete que realmente necesite examinarse.
DeberÃa elegir uno cuya seguridad sea crÃtica.</p>
<p>DirÃjase a <a href="$(HOME)/security/audit/packages">la lista de
paquetes cuya auditorÃa es prioritaria</a> para encontrar
sugerencias que le ayudarán a tomar su decisión.</p>
<p>Una cosa que deberÃa tener clara es que <em>no</em> pretendemos que el
paquete se audite una sola vez. Es bueno que muchas personas elijan
examinar el mismo paquete, porque se demostrará que mucha gente piensa
que ese paquete es sensible a cuestiones de seguridad.</p>
<p>Permitiendo una selección de paquetes esencialmente aleatoria, simplificamos
la coordinación y eliminamos el problema de <q>¿cómo puede uno fiarse de que la
persona X ha hecho un buen trabajo?</q> (No lo necesitamos porque asumimos que
tarde o temprano alguien decidirá examinar el mismo programa).</p>
<h2>Comenzar la auditorÃa</h2>
<p>Tras tomar la decisión de los paquetes, tiene que comenzar la verdadera
auditorÃa.</p>
<p>Si no está seguro del tipo de problemas que tiene que buscar, comience
leyendo un libro sobre desarrollo de software seguro.</p>
<p><a href="http://www.dwheeler.com/secure-programs">Secure Programming for
Linux and Unix HOWTO</a> (n.t. en inglés) tiene información de calidad que
puede resultarle muy útil.
<a href="http://www.securecoding.org/">Secure Coding: Principles &
Practices</a>, de Mark G. Graff y Kenneth R. van Wyk (n.t. en inglés)
también es un excelente libro.</p>
<p>Aunque las herramientas son imperfectas, pueden ser extremadamente útiles para
encontrar posibles vulnerabilidades. DirÃjase a <a href="tools">la página de
herramientas de auditorÃa</a> para encontrar más información acerca de algunas
de las herramientas de auditorÃa disponibles y de cómo se usan.</p>
<p>Además de mirar el propio código, es buena idea leer la propia documentación
del paquete, e intentar instalarlo y usarlo.</p>
<p>Esto le deberÃa permitir urdir maneras de subvertir el comportamiento tÃpico
del programa.</p>
<h2>Informar de problemas</h2>
<p>Si descubre un problema en el paquete que está examinando, deberÃa
informar de ello. Cuando informe de un fallo de seguridad, intente
proporcionar también un parche, para que los desarrolladores puedan
repararlo cuanto antes. No es necesario facilitar una muestra de
ataque (lo que se suele llamar un <em>exploit</em> o una <em>prueba de
concepto</em>), ya que el parche deberÃa hablar por sà msimo. Suele
preferirse la inversión de tiempo en proporcionar un parche adecuado
que en facilitar un ataque con éxito que saque provecho del error.</p>
<p>Aquà tiene una lista con los pasos recomendados para cuando
encuentre un error de seguridad en Debian:</p>
<ol>
<li>Intente producir un parche para el error u obtener información
suficiente para que otros puedan determinar la existencia del fallo.
De forma ideal, cada fallo deberÃa contener una solución para el
problema que se ha descubierto, y que se haya probado y verificado
que ciertamente corrige el problema.
<p>Si no tiene una solución para el problema, lo mejor será que dé los máximos
detalles sobre el ámbito del problema, la severidad de la incidencia y la
información adicional que haya recopilado sobre ella durante su
análisis.</p></li>
<li>En primer lugar, compruebe si el error de seguridad está presente
en la versión estable de Debian o si puede estar presente en otras
distribuciones o en la versión original.</li>
<li>Según los resultados de la comprobación anterior, informe del
incidente:
<ul>
<li>Al desarrollador original, a través del correo electrónico de
contacto para seguridad. Proporcione el análisis y el parche.</li>
<li>Al equipo de seguridad de Debian, si el error está presente
la versión publicada de Debian. El equipo de seguridad de Debian le
suele asignar un <a
href="$(HOME)/security/cve-compatibility">nombre CVE</a> a la
vulnerabilidad. El equipo de seguridad se coordinará con otras
distribuciones de Linux si fuese necesario y se pondrá en contacto
con el responsable del paquete en su nombre. Una cosa que podrÃa
hacer usted es mandar también una copia del correo al responsable
del paquete. De todas formas, hágalo sólo cuando se trate de
vulnerabilidades de bajo riesgo (tiene más información abajo).</li>
<li>Si el error no está presente en la versión publicada de Debian
y la aplicación puede estar presente en otras distribuciones o
sistemas operativos, escriba a <a
href="http://oss-security.openwall.org/wiki/mailing-lists/oss-security">oss-security</a>
(una lista de correo pública usada para informar y debatir sobre errores de seguridad
que han sido previamente divulgados). No
tiene que hacer esto si ya ha enviado el fallo al equipo de seguridad
de Debian, puesto que este equipo también seguirá los pasos de esta
lista.</li>
<li>Si el error <strong>no</strong> está presente en ninguna de las
versiones publicadas por Debian y está absolutamente seguro de que la
aplicación <strong>no</strong> forma parte de ninguna otra distribución
ni sistema operativo, informe de ello a través del sistema de
seguimiento de fallos.</li>
</ul></li>
<li>Una vez que la vulnerabilidad sea pública (por ejemplo, cuando el
equipo de seguridad de Debian o cualquier otro proveedor haya emitido
un aviso) se rellenará un informe de fallo con toda la información
relevante en el sistema de seguimiento de fallos de Debian para seguir
la pista de las incidencias de seguridad en las versiones no publicadas
de Debian (esto es, <em>sid</em> o <em>en pruebas</em>). Esto lo
suele hacer el propio equipo de seguridad. De todas formas, si viera
que no se ha producido este paso o si no va a avisar de esto al equipo
de seguridad, puede informar usted mismo. Asegúrese de que la etiqueta
del fallo es la adecuada (use la etiqueta <em>seguridad</em>) y de que
ha definido la prioridad apropiada (normalmente, <em>grave</em> o
superior). Asegúrese también de que el tÃtulo del error incluye el <a
href="$(HOME)/security/cve-compatibility">nombre CVE</a> adecuado, si
es que se le ha asignado. De esta forma se le puede seguir la pista a
los errores de seguridad que se han corregido tanto en las versiones
publicadas como en las no publicadas de Debian.</li>
<li>Si lo desea, una vez que sea pública la incidencia, puede reenviar
esta información a listas de correo públicas de divulgación, como
<a href="https://lists.grok.org.uk/mailman/listinfo/full-disclosure">full-disclosure</a>
o
<a href="http://www.securityfocus.com/archive/1">Bugtraq</a>.</li>
</ol>
<p>Tenga en cuenta que estos pasos pueden variar según el riesgo
asociado con la vulnerabilidad que se encuentre. Tiene que valorar
el riesgo según:</p>
<ul>
<li>Se trate de una vulnerabilidad remota o local.</li>
<li>Las consecuencias del provecho que se pueda sacar de la
vulnerabilidad.</li>
<li>La popularidad y difusión del software que se vea afectado por la
vulnerabilidad.</li>
</ul>
<p>Se deben dar distintos pasos, por ejemplo, para informar de un
ataque local de enlaces simbólicos que sólo puedan aplicar los
usuarios autenticados y que sólo provea de una forma de dañar el
sistema que para informar de un desbordamiento remoto de buffer que
proporcione privilegios administrativos y esté presente en un
software popular y de gran difusión.</p>
<p>En la mayor parte de los casos, los errores de seguridad no se
deberÃan revelar hasta que se hayan corregido. Por tanto, <i>no</i>
informe de ellos por el <a href="https://bugs.debian.org/">sistema
estándar de seguimiento de fallos</a>. En su lugar, informe del
problema directamente al <a href="$(HOME)/security/">equipo de
seguridad</a>, que gestionará la publicación de un paquete actualizado
y, una vez corregido, informará de ello en el BTS.</p>
Reply to: