viernes, 29 de abril de 2016

Seguridad versus agilidad

La gestión de la seguridad es uno de los procesos que podemos encontrar en la mayoría de metodologías. Sin embargo el grado de importancia que se ha ido dando a este proceso ha ido variando a lo largo del tiempo.

-----------------------------------------

The security management is one of the processes that can be found in most of methodologies. However, the level of importance that has been given to this process has been changing over the time.

------------------------------------

Si nos acordamos de la versión 2 de la metodología que más hablamos, la seguridad se encontraba dentro de otro proceso (el de disponibilidad), y no tenía entidad suficiente para ser un proceso independiente. Por aquel entonces la seguridad se basaba únicamente en tres conceptos
  •           Confidencialidad
  •           Integridad
  •           Disponibilidad

Sin duda los tres son de vital importancia, pero claramente no son suficientes para una buena gestión de la seguridad.

De hecho en la versión 3, se convirtió en un proceso independiente, y nos daba ciertas pautas para mejorar las políticas, sistema gestión, gestión de riesgos, etc. De hecho hay una referencia clara a la ISO correspondiente, como mejor forma de gestionar la seguridad.

Y una vez que hemos contado un poco de historia, ahora toca reflexionar cómo podemos agilizar el proceso de seguridad, si fuera posible, y en qué medida debemos manejar el equilibrio entre seguridad y agilidad.

Para un paranoico como yo, creo que no hay equilibrio. La seguridad puede agilizarse a través de automatismos, pero nunca reducirla para tratar de hacerla “ágil”. De hecho, en mi opinión, debe potenciarse, dado que cada vez más, la seguridad se está convirtiendo en el caballo de batalla (o de Troya).

En las normas clásicas hablamos de seguridad, pero cuando se escribieron, prácticamente no había smartphones, lo mismo ocurría con las App’s. No existían los smartwatches, no se habían inventado los wearables, ni se hablaba del Internet de las cosas. Es decir, nada relativo a la ciberseguridad.

Normas actuales como PCI DSS, obligan a realizar hacking éticos de forma periódica, a realizar escaneos de red. Normas no escritas recomiendan tener algún soporte para analizar la Darkweb, y ver que se dice de nosotros. Tener un SOC externo, que realice estas tareas, puede ser altamente recomendables. Etc.

La seguridad es un proceso que tiene que estar presente en todos los proyectos desde el inicio, para que puedan tenerse en cuenta las necesidades desde el primer momento, y no encontrarnos con sorpresas de última hora.

Concienciar a nuestros usuarios, e incluso a nuestros clientes, puede ser muy útil para evitar infecciones de malware.

Ya se sabe que sólo hay dos tipos de empresas. Las que son atacadas, y las que no son conscientes de que están siendo atacadas. Ahora nos toca posicionarnos en una de las dos.

Aligerar los controles para ser más ágiles, puede repercutir en consecuencias graves, así que en mi opinión, este proceso debe estar vivo cada día, incorporando nuevos controles, aún a riesgo de ralentizar el proceso en sí, y no esperar a una nueva versión que puede llegar entre tres y cinco años.

Los datos son la nueva moneda de este siglo, y hay que mantenerlos a buen recaudo y custodiados, así que aquí lo dejo con una pregunta.

¿Estás seguro que estás seguro?

Share/Bookmark

sábado, 23 de abril de 2016

Día del libro 2016

Hoy es el día del libro. Estos días (ayer y hoy), se celebra el aniversario de la muerte de dos grandes escritores, Cervantes y Shakespeare.

Creo que se merecen un homenaje

-------------------------------------

Today is the World Book Day. These days (yesterday and today), is the anniversary of the death of two great writers, Cervantes and Shakespeare.

I think they deserve a tribute
Share/Bookmark

viernes, 22 de abril de 2016

Gestión Financiera Ágil

Hoy me he propuesto reflexionar en voz alta sobre el proceso de Gestión Financiera, y cuestionarme algunas de las tareas que se realizan, para tratar de agilizarlo.


Sin entrar en mucho detalle, voy a centrarme en los tres grandes bloques que ya veíamos en las metodologías de hace 10 años, y que en algunos casos fueron modificadas o incluso eliminadas posteriormente en algún estándar internacional.

------------------------------------------------

Today I plan to think aloud about the financial management process and questioning some of the tasks that are work with and try to make them agile.

Without going into much detail, I will focus on three main blocks already saw in the methodologies of 10 years, and in some cases were modified or even eliminated later in some international standard.

-----------------------------------

Como podréis ver, intento no poner nombres de metodologías ni estándares, aunque según vaya entrando en harina, sabréis a que me refiero, eso, si no lo sabéis ya.

Recuerdo que hace una década (o algo más), hablábamos de tres grandes bloques dentro de este proceso.
  1.  Presupuestación.
  2.   Contabilidad.
  3.  Facturación.

El primer punto, la presupuestación, creo que es una tarea que debemos mantener. TI es quién conoce qué necesitamos y cuándo lo necesitamos, y por lo tanto tiene que tener un plan a tres o cinco años, que le ayude a preparar los presupuestos anuales de forma coherente.

Aquí hay que tener en cuenta que no todo se basa en nuestras previsiones sino que hay otros parámetros que entran en acción y que tendremos que ayudar a valorar.

  •          Necesidades por cambios legales.
  •          Necesidades por temas relativos a la seguridad.

Nuestras previsiones podrán prever las necesidades por obsolescencia, que es algo que podemos planificar con tiempo.

  •          Bien porque se ha llegado al límite de su vida útil.
  •          Bien porque se ha llegado al fin del soporte del fabricante (hw o sw).

Con todo esto podremos planificar nuestros costes de inversión, y nuestros gastos asociados.

El segundo punto, la contabilidad, es algo que empiezo a replantearme desde cero.

¿No estaremos haciendo un trabajo que debe ser realizado por otros departamentos?

¿No estaremos en algunos casos haciendo un trabajo doble a nivel corporativo?

¿No estaremos basándonos en unas premisas que nos dice nuestra metodología, y que quizás no sea la misma que la compañía realiza a nivel corporativo?

Si hablamos de empresas pequeñas, claramente no tiene sentido. Al final hay una cuenta común de gastos, porque no hay departamentos claros donde imputar.

Si hablamos de empresas grandes, en algunos casos es tan tremendo el follón de separar estos conceptos para imputar a cada área, que muchas veces nos cuesta más el collar que el perro, y estaremos incurriendo en un gasto que no tiene retorno a nivel corporativo. Eso sí, tendremos un control absoluto de quién gasta qué. Pero claro, si queremos ser ágiles y enfocarnos al cliente, me van a perdonar Ustedes que les diga que al cliente esto le importa un pimiento.

Por lo tanto, y en mi modesta opinión lo quitaría, aunque esto cree polémica y un debate que espero sea fructífero.

El tercer punto, la facturación, claramente no ha lugar, desde mi punto de vista, porque si elimino el punto anterior, nunca podré llegar a este.

De hecho, como bien sabéis esta tarea ya se quitó en un estándar internacional que acaba en 20000.

Del resto de conceptos que están dentro de este proceso, de momento no los voy a tratar. Como ya dije la semana pasada intentaremos agilizar aquellas tareas que entendamos que no aportan un valor añadido al cliente, y estas que he comentado hoy, son las primeras que me han venido a la cabeza.

Otro día que tenga ganas de estrujarme mi materia gris, seguro que doy otro repaso.

Share/Bookmark

jueves, 14 de abril de 2016

Adaptar modelos tradicionales, para convertirlos en ágiles

Durante años hemos trabajado en base a modelos tradicionales como ITIL, ISO 20000, Cobit, Prince2, etc, con buenos resultados y una importante aportación de valor, al obtener mejoras sustanciales, sobradamente demostradas por multitud de compañías.

En los últimos años, la explosión de las aplicaciones web, y sobre todo las App’s, han hecho saltar las alarmas a los profesionales de TI, sobre todo en el lado de la operación, donde no podemos atender con la agilidad que nos requiere el negocio, las nuevas necesidades, siguiendo con los modelos tradicionales.

----------------------------------------------


For years we have worked based on traditional models such as ITIL , ISO 20000, Cobit , Prince2 , etc. with good results and a significant contribution of value , to obtain substantial improvements , amply demonstrated by many companies.

In recent years , the explosion of web applications , and especially the App 's, have set off alarms to IT professionals , especially on the side of the operation, where we cannot deal with the agility that requires us business , new needs , following traditional models.

------------------------------------------


En la parte de desarrollo, han llegado nuevos métodos como SCRUM, Kanban, etc, que nos ayudan a agilizar los procesos de desarrollo, para poder realizar nuevas aplicaciones, o modificaciones a las mismas, en un tiempo menor.

Así que ahora nos toca ponernos las pilas en la operación, para que la reducción de tiempos en la creación de nuevos desarrollos, se vea acompañada con la misma reducción en la implantación. Es el momento de tener una Gestión de Servicios Ágil, o como lo denominamos en ITSMF, una ITSMAgil.

¿Esto significa que antes no éramos ágiles?. Por supuesto que no, pero lo que sí está claro, es que si seguimos los procedimientos tal y como los tenemos documentados hasta ahora, los tiempos se alargan. No por falta de agilidad, sino por exceso de actividades intermedias.

Las opciones son varias. Podemos abandonar los modelos tradicionales, lo cual sería un error, en mi humilde opinión, o bien actualizarlos al contexto actual.

Por otro lado podemos utilizar nuevos moldeos como DevOps, que nos permitirán trabajar en modo binomio entre Desarrollo (Dev) y Operaciones (Ops), y que incluye en su ciclo de vida, a todas las partes involucradas, trabajando al mismo tiempo, y en constante armonía.

Desde el Comité de Estándares, queremos dedicarnos este año a analizar cómo podemos agilizar los modelos, y adaptarnos a los nuevos tiempos, y para ello hemos creado 7 Grupos de Expertos con las siguientes temáticas:

1.       La Gestión TI a dos velocidades (Bimodal IT)
2.       La Gestión de los nuevos Servicios Digitales
3.       La Conexión Ágil, extremo a extremo, desde el negocio hasta la producción
4.       La Gestión de Servicios alojados en Cloud externos
5.       La Gestión de Servicios en Pymes
6.       La Adaptación de los modelos estructurales como: ITIL, ISO20000, COBIT, PRINCE2
7.       Nuevos modelos que se incorporan al mercado como IT4IT

Este documento es una pequeña introducción al grupo número seis, “adaptación de modelos”, donde intentaremos liberar de grasa a los modelos actuales aplicando LEAN, y convirtiéndoles en algo más sencillo, y por lo tanto más ágiles.

No es una revolución, sino una evolución natural para adaptarnos a las nuevas necesidades. 

No es una nueva versión oficial de los modelos, sino una reflexión de los que día a día estamos en el terreno.

No es un intento de echar por tierra el buen trabajo que hemos desarrollado con estos modelos, sino romper con los moldes establecidos y replantearnos los procesos desde cero.

Los modelos se han creado a partir de buenas prácticas, y éstas a su vez van evolucionando. Entonces, ¿por qué no las trasladamos a los modelos?.

Las formas de trabajar cambian. Bimodal IT nos dice que hay dos velocidades. La que trata proyectos tradicionales como aplicaciones financieras o bancarias, y la que trata proyectos ágiles como una App para compra o de recetas de cocina. Entonces, ¿por qué sólo tenemos modelos de una velocidad en operación?

Durante las siguientes semanas, iremos desgranando los procesos de los modelos de referencia que hemos mencionado anteriormente, y aportando nuestra visión de cómo deberíamos evolucionarlos, para que se adapten a los nuevos requerimientos.

Hay que ganar en agilidad, tenemos que convertirnos en Agileman.
 

Share/Bookmark

jueves, 7 de abril de 2016

Master en Ciencias Políticas VIII

Estos días han salido a la luz, los famosos papeles de Panamá, añadiendo a la lista de personas con bienes en paraísos fiscales, a personalidades conocidas, tanto de nuestro país como de otros.

Cómo se han conseguido estos datos, es otra cosa. Una filtración de 2,6 Tb de información, no son unos papeles que alguien ha encontrado en la basura.

------------------------------------------------


These days have come to light , the famous Panama papers, adding to the list of people with assets in tax havens, known personalities from both our country and others. How have gotten these data, it is something else. A leak of 2.6 Tb of information are not papers that someone has found in the trash.
Share/Bookmark