Sep 15 2014

Presupuestación de la seguridad de los activos digitales

BudgettingSe aproxima final de año. Epoca de realizar y justificar presupuestos e inversiones para el siguiente año. Comienza un camino en el que se deben recoger necesidades, analizarlas, valorar su impacto económico, priorizar y filtrar, descartando lo que puede considerarse prescindible o de menor importancia. Y finalmente negociar la viabilidad contrastando las propuestas que puedan elevarse con las que realicen otras áreas de la corporación.

En esas condiciones, prácticamente nunca las inversiones en seguridad salen victoriosas frente a otras que puedan demostrar una positiva aportación a los resultados empresariales o un retorno de la inversión en términos razonables. Porque las inversiones en seguridad previenen, y – mientras no se presenten circunstancias adversas – es complejo apreciar su valor. Si las medidas funcionan nadie (o casi nadie) se entera, con lo que es también difícil – salvo que se esté metido de lleno en el asunto – su valía.

La elaboración del presupuesto de seguridad ha venido realizándose de forma casi intuitiva, basada en los riesgos que se perciben, en las experiencias acumuladas y/o en las tendencias observadas en el sector (a las cuales no son ajenos los correspondientes proveedores potenciales de soluciones). Si consideramos una instalación tipo, podremos – con toda seguridad – hallar componentes sobreprotegidos y otros, quizá más relevantes, dotados de poca o nula defensa. En contadas ocasiones podremos afrontar una proporción entre el valor objetivo de los sistemas y la información y los montos económicos dedicados a mantenerlos fuera de peligro.

El modelo que proponemos dentro del conjunto de Best Practices que propugnamos está basado en la atribución a cada uno de los activos digitales que podamos identificar, de un valor en función de la aportación que realice a los resultados empresariales. Mediante un breve análisis de riesgos y en un segundo paso, podremos cuantificar el perjuicio ocasionado a la cuenta de explotación por la ocurrencia de diversos tipos de incidentes, lo que posibilitará, como consecuencia, determinar o estimar las inversiones necesarias.

Puede descargar la guía pulsando aquí.

Permanent link to this article: http://www.ingelan.com/?p=4479

Sep 08 2014

13 Criterios para decidir qué llevar al Cloud (Post 3 de 3)

Objetivados el valor, los riesgos y la adecuación técnica de una aplicación para llevarla a la nube, únicamente queda tomar las decisiones adeciadas. En este artículo – último de la serie – facilitaremos algunas directrices que permitan establecer las prioridades del proceso. No tome nuestras sugerencias como la Biblia, y aporte al proceso sus propias sensaciones: Es Vd. quien mejor conoce su negocio, su entorno y lo que necesita para soportarlo.

cloud-computing_2Ponderados y objetivados mediante el método descrito en el post anterior los valores para los ejes según las puntuaciones otorgadas a cada uno de los 13 criterios (que pueden desglosarse en subcriterios para mayor nivel de detalle), nos sería posible establecer resultados definitivos:

 

Eje p>7.5 7.5>p>5 5>p>2.5 2.5>p
Valor Muy Alto Alto Medio Escaso
Riesgos Muy Elevados Elevados Medios Pocos
Adecuación Tecnológica Muy Alta Alta Media Poca

… y clasificar a partir de esto nuestra cartera de sistemas y aplicaciones.

Y bien…. ¿Como proceder entonces?

Aquí tiene nuestras recomendaciones:

 

Num Valor Adecuación Riesgos Comentarios
 1 Muy Alto Muy Alta Pocos Los sistemas y aplicaciones con estos niveles de puntuación deberían ser los primeros candidatos en la lista ya que – presumiblemente – pueden presentar un alto retorno de la inversión en plazos razonables y con mínimos riesgos.
 2 Alto o Muy Alto Alta o Media Pocos Este grupo podría constituir el segundo pelotón. Las condiciones son similares a las anteriores si bien pueden presentarse dificultades de ajuste. Quizá valga la pena realizar un replanteamiento y sustituirlo por un soporte adecuado a la nube
 3 Otros Otras Otros  Zona de claroscuros. No nos atrevemos a proporcionar ningún criterio en ella y dependerá de las especiales circunstancias de cada uno de los casos para que pueda añadirse como candidato a una u otra acción.
 n Escaso  Poca Elevados o Muy Elevados  Sistemas o aplicaciones sujetos a este tipo de calificaciones es mejor conservarlas en el estado en que se encuentren. Probablemente sería suicida abordar su migración a la nube.

Obviamente y puesto que la estrategia no se debería delegar, el resultado habría de pasar el filtro de la razón y tener en cuenta los condicionantes marcados por otras variables no consideradas.

 

Permanent link to this article: http://www.ingelan.com/?p=4446

Sep 01 2014

13 Criterios para decidir qué llevar al Cloud (Post 2 de 3)

Continuamos en este post ofreciendo una visión del método pretendidamente objetivo (la realidad siempre es mas compleja) que sugerimos para ayudar a tomar decisiones acerca de qué sistemas o aplicaciones puede una determinada compañía llevar a la nube.

iStock_000020265568Small

Un método objetivo para decidir qué mantenemos y qué podríamos enviar al exterior podría estar basado (como en muchos otros casos) en la clasificación de los sistemas y/o aplicaciones en base a pautas de adecuación siguiendo características que podrían ser cuantificadas de forma objetiva utilizando tablas y pesos que, totalizados, proporcionarían una visión sustancialmente clara de la situación.

Para el caso que nos ocupa, sería muy adecuado emplear criterios que podríamos agrupar en tres ejes claramente diferenciados e independientes y que responden a diferentes necesidades:

a) Valor para el negocio:

¿Significa una mejora en la operativa? ¿Permite incrementar la “top line”? ¿Facilita disminuir la “bottom line”? ¿Proporciona una rentabilidad real? ¿Es suficientemente rápido el Retorno de la Inversión?

b) Exposición a riesgos:

¿Podemos realmente perder el control de la situación? ¿Hay un riesgo cierto de exposición de información estratégica o sensible? En caso de problemas … ¿qué forma tenemos de asegurarnos de que las condiciones habituales se restablezcan?

c) Adecuación tecnológica:

¿Es compatible con los sistemas/arquitecturas que nuestros proveedores pueden poner a nuestra disposición? ¿Podemos estar seguros de que los niveles de respuesta serán rápidos y adecuados? ¿Será sencillo realizar el traspaso de datos y sistemas?¿Será fácilmente reversible o trasladable a otros proveedores?

Los 13 criterios

Entre los criterios (que podríamos, aplicación a aplicación, puntuar en cada caso de 0 a 10, por ejemplo, para luego filtrar a través de los atributos de “peso” (hemos incluido información ficticia) que faciliten la consolidación de los valores en cada uno de los ejes, se hallan los 13 a los que hace referencia el título de los dos posts que componen este artículo:

 

Eje # Criterio Peso Notas para la evaluación Puntos Ponder.
Valor 1 Rapidez de despliegue 10% 10 – Inmediato, 0 – Muy largo
2 Impacto en la Top Line/Ingresos 40% 10 – Alto, 0 – Muy escaso
3 Impacto sobre la Bottom Line/Gastos 20% 10 – Grandes ahorros, 0 – Escaso
4 Ahorros operacionales 20% 10 – Altos, 0 – Nulos
5 Coste de la Migración 10% 10 – Escaso, 0 – Muy alto
Riesgos 6 Pérdida de control 25% 10 – Muy probable, 0 – Prácticamente ninguna
7 Impacto caso de no cumplirse el SLA 40% 10 – Muy Alto, 0 – Ninguno
8 Seguridad de la información 30% 10 – Escasa, 0 – Muy alta o los datos no son sensibles
9 Repercusiones legales/en el negocio en caso de revelación 5% 10 – Muy importantes, 0 – Escasas o la información manejada no es relevante
Adecuación 10 Facilidad de integración/complejidad 10% 10 – Sencilla, 0 – Muy compleja
11 Tamaño 40% 10 – Escaso, 0 – Grande
12 Compatibilidad técnica 40% 10 – Total o muy alta, 0 – Escasa o muy escasa
13 Simplicidad del diseño aplicativo 10% 10 – Muy alta, 0 – Escasa

La cumplimentación de este cuadro nos permitirá hallar un valor comparativo de cada una de las aplicaciones en los diversos ejes que nos servirán (suponiendo que cataloguemos de alto el valor si el resultado ponderado es mayor de 7,5 y así sucesivamente) para objetivar valor, riesgos y adecuación de cada una de las aplicaciones candidatas a externalizar.

Permanent link to this article: http://www.ingelan.com/?p=4426

Aug 26 2014

13 Criterios para decidir qué llevar al Cloud (Post 1 de 3)

Si usted ha oído (como un 88% de los empresarios españoles) hablar de Cloud Computing y está pensando (como cerca de un 40%) avanzar por ese camino, es importante que piense antes de actuar acerca de qué es lo que le conviene (por coste y riesgo) migrar a la nube. En esta serie de tres artículos le vamos a proporcionar algunos elementos de reflexión y criterios para separar el grano de la paja y acertar en el difícil equilibrio (si es eso lo que desea) entre lo que mantengo en casa y lo que saco fuera.

Cloud-Computing-B

Drivers y propuesta de valor de la arquitectura Cloud.

Los evangelistas de la infraestructura en la nube han concretado sus bondades en unas pocas (pero atractivas) promesas

  1. Eficiencia, estandarización y acceso ubícuo a los datos consecuencia de su flexibilidad, de la capacidad de añadir o sustraer capacidad en función de las necesidades de cada momento y del empleo de redes de comunicaciones abiertas con amplias capacidades de transmisión.
  2. Automatización y adaptabilidad que se concretan en un mucho más rápido y eficiente despliegue y que son consecuencia de la estandarización de medios y de la repetitividad de los procedimientos.
  3. Ahorro, debido a una estructura de costes dependientes de la utilización de los sistemas de información que pueden ser contabilizados como gasto.

Facilitadores.

Diversas aportaciones (quizá no novedosas pero sí aplicadas a esta finalidad) han posibilitado avanzar en la línea propuesta. Entre ellas:

  1. Las tecnologías de virtualización aplicadas a los sistemas medios, que facilitan compartir medios y recursos, previenen una utilización ineficiente de los mismos y facilitan combatir un incremento cada vez más irracional e imprevisible de los costes energéticos.
  2. Las mejoras en amplitud, disponibilidad y cobertura de las redes de comunicaciones basadas tanto en tecnología de cable como inalámbricas.
  3. El uso cada vez más imprescindible de dispositivos móviles (smartphones, tablets) para acceder a sistemas e informaciones de la organización.

Inhibidores.

Pese a todo y al muy atractivo planteamiento que todo ello pueda suponer, no ha existido un movimiento unánime hacia la adopción de esta nueva arquitectura. Los motivos son diversos, pero podríamos elaborar una lista no excesivamente exhaustiva apuntando a:

  1. Problemas derivados del escaso margen de personalización admisible, cosa necesaria para mantener una identidad diferenciada en un mercado hipercompetitivo.
  2. Necesidades de integración, interrelación e intercambio de información (junto con las responsabilidades derivadas) con otros sistemas y aplicaciones que pudieran estar alojados en otras nubes o en los sistemas propios de la entidad.
  3. Falta de control sobre los medios por parte de la organización, incluyendo las implicaciones de seguridad y legales que pudiera tener sobre ello la deslocalización de los centros de proceso de datos.
  4. La existencia de garantías necesarias sobre la seguridad física y lógica de la información almacenada, con el impacto – parcialmente fuera del control de la empresa – que posibles carencias en este aspecto podría tener en el cumplimiento de la legislación, de la normativa, en la imagen corporativa y en la confianza de los clientes.
  5. El futuro profesional de los técnicos y la inseguridad laboral que este panorama puede ofrecerles en contraposición con el creciente poder que estará en condiciones de ejercer el proveedor de los servicios, que se incrementará proporcionalmente a la dificultad en migrar o hacer reversibles los sistemas o aplicaciones.
  6. Las dudas acerca de la posibilidad de mantener en el futuro el modelo, una vez el mercado haya alcanzado el techo de uso y se haya estabilizado. Posibles retrocesos en situaciones de crisis podrían forzar a los proveedores a discontinuar la proporcionalidad coste:uso, desvirtuando uno de sus principales atractivos. Muchos observadores también recelan ante el entusiasmo de conversos mostrado por fabricantes hardware y software que vivieron en el pasado de la venta de equipos o licencias y a los que esta arquitectura ha recortado ingresos. ¿Cómo es que apoyan y favorecen una estrategia que ha hecho disminuir sus ventas? ¿Hay alguna estrategia a largo plazo tras de esta – presumiblemente – época de “vacas flacas”?

Permanent link to this article: http://www.ingelan.com/?p=4410

Página 1 de 3012345...102030...Última »