Llegamos a ustedes gracias a:



Columnas de opinión

Cómo vender software de código abierto dentro de su empresa

Por: Kristy Westphal, CISO del Departamento de Seguridad Económica de Arizona

[08/09/2009] ¿Es bueno el código abierto para su organización? Aquí le presentamos una forma realista de comparar el software comercial con el software de código abierto, y tomar la decisión correcta basados en los requerimientos y riesgos. Se enumeran muchas fuentes que puede usar y adaptar para su organización, lo cual dará como resultado una política de la organización que dejará satisfechos a las áreas legales, de procurement y TI.

¿Por qué tomar en consideración el código abierto? ¿Quién podría resistir una forma de reducir costos y encontrar al mismo tiempo formas para abordar las necesidades de la empresa? Las opciones económicas y gratuitas son más importantes que nunca. Algunas organizaciones tienen políticas estrictas contra este tipo de software, pero si puede proporcionar datos válidos para probar que el código abierto proporciona una funcionalidad similar a la del software comercial, probablemente pueda proporcionar un valor real a su organización.
Algunos de los temas importantes a ser incluidos se refieren a la marca, derecho de propiedad e información sobre la patente, y las garantías y responsabilidades definidas en estas garantías. Generalmente, las garantías y responsabilidades son una clave para identificar los riesgos en estos tipos de software porque el creador no es responsable. ¿Quién lo es? Más que probablemente, uno toma el software a su valor nominal, y si algo sale mal uno acepta el riesgo. Punto. Pero nuevamente, si ha hecho su due dilligence, realizará elecciones inteligentes acerca de si el riesgo vale la pena o no.
Antes de que incluso considere cualquier tipo de código abierto, tiene que tener a algunos buenos elementos de su lado. Si no puede hacer que estén con usted sus grupos legales, de procurement, y administración de riesgos, ni siquiera debería comenzar. Una forma de hacerlo es proporcionándoles los hechos acerca del riesgo que se corre. Espero que este artículo le de las herramientas para hacer esto.
Escoger una definición
A medida que camina por las oscuras aguas del código abierto, asegúrese que tiene una buena idea del tipo de software con el que está trabajando, porque hay numerosas versiones y usted necesita asegurarse que aquellos que realicen la evaluación entiendan qué es lo que están buscando. Esto en sí es un desafío porque hay numerosas opciones. Código abierto, académico, GNU, shareware, dominio público, usted escoja. Además, necesita asegurarse de que se tengan pautas o reglas para cubrir todas las categorías o, si esto no es lo apropiado, entonces quizás adaptar las pautas a los tipos específicos de software que está buscando.
Por ejemplo, podría usar criterios diferentes cuando se trata de seleccionar freeware para desktop (un programa para PDF o utilidad de seguridad, por ejemplo) versus software empresarial como Open Office.
Algunas posibles pautas para ayudar a examinar el freeware:
1. Revise con el grupo de seguridad si el producto cumple con las necesidades y ya ha sido revisado. Ellos mantendrán un repositorio central de herramientas que ya han sido revisadas en el proceso.
2. Lea el End-User Licensing Agreement (EULA) para verificar su validez de uso. Lo principal que debe buscar:
    a. Puntos específicos sobre la redistribución
    b. Restricciones de Copyright
    c. Otros requerimientos de uso
3. También necesitará revisar el software para ver:
    a. Opciones de soporte (¿se basa en una comunidad o se puede comprar un contrato de soporte?)
    b. Políticas de parches y actualizaciones
    c. Documentación (¿se encuentra disponible en caso de que usted o sus usuarios tengan preguntas?)
    d. Peer feedback (¿qué dice Internet acerca del uso de la herramienta?). Algunas buenas fuentes para conducir esta investigación son:
        i. http://www.finance.gov.au/publications/guide-to-open-source-software/appendix-a-resources.html
        ii. http://www.securityfocus.com/vulnerabilities      
       iii. http://www.google.com
4. Si no hay problemas que eviten seguir adelante, entonces haga que el grupo de seguridad realice una revisión del código en busca de código malicioso. Para esto se necesita:
    a. Nombre del producto
    b. Sitio web
    c. Ratificación de que el EULA ha sido revisado y los términos y condiciones son aceptables.
    d. Los resultados de la búsqueda del paso 3.
5. Si el producto pasa la revisión, será añadido a la lista y se enviará una notificación de certificación al personal. Si no lo hace, se enviará una notificación de rechazo al personal.
Presumiendo que el software cumplirá con los requerimientos técnicos y del negocio, es tiempo de hacer la verdadera evaluación. Esta es la parte complicada. Tener un conjunto de estándares específicos que el software deba cumplir antes que el proceso se inicie, ayuda a que quienquiera que realice el trabajo tendrá los mismos resultados que cualquier otro. Si permite que los criterios sean elegidos por la parte evaluadora, entonces la integridad de la evaluación podría estar en cuestión. Esta parte es bastante difícil, así que sea tan específico como sea posible durante esta parte del proceso.
Con suerte, muchas de la investigaciones en esta área ya se han hecho, incluyendo a actores como el Departamento de Defensa de Estados Unidos, el gobierno australiano, la Universidad de Atenas, y una compañía llamada Atos Origins. El proceso definido aquí usa una combinación de factores de cada una de esas fuentes.
El software debe ser evaluado contra un paquete comercial y recibir un puntaje basado en su desempeño. Algunas pruebas se basan en el uso real del software mientras, que otras requieren de un due dilligence. Los factores incluidos en esta evaluación pueden ser:
* Durabilidad intrínseca
    o Madurez
        - Edad
        - Estabilidad (¿cuál es su proceso de parchado/actualización?)
        - Problemas/bugs conocidos
    o Adopción
        - Popularidad (¿quién lo usa?), feedback
        - Referencias
        - Comunidad que contribuye
        - Documentación/Libros para usuarios finales
    o Liderazgo del desarrollo
        - Equipo líder
        - Estilo de gerencia
    o Actividad
        - Desarrolladores, identificación, rotación
        - Actividad en bugs
        - Actividad en funcionalidades
        - Actividad en lanzamientos
* Servicios
    o Disponibilidad de la capacitación
    o Soporte
    o Consultoría
* Quality Assurance
    o ¿Tiene el producto un proceso de QA?
    o Herramientas (como en los reportes de bugs o herramientas de solicitud de características)
    o Revisión de código malicioso
* Empaquetado
    o Fuente (¿cuán difícil es instalar el software?)
* Uso
    o Administración - ¿fácil/difícil?
    o Monitoreo - ¿fácil/difícil?
    o Interfase de usuario final - ¿fácil/difícil?
    o Implementación
* Modularidad
* Subproductos
    o ¿Cómo se puede modificar el código?
    o ¿Extensibilidad del código?
* Tipo de licencia
    o Copyright
    o Modificación de código fuente
    o Hoja de ruta
* Mantenimiento
    o Calidad del código fuente
    o Complejidad intrínseca
    o Documentación técnica
* Dominio del código
    o Directo
    o Indirecto
Estos criterios son muy tangibles y pueden usarse para evaluar cualquier paquete comercial. Luego se puede determinar algún tipo de rating y basar la selección en el puntaje que obtengan. Por ejemplo, el sistema de rating puede ser tan simple como:
0 Ausente
1 Presente
2 Excede las expectativas
El software de código abierto puede ser una solución valiosa para muchos tipos de software en una organización. En tiempo de presupuestos ajustados y asegurándose de que todos los procesos son revisados buscando su eficiencia, puede que sea el momento para presentar el software de código abierto a su organización. Ya sea que se trate de largo plazo o del corto plazo, asegúrese de que basa sus decisiones en una evaluación razonable y apropiada.
Westphal es una profesional de las tecnologías de la información con 16 años de experiencia específica en el área de seguridad de la información. Actualmente ella se encuentra empleada como la CISO del Departamento de Seguridad Económica de Arizona. Capacitada en la resolución de problemas y análisis de procesos, su experiencia específica en las áreas de seguridad incluyen evaluación forense, sistemas operativos y seguridad de redes, detección de intrusiones, manejo de incidentes, análisis de vulnerabilidades y desarrollo de políticas. Westphal ha sido CISSP desde 2001 y CISA desde 2008.
Network World (US)