<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta content="MSHTML 6.00.2900.3492" name="GENERATOR">
</head>
<body>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2">Andrés:</font></span></div>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2">Lo clásico si la organización es pequeña: formar un equipo de seguridad (una o dos personas) que cumplan las funciones, de mantenimiento y control de cumplimiento
de las políticas, así como de comunicaciones con los Cert locales.</font></span></div>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2">Si la organización es grande, pero no admiten centralizar (por la razón que sea: cultura organizacional, dispersión geográfica, etc.), pueden formar un
pequeño grupo coordinador de dos personas y tener oficiales de seguridad informática en cada sucursal....</font></span></div>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2">El tema es que la organización (en general esto sucede por exigencia legal externa) tiene que desarrollar previamente sus Políticas de Seguridad de la Información,
son éstas las que crean (en la mayoría de los casos) personal con capacidad de detectar incidentes y eso presiona para la formación de un equipo especializado.</font></span></div>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2">No he visto casos en los que no haya sido como lo cuento, primero las políticas de SI, luego el Csirt para enfrentar los incidentes...</font></span></div>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2">Saludos,
</font></span></div>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2">Eduardo.</font></span></div>
<div dir="ltr" align="left"><span class="386440716-18122009"><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<br>
<div class="OutlookMessageHeader" lang="es" dir="ltr" align="left">
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>De:</b> seguridad-bounces@lacnic.net [mailto:seguridad-bounces@lacnic.net]
<b>En nombre de </b>Andres Tarallo<br>
<b>Enviado el:</b> viernes, 18 de diciembre de 2009 14:02<br>
<b>Para:</b> Lista para discusión de seguridad en redes y sistemas informaticos de la región<br>
<b>Asunto:</b> Re: [LACNIC/Seguridad] Temas de interes y brainstorming generalpara LACNIC XIII<br>
</font><br>
</div>
<div></div>
Apoyo ese tema para tratarlo en un foro o debate. <br>
<br>
De paso planteo otro tema que me parece importante. ¿Que podemos hacer en aquellas organizaciones donde un CSIRT/CERT no es viable?<br>
<br>
Saludos<br>
<br>
Andrés<br>
<br>
<div class="gmail_quote">El 18 de diciembre de 2009 12:47, ariel sabiguero yawelak
<span dir="ltr"><<a href="mailto:asabigue@fing.edu.uy">asabigue@fing.edu.uy</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<div bgcolor="#ffffff" text="#000000">Bueno, lamentablemente hay entes por acá que niegan sus problemas de seguridad, y además, no autorizan que se consulte a CERTs locales, ni que recurran a grupos académicos en búsqueda de soluciones.<br>
<br>
En esos casos, en los que un consultor está contratado bajo un acuerdo de confidencialidad, es donde se genera el problema ¿Se entiende?<br>
<br>
El problema gerencial y cultural puede llegar entonces a ser el tema a discutir entonces en el foro ;-)<br>
<br>
¿cómo conscientizamos a gerentes no informáticos?<br>
<br>
ariel<br>
<br>
El 18/12/09 13:02, Nicolas Antoniello escribió:
<div>
<div></div>
<div class="h5">
<blockquote type="cite">Estimados,<br>
<br>
La pregunta creo, es ¿por qué el anonimato?<br>
<br>
Quien crea que por quedar en evidencia el hecho de que tuvo un problema de seguridad es "mas malo" como prefesional o como empresa que otro que no lo tuvo, ese, es quien tiene el principal problema de seguridad. :)<br>
<br>
Por lo tanto, no veo por que el anonimato. De hecho, de eso se trata la solucion proactiva, al poner en evidencia algo antes de que sea demasiado tarde.<br>
Acaso no creamos CERTs o CSIRTs para estos propositos. Acaso no invertimos dinero en auditorias para resolver estos problemas de seguridad.<br>
<br>
Cuando el problema con las publicaciones BGP de Google (por ejemplo) evidenció un problema de seguridad en el modo de proceder en lo referente a los prefijos BGP que se aceptan de los peers, acaso eso debio permanecer en el anonimato, o fue mas productiva la
discusión posterior?<br>
Acaso nadie se dió cuenta de que la solución adoptada en ese caso atenta contra el número de publicaciones BGP en la tabla global (... y luego nos quejamos de las políticas de IPv6...).<br>
Creo que efectivamente el que Google y los "demas" comentaran la solucion y el problema fue más productivo que el anonimato... que por ciero en ese caso, era imposible de guardar.<br>
<br>
Creo que deberíamos tratar de que las "gerencias" vean ese punto de vista.<br>
<br>
Saludos,<br>
Nicolas.<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<hr>
<font face="Arial" color="Gray" size="1">El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique
al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las
específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información<br>
<br>
<br>
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy
of this e-mail by any person or entity that is not the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.<br>
</font>
</body>
</html>