[RFR] wml://security/audit/auditing.wml

[Laura Arjona Reina <larjona99@gmail.com>]

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 &amp;
 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>