[LACNIC/Seguridad] Temas de interes y brainstorming generalpara LACNIC XIII

Carozo, Eduardo ecarozo en antel.com.uy
Vie Dic 18 14:15:28 BRST 2009


Andrés:
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.
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....
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.
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...

Saludos,
Eduardo.


________________________________
De: seguridad-bounces en lacnic.net [mailto:seguridad-bounces en lacnic.net] En nombre de Andres Tarallo
Enviado el: viernes, 18 de diciembre de 2009 14:02
Para: Lista para discusión de seguridad en redes y sistemas informaticos de la región
Asunto: Re: [LACNIC/Seguridad] Temas de interes y brainstorming generalpara LACNIC XIII

Apoyo ese tema para tratarlo en un foro o debate.

De paso planteo otro tema que me parece importante. ¿Que podemos hacer en aquellas organizaciones donde un CSIRT/CERT no es viable?

Saludos

Andrés

El 18 de diciembre de 2009 12:47, ariel sabiguero yawelak <asabigue en fing.edu.uy<mailto:asabigue en fing.edu.uy>> escribió:
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.

En esos casos, en los que un consultor está contratado bajo un acuerdo de confidencialidad, es donde se genera el problema ¿Se entiende?

El problema gerencial y cultural puede llegar entonces a ser el tema a discutir entonces en el foro ;-)

¿cómo conscientizamos a gerentes no informáticos?

ariel

El 18/12/09 13:02, Nicolas Antoniello escribió:
Estimados,

La pregunta creo, es ¿por qué el anonimato?

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.  :)

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.
Acaso no creamos CERTs o CSIRTs para estos propositos. Acaso no invertimos dinero en auditorias para resolver estos problemas de seguridad.

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?
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...).
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.

Creo que deberíamos tratar de que las "gerencias" vean ese punto de vista.

Saludos,
Nicolas.


________________________________
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


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.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20091218/08d2f777/attachment.html>


Más información sobre la lista de distribución Seguridad