domingo, 30 de noviembre de 2008

En casa del herrero...


Hoy leo en Coding Horror el post “Coding: It’s just writing”. Nos recuerda que programar bien, tiene que ver tanto con hacer que un programa haga lo que debe, como con hacer que los demás lo entiendan. Aplica lo mismo que a la escritura normal: ser claros y concisos es súper importante, expresar tus ideas de forma sencilla, y a ser posible con las palabras justas (o cantidad de código preciso), pero no menos de las necesarias. Podemos pasarnos la vida mejorando y refinando la forma en que redactamos, e igualmente, la forma en que codificamos. Lo mismo aplica a cualquier otro campo de la informática: lo que queda de un proyecto es lo documentado, así que al final, eso es el proyecto.

Nos mencionan el concepto de “Literate programming”, original de D. Knuth, con el siguiente párrafo, que escribió:

“Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.”


Esto os lo escribo porque dentro mis actividades como informático y segurata, también he tenido labores de analista y programador. Lo de programar lo llevo en el cuerpo, me encanta, estudié informática por eso. Pero… ¡Ay!: las prisas, el tener que desarrollar una funcionalidad compleja para mañana, porque la necesito para el último proyecto en el que estoy trabajando, llevan a no escribir bien. Particularmente: a escribir código de forma que luego es difícil de entender. Ocurre, aunque me crea un buen developer.... Y eso, por ejemplo, lleva a problemas de seguridad, o sea que se puede decir eso de “en casa del herrero, cuchara de palo”.

Hace ya algún tiempo (cuando me metí en el mundo del Traje y la corbata), nuevos informáticos y seguratas en la empresa heredaron mi trabajo, y tienen ante sí una doble tarea: desarrollar como les gusta y crear nuevas funcionalidades, y lidiar con partes del código que dan asco porque no tuve tiempo para codificar adecuadamente. Este post es para que conste: Kudos para ellos :)

Slds!

P.D. También nos mencionan este otro post sobre borrar código (), muy bueno ;)
P.D. Relacionado: Enrique nos presenta el Tao del programador


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

miércoles, 26 de noviembre de 2008

MISSP en PYMES


¿Qué es un MISSP y por qué puede ser útil? Un Managed Internet Security Service Provider es un proveedor de servicios de internet (ISP), que complementa su oferta al cliente con servicios de seguridad gestionada, como firewalls en red, vpn, detección de spam, o detección de intrusiones.

La idea básica es proteger el acceso a Internet, tanto en tráfico entrante como saliente, desde la propia red del operador en vez de en las instalaciones del cliente. Típicamente será un servicio operado desde un Security Operation Center propiedad del ISP, que deberá contar con soluciones tecnológicas adecuadas y personal especializado.

No es un concepto nuevo, ni mucho menos. Pero tampoco lo conoce todo el mundo ;) . En el FAQ de Sans nos hacen una descripción de qué son, y comentan algunos factores a tener en cuenta antes de decidir si contratar, o no, servicios de estas características. Básicamente:
  • si se dispone de la capacidad de generar firmas propias para los sistemas de detección de intrusiones, o si por el contrario, se depende del fabricante del IDS
  • ¿se dispone de una variedad de soluciones, que permitan operar sobre entornos tecnológicos variados, o se utiliza una solución global para todo?
  • ¿qué medidas de seguridad física se emplean en el SOC?
  • ¿qué medidas se han aplicado con respecto a la tolerancia a fallos? ¿Cuál es el proceso de notificación de fallos? ¿Se revisa periódicamente el funcionamiento de los equipos? ¿Existe un sistema de centralización de logs, que permita revisar los mismos en caso de que un equipo se vea comprometido?
  • ¿se confía el servicio a personal propio o subcontratado? ¿Se investiga a las personas que componen el equipo, antes de contratarlas? ¿Se realizan acuerdos de confidencialidad en todos los casos?
  • ¿qué importancia da el proveedor a las certificaciones en seguridad? ¿El equipo que se ocupa del servicio recibe formación contínua, que le permita seguir al día?
A mí personalmente me parece interesante saber cómo el servicio se va a adaptar a las propias necesidades de mi organización, por ejemplo, si me va a proporcionar algún tipo de consola en la que se pueda parametrizar determinados aspectos del servicio, y si se pueden definir políticas y utilizar el servicio proporcionado para vigilar su cumplimiento de forma externa a la organización. También es interesante saber si el servicio proporciona informes en un formato personalizado o por el contrario es genérico, cuál es el detalle de las explicaciones que se proporcionan, si se incluyen servicios de consultoría que ayuden a comprender bien las características del problema que se haya reportado, la probabilidad de que ocurra y el impacto que podría tener, o si mantienen contacto con equipos CERT oficiales.

Otras cuestiones interesantes no tienen que ver tanto con el propio servicio en sí, como con la manera en que el cliente utilizará este servicio. Es el propio usuario el que tiene un conocimiento exhaustivo de su propia organización, y podrá distinguir amenazas reales de las que no lo son. Su gestión de riesgos es el motor del resto de las tareas a realizar en materia de seguridad, no se debe olvidar esto nunca. Una pequeña o mediana empresa podría pensar que contratando un servicio de seguridad gestionado como este resuelve todas sus necesidades de seguridad. Sin embargo, lo que hace es externalizar los medios técnicos necesarios, pero sigue teniendo necesidades organizativas a las que prestar atención.

Así será necesario que se defina un plan de acción en caso de que se detecte un riesgo real, y esto es algo que sólo el personal interno de una organización puede realizar. Sólo los usuarios pueden priorizar adecuadamente sus riesgos, decidir cuál el plazo fijado para la resolución del problema detectado, o establecer cuáles son las medidas de mitigación y supervisión adecuadas a su entorno y a los medios de que dispongan. Y son ellos los que deben definir sus propios planes de contingencia y de continuidad de negocio. Por eso, por ejemplo, en Inteco existe un plan de impulso a la certificación e implantación de un SGSI en la PYME (hay que decir que una empresa que decida implantarlo, obtiene una subvención del Plan Avanza que cubre un elevado tanto por ciento de los costes de implantación).

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...