<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comentarios en: WWW. Una ventana al mundo, una ventana para los intrusos</title>
	<atom:link href="http://www.securityartwork.es/2009/03/26/www-una-ventana-al-mundo-una-ventana-para-los-intrusos/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.securityartwork.es/2009/03/26/www-una-ventana-al-mundo-una-ventana-para-los-intrusos/</link>
	<description>Blog de Seguridad de la Información de S2 Grupo</description>
	<lastBuildDate>Sat, 11 Feb 2012 09:31:50 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Por: xavim</title>
		<link>http://www.securityartwork.es/2009/03/26/www-una-ventana-al-mundo-una-ventana-para-los-intrusos/comment-page-1/#comment-838</link>
		<dc:creator>xavim</dc:creator>
		<pubDate>Fri, 27 Mar 2009 11:38:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.securityartwork.es/?p=659#comment-838</guid>
		<description>Cultura de seguridad o &#039;la seguridad por contrato&#039;??

Creo que antes de buscar responsabilidades se deben pedir garantías y este es un tema que los técnicos podemos recomendar.

Si el desarrollo no es propio, hay que tomar ciertas medidas para evitar los problemas de seguridad y esto tiene que venir reflejado en la oferta del proyecto. Tal como está el estado del &#039;arte de la programación&#039; nunca vamos a tener una certeza absoluta de ser invulnerables, mucho menos en desarrollos hechos a medida, por eso, las salvaguardas, incluyen tener en cuenta la seguridad en ciclo de vida del software.

Por ejemplo, se debe incluir en los pliegos que los desarrollos seguirán las guías de desarrollo seguro del OWASP o pedir certificaciones como la de ISC2 , http://www.isc2.org/csslp/default.aspx  además de que se verifique la validación sobre los errores más típicos de programación del SANS http://cwe.mitre.org/top25/ 
 ...
Posteriormente tendrá que ser preceptivo el pasar una auditoría (no automatizada) por parte de un centro independiente para que se valide la entrega de la aplicación.

Esto supondrá sobre costes puesto que no existe una seguridad absoluta, pero es lo menos que podemos pedir.</description>
		<content:encoded><![CDATA[<p>Cultura de seguridad o &#8216;la seguridad por contrato&#8217;??</p>
<p>Creo que antes de buscar responsabilidades se deben pedir garantías y este es un tema que los técnicos podemos recomendar.</p>
<p>Si el desarrollo no es propio, hay que tomar ciertas medidas para evitar los problemas de seguridad y esto tiene que venir reflejado en la oferta del proyecto. Tal como está el estado del &#8216;arte de la programación&#8217; nunca vamos a tener una certeza absoluta de ser invulnerables, mucho menos en desarrollos hechos a medida, por eso, las salvaguardas, incluyen tener en cuenta la seguridad en ciclo de vida del software.</p>
<p>Por ejemplo, se debe incluir en los pliegos que los desarrollos seguirán las guías de desarrollo seguro del OWASP o pedir certificaciones como la de ISC2 , <a href="http://www.isc2.org/csslp/default.aspx" rel="nofollow">http://www.isc2.org/csslp/default.aspx</a>  además de que se verifique la validación sobre los errores más típicos de programación del SANS <a href="http://cwe.mitre.org/top25/" rel="nofollow">http://cwe.mitre.org/top25/</a><br />
 &#8230;<br />
Posteriormente tendrá que ser preceptivo el pasar una auditoría (no automatizada) por parte de un centro independiente para que se valide la entrega de la aplicación.</p>
<p>Esto supondrá sobre costes puesto que no existe una seguridad absoluta, pero es lo menos que podemos pedir.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Francisco Benet</title>
		<link>http://www.securityartwork.es/2009/03/26/www-una-ventana-al-mundo-una-ventana-para-los-intrusos/comment-page-1/#comment-837</link>
		<dc:creator>Francisco Benet</dc:creator>
		<pubDate>Fri, 27 Mar 2009 11:38:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.securityartwork.es/?p=659#comment-837</guid>
		<description>Bueno, a veces tienes lo que pagas, si pagas becarios debes poner más atención, pese a que lo que deberias hacer es implantar controles de testing. En cualquier caso yo a este tío lo largaba a la calle...aunque si tiraramos a todos los que hacen males el paro se duplicaria. Es más, si esto llegase a ver la luz (me refiero al codigo) largaba al desarrollador, al jefe de proyecto, a los de pruebas(si los hay), al responsable de seguridad (si lo hay), al responsable de metodología (Si lo hay),... Lo que quiero decir es que estas cosas pasan muchas veces por falta de rigor, conocimiento, y por costes...y más de una vez &#039;por mala leche&#039;.

Como todos sabemos, cuanto más grande es el proyecto (en presupuesto) más se lleva el consultor y menos hay para el desarrollador...así que cuando pagas becarios, tienes becarios, si te saltas las fases de pruebas, si no usas frameworks que te alivien la carga de seguridad, si no eres preventivo...entonces la Web 2.0 te lleva al infierno.

Y sigo estando de acuerdo contigo, exceptuando que el desarrollador es el medio pero no el fin...</description>
		<content:encoded><![CDATA[<p>Bueno, a veces tienes lo que pagas, si pagas becarios debes poner más atención, pese a que lo que deberias hacer es implantar controles de testing. En cualquier caso yo a este tío lo largaba a la calle&#8230;aunque si tiraramos a todos los que hacen males el paro se duplicaria. Es más, si esto llegase a ver la luz (me refiero al codigo) largaba al desarrollador, al jefe de proyecto, a los de pruebas(si los hay), al responsable de seguridad (si lo hay), al responsable de metodología (Si lo hay),&#8230; Lo que quiero decir es que estas cosas pasan muchas veces por falta de rigor, conocimiento, y por costes&#8230;y más de una vez &#8216;por mala leche&#8217;.</p>
<p>Como todos sabemos, cuanto más grande es el proyecto (en presupuesto) más se lleva el consultor y menos hay para el desarrollador&#8230;así que cuando pagas becarios, tienes becarios, si te saltas las fases de pruebas, si no usas frameworks que te alivien la carga de seguridad, si no eres preventivo&#8230;entonces la Web 2.0 te lleva al infierno.</p>
<p>Y sigo estando de acuerdo contigo, exceptuando que el desarrollador es el medio pero no el fin&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: ramado</title>
		<link>http://www.securityartwork.es/2009/03/26/www-una-ventana-al-mundo-una-ventana-para-los-intrusos/comment-page-1/#comment-835</link>
		<dc:creator>ramado</dc:creator>
		<pubDate>Fri, 27 Mar 2009 10:03:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.securityartwork.es/?p=659#comment-835</guid>
		<description>Hola Francisco, en primer lugar agradecerte tu comentarío. Estoy totalmente de acuerdo con tu postura en cuanto a las responsabilidades finales de los posibles fallos de seguridad de las aplicaciones web. No se debe buscar un único responsable, pese a que mi persona instando a la provocación haya querido cargar a lomos de los programadores la responsabilidad de aberraciones como :

(menorque)?php
include($_GET[&#039;vuln&#039;]);
?(mayorque)

o incluso...

SELECT * FROM usuarios WHERE nombre = &#039;&quot; + nombreUsuario + &quot;&#039;; sin valildación y filtrado previo

Saludos.</description>
		<content:encoded><![CDATA[<p>Hola Francisco, en primer lugar agradecerte tu comentarío. Estoy totalmente de acuerdo con tu postura en cuanto a las responsabilidades finales de los posibles fallos de seguridad de las aplicaciones web. No se debe buscar un único responsable, pese a que mi persona instando a la provocación haya querido cargar a lomos de los programadores la responsabilidad de aberraciones como :</p>
<p>(menorque)?php<br />
include($_GET['vuln']);<br />
?(mayorque)</p>
<p>o incluso&#8230;</p>
<p>SELECT * FROM usuarios WHERE nombre = &#8216;&#8221; + nombreUsuario + &#8220;&#8216;; sin valildación y filtrado previo</p>
<p>Saludos.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Francisco Benet</title>
		<link>http://www.securityartwork.es/2009/03/26/www-una-ventana-al-mundo-una-ventana-para-los-intrusos/comment-page-1/#comment-834</link>
		<dc:creator>Francisco Benet</dc:creator>
		<pubDate>Fri, 27 Mar 2009 09:46:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.securityartwork.es/?p=659#comment-834</guid>
		<description>Roberto, me ha gustado tu post, y coincido contigo en todo (sin entraramos a profundizar podriamos estar dias, horas y eternas jornadas de cervezas charlando - seguro - ) pero veo tres aspectos fundamentales en los que te centras: 
1 - seguridad de elementos de infraestructura.
2 - seguridad de codigo.
3 - Responsabilidad.

Y es aquí donde me gustaría lanzar una cuestión (cada uno que tenga su opinión) relativa a la seguridad empresarial: ¿la responsabilidad de la seguridad realmente recae sobre un único sujeto?¿y legalmente ante un fallo de los sistemas?

Ahora, el control de la información así como la gestión de los sistemas debe ser horizontal a la empresa, por lo tanto ¿que responsabilidad real existe en el desarrollador? ¿quien es el responsable de la calidad del software? - y la calidad engloba seguridad, hay que asumirlo de una vez - 
Sí creamos software, ¿por que el comprador no nos exige resultados de seguridad? ¿por que no exige el resultado de metricas o testing en seguridad?
Si compramos sofware ¿por que el desarrollador no nos ofrece garantias de calidad asociadas a la seguridad y no solo a la funcionalidad? Lo del ACE Team de Microsoft esta bien, pero no me convence mucho. 

Creo que el comprador también debe asumir su culpa, la de la no exigencia (por miedo al coste, claro, lo de siempre) de la seguridad (por que desconoce, por que no tiene cultura). Y luego va y se queja que de su página web alguién ha sacado sus usuarios...por favor.

Pero aún hay más, a menudo estamos acostumbrados a dividir las responsabilidades entre equipos de proyecto de desarrollo, de implantación y pruebas, y de explotación. Cada uno con su parcela, cada uno con sus métodos y con sus responsabilidades, pero el factor común en la seguridad es que la mala praxis en cada uno de estos grupos expone el sistema a fallos de seguridad y a fallos disponibilidad de los servicios y datos (Dejame que los diferencie). ¿A quien corresponde asumir la responsabilidad de la mala praxis de estos grupos y la exposición a fallos del sistema y/o vulnerabilidades? ¿a la metodología? ¿al responsable de seguridad? ¿al responsable de &#039;presupuestos&#039;? ¿al jefe de proyecto de cada uno de los grupos? ¿al operador/desarrollador/analista? ¿o a la empresa en general? ¿y legalmente?

La asignación de responsabilidades -para mi gusto- es como asegurar que por tener firmado un papel de confidencialidad se le puede dejar a un señor campar a sus anchas por los datos de la empresa, o que una politica de seguridad nos cubre de todos los males aunque no se disponga de medios para que se cumplan. 

Al final, como todos sabemos, acabamos cargando contra el remero, y no contra el patrón.</description>
		<content:encoded><![CDATA[<p>Roberto, me ha gustado tu post, y coincido contigo en todo (sin entraramos a profundizar podriamos estar dias, horas y eternas jornadas de cervezas charlando &#8211; seguro &#8211; ) pero veo tres aspectos fundamentales en los que te centras:<br />
1 &#8211; seguridad de elementos de infraestructura.<br />
2 &#8211; seguridad de codigo.<br />
3 &#8211; Responsabilidad.</p>
<p>Y es aquí donde me gustaría lanzar una cuestión (cada uno que tenga su opinión) relativa a la seguridad empresarial: ¿la responsabilidad de la seguridad realmente recae sobre un único sujeto?¿y legalmente ante un fallo de los sistemas?</p>
<p>Ahora, el control de la información así como la gestión de los sistemas debe ser horizontal a la empresa, por lo tanto ¿que responsabilidad real existe en el desarrollador? ¿quien es el responsable de la calidad del software? &#8211; y la calidad engloba seguridad, hay que asumirlo de una vez &#8211;<br />
Sí creamos software, ¿por que el comprador no nos exige resultados de seguridad? ¿por que no exige el resultado de metricas o testing en seguridad?<br />
Si compramos sofware ¿por que el desarrollador no nos ofrece garantias de calidad asociadas a la seguridad y no solo a la funcionalidad? Lo del ACE Team de Microsoft esta bien, pero no me convence mucho. </p>
<p>Creo que el comprador también debe asumir su culpa, la de la no exigencia (por miedo al coste, claro, lo de siempre) de la seguridad (por que desconoce, por que no tiene cultura). Y luego va y se queja que de su página web alguién ha sacado sus usuarios&#8230;por favor.</p>
<p>Pero aún hay más, a menudo estamos acostumbrados a dividir las responsabilidades entre equipos de proyecto de desarrollo, de implantación y pruebas, y de explotación. Cada uno con su parcela, cada uno con sus métodos y con sus responsabilidades, pero el factor común en la seguridad es que la mala praxis en cada uno de estos grupos expone el sistema a fallos de seguridad y a fallos disponibilidad de los servicios y datos (Dejame que los diferencie). ¿A quien corresponde asumir la responsabilidad de la mala praxis de estos grupos y la exposición a fallos del sistema y/o vulnerabilidades? ¿a la metodología? ¿al responsable de seguridad? ¿al responsable de &#8216;presupuestos&#8217;? ¿al jefe de proyecto de cada uno de los grupos? ¿al operador/desarrollador/analista? ¿o a la empresa en general? ¿y legalmente?</p>
<p>La asignación de responsabilidades -para mi gusto- es como asegurar que por tener firmado un papel de confidencialidad se le puede dejar a un señor campar a sus anchas por los datos de la empresa, o que una politica de seguridad nos cubre de todos los males aunque no se disponga de medios para que se cumplan. </p>
<p>Al final, como todos sabemos, acabamos cargando contra el remero, y no contra el patrón.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

