-
Mejoras, sugerencias y cambios del foro · Consulta las novedades y comparte tus propuestas.
-
Segunda mano vuelve a abrir. Hemos juntado DVDs y BDs y añadido una forma más cómoda de seguir y valorar los tratos. Aquí tienes los cambios y la guía rápida.
Proyecto en PMBOK y MAGERIT
- Iniciador del tema Merlin
- Fecha de inicio
Re:
te refieres a MAGERIT o MÉTRICA? porque pmbok todavia, pero magerit es una metodología de analisis de riesgos, y no me imagino haciendo un proyecto segun magerit.. que por otro lado es tan coñazo como metrica. Me refiero a que magerit en desarrollos basicamente no se usa, y como modelo de gestion de proyectos, ni me lo imagino. En todo caso las de riesgos son metodologías que se aplican posteriormente, principalmente a la hora de definir contramedidas y como y donde aplicarlas. Y ademas para análisis de riesgos en lo que es sgsi lo que se aplica es lo que dice BS7799 o iso17799 o une71502, que viene a decir que uses la metodologia que mas te guste, mientras uses una que sea sistematica y repetible. Yo soy auditor jefe certificado ISO17799 y siempre hemos utilizado la metodologia propia de mi empresa sin problema.
Salu2!
te refieres a MAGERIT o MÉTRICA? porque pmbok todavia, pero magerit es una metodología de analisis de riesgos, y no me imagino haciendo un proyecto segun magerit.. que por otro lado es tan coñazo como metrica. Me refiero a que magerit en desarrollos basicamente no se usa, y como modelo de gestion de proyectos, ni me lo imagino. En todo caso las de riesgos son metodologías que se aplican posteriormente, principalmente a la hora de definir contramedidas y como y donde aplicarlas. Y ademas para análisis de riesgos en lo que es sgsi lo que se aplica es lo que dice BS7799 o iso17799 o une71502, que viene a decir que uses la metodologia que mas te guste, mientras uses una que sea sistematica y repetible. Yo soy auditor jefe certificado ISO17799 y siempre hemos utilizado la metodologia propia de mi empresa sin problema.
Salu2!
Merlin
Miembro10.552 mensajesdesde 2003
0 agradecimientos
Metrica3 también, pero Magerit se pide en el proyecto junto con Metrica 3 y PMBOK y como dices, únicamente para en análisis de riesgos.
Se trata de un proyecto grande, pero sobretodo, que manejará muchísima información personal, de ahí supongo que sea una de las condiciones del proyecto, por eso preguntaba quien ha trabajado con ese estándar, ya que en mi caso es la primera vez que lo escucho.
La metodología propia que dices es lo normal, pero en este caso es el cliente el que define cual será porque él también auditará.
Saludos.
Se trata de un proyecto grande, pero sobretodo, que manejará muchísima información personal, de ahí supongo que sea una de las condiciones del proyecto, por eso preguntaba quien ha trabajado con ese estándar, ya que en mi caso es la primera vez que lo escucho.
La metodología propia que dices es lo normal, pero en este caso es el cliente el que define cual será porque él también auditará.
Saludos.
Merlin
Miembro10.552 mensajesdesde 2003
0 agradecimientos
Lo que pregunto no tiene nada que ver con programación, es precisamente la parte de análisis.
Es que todo ese follón de estándares son un coñazo del copón. Obligan a seguir una serie de pasos que encuentro en muchos casos innecesarios y que srven únicamente para que se tarde más en hacer algo y que aún encima no va a asegurar en ningún caso que el producto final esté libre de fallos.
Ferenczyg, ¿tu opinión al respecto cuál es?.
Saludos.
Es que todo ese follón de estándares son un coñazo del copón. Obligan a seguir una serie de pasos que encuentro en muchos casos innecesarios y que srven únicamente para que se tarde más en hacer algo y que aún encima no va a asegurar en ningún caso que el producto final esté libre de fallos.
Ferenczyg, ¿tu opinión al respecto cuál es?.
Saludos.
Merlin dijo:
Mi opinion al respecto es que tanto metrica como magerit no estan tan destinados a lo que parece (la gestión del proyecto o el riesgo) sino que se dedican a sistematizar tareas para que luego puedan ser muy trazables. El problema es que introducen una sobrecarga tanto en la fase de análisis como en la de desarrollo que suele hacer que los proyectos se vayan de madre ya desde el principio, en lugar de por la mitad o al final, que es como dios manda
ademas normalmente por eso se aplican poco a la hora del diseño y el análisis. No obstante si la aplicación lo requiere espero que estemos hablando de meses/años de desarrollo y que el presupuesto ande en las seis cifras, por la parte alta. Por otro lado si me pongo el gorro de consultor y he de recomendar algo, Magerit (y todas las metodologias de gestion de riesgos) tienen tres pasos, que son basicamente definir los riesgos, evaluar su impacto y definir las contramedidas a aplicar para minimizar el impacto. Cuando el desarrollo ya se ha hecho, suele venir un plan de accion para aplicar las contramedidas. En tu caso y siendo un desarrollo mi opinion es que en la parte de análisis hagais un analisis de riesgos en vacio (o sea, referido a los datos a tratar, a los sistemas de explotación del aplicativo caso de que ya se sepan y al lenguaje de programación si ya se sabe) y si en tiempo de desarrollo aplicais metodologias de programación segura (que en si mismo ya es toda una disciplina) ya tendreis un nivel de riesgos final bastante recortado.
Evidentemente, sería de ayuda aplicar paradigmas de programación tipo factoria de software, especialmente la parte de las pruebas de modulos previas a la integración que ademas de las funcionalidades definidas para los módulos testeen los requisitos de seguridad para los mismos.
Otra posible idea sería, sobre todo si trabajais en OOP, aplicar la seguridad a nivel de UML, principalmente a la hora del modelado de datos, objetos y vinculos. Habría que buscar o construir una extensión de los principales modelos de UML que permitan un sistemas de información seguro y generarn un paso coherente de unos modelos a otros en el proceso de desarrollo. Habría que incluir niveles de seguridad en los modelos, y evitar que aparecieran flujos de información que violaran la jerarquía de niveles de seguridad.
Ademas si te vas a donde pasta platero y pones magerit veras algunos pedefes que pueden ser interesantes.
Salu2!
Tim dijo:
¡¡¡¡QUÉ GRAN DÍA AQUEL QUE DECIDÍ NO VOLVER A PROGRAMAR!!!!
... y me metí en la parte de sistemas (servidores de gama media-alta, comunicaciones, seguridad...) :mmmh ......
...
La seguridad no es un producto, es un proceso. Debería estar presente tanto en los desarrollos como en la selección de soluciones como en la explotación de sistemas y comunicaciones. El problema esta en que la gente se cree que con poner un cortafuegos esta segura, cuando en el momento actual el 99'5% de las vulnerabilidades ya no esta en los sistemas, esta en las aplicaciones. Y por supuesto, los hackers lo saben.
Salu2!