Threats & VulnerabilitIES Process Management

Fri, 19 Mar 2010 10:14:32 +0100

Introduction
What would you do if your favorite carmaker was recalling your car every month to fix some design flaw? Probably never buy again from them and switch to another vendor. Now let’s say you’re an airline CEO and the aircraft manufacturer is recalling planes or requiring specific fixes to be applied every weeks. Would you accept it? Would you fly them? Certainly not. However this is exactly what major software vendors are doing to businesses all around the world. It’s called software patching. A patch is a piece of software released by a software vendor to fix a defect. And software vendors release a continuous stream of patches, especially ones to fix security defects : vulnerabilities.
For companies software patching is a headache. Bruce Schneier, one of the world’s foremost security experts, said that «Everyone knows that [software] patching is in shambles. <…>The best patching techniques involve a lot of negotiation, pleading, and manual labor <...> things that nobody enjoys very much.».
KPMG’s risk and management business representatives said that «The board of directors doesn’t understand anything about security». However just like our airline CEO would have to globally manage issues with the airplanes with his staff, board members and customers, companies relying on IT must fulfill their IT and Security governance mission.
So how to reconcile the complexity of patching security vulnerabilities and the needs of board members and executives?
Consulare’s vision is to bring to executives a opensource software solution that will empower them to fulfill their IT and Security governance mission. The Executive Security Information System (ESIS) enables Chief Security Officers (CSO) and other executives as well as board members to truly and actively manage the company’s security strategy.
The Patching Game
Every day sees a number of new security vulnerabilities and advisories being published. Reading and understanding each advisory is one of the key missions of the IT security team and it is a non-trivial and tedious task. It often requires a sound knowledge of protocols and various technology layers to understand both the vulnerability and the proposed fix. It further requires that an analysis of the risk, or threat, to the company’s business be conducted; this blends in much more than technology and typically includes cost estimates of the impact of patching or not.
The length and complexity of the corporate process following the publication of a security vulnerability advisory by a vendor is nearly the same as the one that IT operations have been using over the last 20 years when dealing with standard bug fixes and upgrade patches. Therefore, it is neither new nor a discovery that this is a challenging and lengthy task. Apart from the sky rocketing number of security patches now published, the difference between these and regular patches is the sense of urgency. Common patches provide bug fixes and enhancements; clearly the severity of a bug can make patching, for some businesses, a critical matter. However this is the exception. Security patches, on the other hand, are almost always urgent. For the majority of businesses, low priority security patches are the exception!
Patching is not only a technical challenge, it also imposes a strain on organizations due to its heavy requirement for trade-off decisions. While IT departments have long lived by the motto: «If it’s not broken don’t fix it!», security staff must declare «patch it now or suffer!». There are valid arguments for both positions. Patching is a surgical act, it’s risky and dangerous, and IT operations have learned this through long years of painful experience. On the other hand, IT Security have quickly learned the price of not applying security patches. Worms like SQLslammer have brought down, in a matter of hours, entire companies for long and costly hours.
Measuring the risk and impact of applying a patch forms the great divide between IT and IT Security. The theory of risk decaying with time as more knowledge is gained about the impacts of a patch is quite unproven and often contradicted by field experience. The key is the overall complexity of the systems (applications, middleware, O/S and hardware) on which the patch needs to be applied. The fact that this complexity is likely unique for each system or group of systems is the major reason why patching is delicate and often results in high patching cost.
Certainly it is possible to gather external clues on the reliability and efficiency of a patch, however we’ve all been the victims of advice gathered on forums or support sites that unfortunately didn’t work, even though it should have! This type of outcome might be acceptable for a home Linux box, but not for mission critical clusters. External inputs however helpful, are no substitute for the delicate but necessary trade-off discussions between security and operations, which embody the real knowledge of the company’s IT systems.
Automation tools are of great help but they are just assistance to the deployment process, once a decision to patch has been made. Having an efficient patch deployment process just improves one part of the issue at hand.
The impacts inherent in changing a complex system comprised of millions of lines of interacting code is hardly predictable. In the end, companies must rely on the experience and judgment of their operations to come up with the recommendation to patch or not, as well as the critical planning and testing plans that a “go” decision entails.
A Management Issue?
What can executives and management do about vulnerability management? How are they supposed to act and re-act when asked to authorize the fix of a specific vulnerability? Should they even be involved in the sign-off process? How many resources should they allocate to vulnerability management activities? What is their company’s vulnerability management strategy? How much should they invest in it? These questions are among those that more and more executives and managers face regularly when new security vulnerabilities and patches appear, and as they are dragged into “vulnerability review” meetings or continuous vulnerability escalations.
The cost of patching is one key concern for executives. A research from the Meta Group estimates it takes 1,920 hours to apply 4 patches across 120 servers. The CERT reports 2,982 vulnerabilities for the Q1-Q3 2003 period. This leads to the uncomfortable conclusion that an entire IT department could be working 24x7 just to fix vulnerabilities! Some estimate the cost of securing one vendor’s software to be double the license cost. On the other hand, cost estimates of virus reach billions of dollars (Code Red: $2.6 billions; Love Bug: $8.2 billions; Melissa: $1.2 billions). Clearly risks versus cost trade-off decisions are needed; this is where executives have to be involved. But their involvement must be at a global level, not ‘per vulnerability’.
It is key to remember that a patch is a technology response to a technology problem: security vulnerability. Unlike some bugs that can be perceived as visible to users, ranging from being simply annoying to, in some cases infuriating, security vulnerabilities are normally invisible to users and usually don’t pose any issue to the day-to-day business - until an outbreak takes down part of the IT infrastructure. In the management chain where technical expertise and operational awareness decrease as strategy, organization and business increase, the most qualified to handle the patch decisions are middle managers guided by experts. These managers, usually operational security or incident managers, are the ones who can manage the technology and security discussions with Operations, whilst having the business and management perspective to deal with organizational, customer, and related business impacts. They can and should, of course, bring to executives those same delicate and complex business-related questions, which they refer on other topics.
Executives play a very crucial role in the vulnerability management process. They need to define and actively manage the overall vulnerability strategy, without having to participate in the low level operational and technology debates. This is a very challenging task today as the global bottom-up approach favored by security staff and vendors doesn’t produce the information and indicators managers require to accomplish this.
Executives need to tackle the patching problem at the global IT strategic level. In short, they must:
• Define the overall vulnerability management strategy and budget - related to other IT and security activities;
• Actively review the vulnerability process performance and costs within the overall perspective of the global IT environment;
• Report to the board and other executives on global goals and achievements.
It is only by being able to appropriately define a strategy, enforce and monitor the process and subsequently report and communicate about it that executives will be able to regain active control of the vulnerability and patch maelstrom.
Governing IT Security
Executives need to orient their strategies and investments, depending on their business and on the current situation, in order to make and accept appropriate trade-offs.
It is vital that these decisions are able to be clearly communicated and explained bidirectionally: up to peers and board members as well as down to staff and operations. Enabling communication is one key function of ESIS, the opensource Governance software backed by Consulare.
Executives must also monitor and build situation awareness in order to pro-actively manage IT security and thus fulfill IT Security governance. Situation awareness typically requires a very few indicators that can quickly depict complex situations. ESIS provides that capability through a reduced set of clear and efficient indicators. Plus, it has the ability to drill down through information levels in a way that sets up a full feedback loop with the operational levels.
The Return On Security Investments (ROSI) is risk economics that depicts a company attitude toward security. It should be answering business questions based on security numbers. ESIS with its indicators provides an efficient way to model part of the ROSI with a ratio in between the indicators objectives and the investment needed to reach them, it also explicit the trade-off in between indicators.
Compliance
The Compliance indicator is one of the six ICARRE indicators that comprise ESIS. Indicators are composite analytics that include information from various sources.
The Compliance gives to executives a picture of the company patching activity in comparison to the global patch issuance done by vendors. Therefore it provides the Compliance level compared to the industry. It is a major driver for strategy and investment decisions in patch.
For vendors, patch activity is defined as the number of patches issued by vendors over time. It can be viewed as unbalanced or balanced, the latter being the most interesting as it includes weighting based on the defined business descriptions, strategies and vulnerabilities. Both include all patches that relate to security that include stability, reliability, performance, etc., excluding features improvements.
For business, the patch activity is defined as the number of patches applied throughout the infrastructure over time. It can be viewed as unbalanced or balanced, the latter being the most interesting as it includes weighting based on the defined business descriptions, strategies and vulnerabilities. Part of the definition of the strategy is a threshold that defines acceptable patch Compliance and the time to move from that threshold to full Compliance.
The company’s business model definition is of utmost importance to properly define the patch strategy. For instance, an increase in the issuance of Oracle patches and one in the issuance of patches for Windows have completely different meaning for a company whose core business relies on Sun’s clusters of SAP/Oracle systems than for a managed services providers with web farms running Windows. Clearly, the inventory of systems is another important piece of information, but it needs to be balanced with the business view and corporate strategies.
Executives need to define the company’s patching strategy. This map enables then to globally define the expected level of Compliance and pro-actively manage it to decide on investments or initiatives. This is quite important, as the patching activity is irregular and resource heavy.
The key decision for an executive is to define strategies in terms of a Compliance rate and Compliance dynamic.
Compliance Rate
The Compliance rate is the difference in between the vendor patch activity and the company’s one. Let’s look at examples to illustrate it.
A company may discover that it is running at a 45% Compliance rate, which means that for a 100 patch published by vendors it deploys less than a half of them. It might be that for the business in which the company is, this rate is quite too low inducing a high Exposure. Therefore the CISO will negotiate with the CEO to bring that number to 70% over the next two years, with a corresponding investment plan. The ROI is then the 30 points improvement in the indicator.
A CISO sees a clear trend developing over a year of vendors issuing more and more patches, making the agreed upon Compliance rate less and less likely to be sustained. He drills down to discover that the European subsidiary is the one generating the increase through vendor AnyVendor - whose CRM is being standardize on. This leads to strategic discussions on either agreeing to lower the Compliance rate, hiring security staff in Europe, etc.
The Compliance rate let executives define, communicate and manage the overall company’s goal in term of patching. It drives investment decision in perspective of reaching the agreed upon rate. It enables executives to manage the situation whilst fully delegating to Operations the responsibility on tactical choices, appropriateness of a patch, etc.
In the case of an outsourcer it is a major enabler to precisely define Service Level Agreement.
Compliance Dynamic
However stable on a long-term horizon the Compliance rate fluctuates because:
• Patches are not issued on regular basis by vendors.
• Operational level varies for multiple reasons.
Therefore executives must decide either to give or not latitude to the operations as long as the Compliance rate target is reached at specific interval. This is a very important choice as it is very structural for Operations as it defines the Compliance dynamic. Let’s illustrate it with two examples.
A CSO may decide that for the company the Compliance rate must be met permanently. Making it a baseline floor that must not be broken, in which case the Operations will have to permanently sustain a minimal patching activity. In this scenario Operations load may vary greatly as it depend of the vendors patching rhythm.
Another company may decide that Compliance rate must be met, for instance, quarterly. In this case, Operations have much more latitude to schedule their work. They may combine a minimal patching activity with a “patchbowl” in the last month of the quarter.
The Compliance dynamic is a strategic point of inflexion. It sets the pace of the company on its patching journey.
Trade Offs
The Compliance duo, rate and dynamic, enables executive to define, communicate and monitor the company’s patching strategy. Such decisions of course embeds trade-off, first in between the two but also with other indicators like Exposure, Robustness or Reactivity.
As the Compliance rate is clearly a corporate objective, part of a global security strategy, the Compliance dynamic constrains the IT department on its process and priorities. Clearly the first one will be use to communicate with other executives, board members and IT department, whereas the second one will be expression of an agreement in between the executives and the IT department on how to reach the objective.
For executives deciding to reach a given level of Compliance must be part of a global security strategy, which is largely based on trade-offs to mitigate risks in the lights of business and budget constrains. For instance, companies faced with a vendor inability to stabilize their software, which wreck any reasonable possibilities of increasing the Compliance rate, might make a Compliance vs. Reactivity trade-off. Thus favoring an escalation and incident management approach. This is one example, as other companies’ business models and situation may drive, for instance, Compliance vs. Robustness decisions.
Trade-off is the fundamental tool of risk management. There is no single correct level of security; how much security company wants on one indicators will likely depends on what it is willing to give up on another. These trade-offs are often subjective and non explicit.

Conclusion
There is no easy answer to the patching problem, which due to embedded risks and criticality requires executive attention. However, executives must be able to manage it at the appropriate level – not interfering or being dragged into operational and technology day-to-day decisions. Executives need to be able to communicate with board members, auditors, and shareholders on objectives, policies and achievements on Compliance.
ESIS brings the right top-down approach that executives have been waiting for. Executives can define the overall patching strategy and pro-actively manage it in relationship with the IT and security operations. It enables executives to clearly communicate on this topic at the strategic but also operational level.
Effective and efficient IT and Security Governance is at the center of Consulare’s vision and opensource solutions ESIS

CLuB ISO 27001 (Paris, FR) : ISO 27004, métriques, indicateurs et tableaux de bord

Fri, 26 Feb 2010 12:27:53 +0100

Le Club ISO 27001
L'objectif du Club 27001 est de réunir les personnes intéressées par la série des normes ISO 27000, sous la forme d'un groupe de travail, de réflexion et d'échanges. Les réunions peuvent avoir des présentations, des discussions ouvertes, et des prises de décision. Le groupe est ouvert à tous, utilisateurs comme fournisseurs. Les présentations sont de toutes natures : explications sur les normes, retours d'expérience, solutions commerciales, etc... Il n'est pas nécessaire d'être membre d'une association pour participer au Club 27001.
Prochaines dates de réunions
Les prochaines réunions du club 27001 auront lieu aux dates suivantes :
Jeudi 25 mars  Présentation de "ISO 27004, métriques, indicateurs et tableaux de bord", par Philippe Le Berre, Consulare

Learn & Lunch : “ Discover ESIS - ISO 27001 : How to implement A process to manage audits, controls and action plans ?“

Thu, 7 Jan 2010 18:53:57 +0100

At the core of the ISO 27001 is the famous wheel of the PDCA (Plan Do Check Act) that enables to structure the overall information security process. For any CSO, the key challenge is to transform the ISO 27001 requirements into a set of actionable processes that match the organization maturity, resources and skills whilst delivering real and tangible benefits to the organization

We invite you to discover how the OpenSource Software ESIS enables organizations to put in place real and effective processes to manage key parts of the PDCA and ISO 27001.

During this “Learn & Lunch” you will discover :

• How to plan your process from defining responsibility, roles and worklow
• How to setup a referential (ie. ISO, PSSI, Scoring, etc.)
• How to setup a process and use it
• How to use the process indicators to deliver an Executive report on the process effectiveness and security posture

We look forward to welcome you on February 2nd from 12h to 14h at the Novotel Genève Centre.

This event is free (lunch included) but however limited to registered participants.

Learn & Lunch : “ Discover ESIS - ISO 27004 : How to implement metrics, indicators & dashboards ?“

Thu, 7 Jan 2010 16:52:03 +0100

In the last days of december 2009 the much awaited ISO 27004 was published, which provides guidance on the development and use of measures and measurement to assess the effectiveness of information security management. Now comes the question on how to transform these new requirements into real and effective metrics, indicators and dashboards.

We invite you to start this new year with a “learn & lunch” focused on how to implement the ISO 27004 and deliver effective metrics and dashboard with the OpenSource Software ESIS.

ESIS has unique features that enables organization to consolidate metrics into an holistic set of daily semantic metrics. The metrics are semantic hence independent from the sources and covering all key areas (ie. virus, threats, identity, attacks, assets, tickets, accounts, etc.). The metrics are daily hence enabling medium and long term analysis.

During this “Learn & Lunch” you will discover :

• How to cartography the metrics and build your metrics map
• How to plan and setup ESIS to consolidate metrics
• How to define and build ISO 27004 reports

We look forward to welcome you on January 28th from 12h to 14h at the Novotel Genève Centre.

This event is free (lunch included) but however limited to registered participants.

Le Responsable de la Sécurité des Systèmes d’Information (RSSI) peut-il et doit-il être le dépositaire responsable des risques de son organisation ?

Mon, 26 Oct 2009 17:20:29 +0100

Face à la montée en puissance des réglementations et standards, les organisations se questionnent sur le positionnement, voire la légitimité ou l’utilité, du RSSI. La notion de risques opérationnels est au centre des interrogations des dirigeants sur l’organisation et les processus à mettre en œuvre. En effet, il leur faut appréhender les liaisons, plus ou moins fortes, entre le risque opérationnel métier, l’information et les Systèmes d’Information. Du coup, le positionnement, le rôle et la responsabilité du RSSI est sous le feu des projecteurs, avec potentiellement des impacts non négligeable. Pendant ce temps celui-ci, dans cette quête existentielle, court d’intelligence économique en gestion des identités à la recherche de « qui il est » et de « ce qu’il est » pour son organisation.

Un RSSI pour quels Risques ?

Le risque opérationnel est défini par la Commission bancaire comme « le risque résultant d’une inadaptation ou d’une défaillance imputable à des procédures, personnels et systèmes internes ou à des événements extérieurs. ». Le risque opérationnel est donc avant tout celui des métiers, le risque d’un procédé de fabrication défectueux, d’un mauvais contrôle d’un bordereau par un back-office ou simplement d’une erreur lors d’un contrôle qualité en fin de chaîne de montage. Globalement, le risque opérationnel tend à mesurer la perfection, ou à l’inverse l’exposition au défaut, de l’organisation dans la réalisation de son métier. C’est un fondement pour évaluer la gouvernance et la qualité de la gestion d’une organisation. Il est bien naturel qu’actionnaires, législateurs et simples citoyens en demandent plus quand ces risques peuvent se traduire en Seveso, Enron, AZF, etc. L’homme moderne aime de moins en moins l’incertain, et l’imperfection humaine, chère à Platon, et ses effets n’ont jamais finalement autant été d’actualité !

Dans son analyse, le risque opérationnel peut avoir comme sous-jacent un ou plusieurs autres risques comme, par exemple, un risque de l’information, un risque informatique ou un risque de l’informatique. Par exemple, un risque de l’information pour la protection de la confidentialité d’un nouveau modèle, un risque informatique pour la défaillance d’une baie de stockage, un risque de l’informatique pour la difficulté à opéré un magasin sans informatique. La prépondérance de l’un ou plusieurs de ces risques sous-jacents va profondément influencer la stratégie de gestion des risques décidés par les dirigeants de l’organisation, et, par la même, les responsabilités du RSSI. Doit-il couvrir les risques opérationnels, inclure les risques de l’information ou plus traditionnellement se focaliser sur les risques informatiques ? L’enjeu est bien la pertinence pour l’organisation d’une notion de Direction des Risques qui engloberait les différents types de risques, de la contribution du RSSI à cette direction et avec l’éternelle balance entre centralisation et délégation.

Le RSSI un Manager des Risques

Il peut être intéressant d’aborder le métier de RSSI en faisant l’analogie avec un autre mieux défini et compris des organisations comme celui de Directeur Administratif & Financier (DAF). Le DAF n’est pas responsable de l’utilisation par chaque département des budgets alloués. Il est en charge de définir et mettre en œuvre les processus et l’organisation nécessaire au suivi de l’utilisation des budgets et des recettes. La comptabilité enregistre les opérations de crédits et débits de l’organisation et le contrôle de gestion procède à l’analyse des comptes, notamment à des fins de conformité et de pilotage. Ainsi pourquoi un RSSI devrait-il être le primo responsable des risques liés aux données nominatives d’un fichier de prospects ou clients, quand le Directeur Financier n’est pas lui le primo responsable des dépenses commerciales et marketing ? Le Directeur Financier a-t-il autorité pour expliquer au Directeur Marketing quand et comment il doit utiliser son budget ? Le RSSI doit-il seul décider du niveau de confidentialité d’un plan marketing et supporter les conséquences de la décision ?

Le RSSI doit, comme son homologue des finances le fait via la comptabilité et le contrôle de gestion, définir et mettre en œuvre les processus de gestion et de suivi des risques qui lui incombent. D’une part des processus de comptabilisation des risques pour augmenter et maintenir un référentiel alimenté par les métiers et unités opérationnelles. D’autre part, des processus de contrôle des risques pour structurer, analyser et communiquer la posture de l’organisation. Par la maîtrise de ces processus, le RSSI peut fournir à la Direction Générale une vision sur les risques de l’entreprise et apporter toute son expertise.

Mais, le responsable d’un risque, celui qui a autorité à l’accepter ainsi qu’à endosser les mesures de contingentement ne peut-être que le responsable du métier impacté. La vraie responsabilité du RSSI est le bon fonctionnement des différents processus de gestion des risques, du respect de leurs objectifs de performance et adéquation vis-à-vis de la stratégie et de l’organisation. C’est par la compréhension du cap fixé par les dirigeants que le RSSI peut bâtir l’itinéraire vers l’objectif de la gestion des risques : la compréhension et la maîtrise de la résilience de l’entreprise face aux risques.

La responsabilité des incidents et des crises

Les traumas de la Sécurité des Systèmes d’Information (SSI) issus des crises et incidents sont toujours inégaux puisqu’ils surviennent à des moments différents sur des Systèmes d’Information (SI) et des organisations qui évoluent en permanence. Pour le RSSI un malheur n’est jamais miraculeux, mais il présente une opportunité pour construire ou étendre sa légitimité personnelle, organisationnelle et fonctionnelle. Face à un incident ou une crise, le RSSI peut soit se soumettre à la fatalité et devenir « le Jacques » des SI ou la surmonter grâce à la maîtrise des processus de gestion des risques informatiques. Le RSSI doit-il être un héros coupable d’avoir réduit les menaces ?

Le danger d’une dérive d’un fatalisme aggravé mettrait le RSSI face à des choix névrotiques comme celui d’attendre volontairement l’incident, « je vous l’avais dit ! », se mettant ainsi en conflit tant avec son éthique personnelle que de son engagement moral auprès de l’entreprise. Le RSSI doit savoir surmonter cela et ainsi faciliter son intégration dans les rites sociaux et organisationnels de l’entreprise. Le catastrophisme et l’appel aux loups, si cher à l’industrie de la sécurité, sont un fatalisme de mauvais alois, ils doivent être oubliés pour que le RSSI devienne un Manager normal, qui organise, gère, délivre et surtout communique. La première utilité de la communication est de tisser la relation avec le reste de l’organisation et plus particulièrement la Direction Générale au travers de tableaux de bord sur la performance des processus de gestion des risques.

L’oubli ouvre la porte à la répétition alors que l’abus de mémoire prépare la répétition intentionnelle. Face à un incident ou une crise, le mantra du RSSI doit être « ni oublier, ni utiliser »: le seul moyen de s’en sortir, c’est de comprendre pour optimiser et faire évoluer les processus dont il est responsable. Le travail du RSSI, comme celui de beaucoup de manager, n’est pas une histoire linéaire mais une résolution incessante de problèmes, qui remis en perspective, reconstruit dans le cadre de l’histoire des risques et processus de l’entreprise, prend une toute autre signification.

Des technologies de la sécurité au Management des Risques

Si le RSSI ne peut ou ne sait affirmer son rôle d’organisateur de la gestion des risques, il est en péril de passer son temps à souffrir et se plaindre. Les raisons de cette incapacité peuvent être humaines, car le métier de RSSI oblige à abandonner le monde des technologies pour entrer dans celui du Management et d’une logique d’entreprise. C’est un saut qui peut être difficile et où le suivi d’une formation complémentaire, comme un MBA, est souvent salutaire pour acquérir les compétences nécessaires. A défaut, le retour vers un poste technologique de Responsable Informatique de la Sécurité (RIS) au sein de la Direction Informatique est à rechercher. La nomination de RSSI non-technique mais issus du monde juridique, des métiers est une tendance lourde et profonde de l’industrie, appuyée par les enjeux globaux de la gestion des risques. L’incapacité peut aussi venir de l’organisation et de sa Direction Générale qui peuvent ne chercher, par la création du poste de RSSI, qu’une étiquette de bienséance et de bonne conscience, et, parfois, rien d’autre qu’un bouc émissaire prêt à consommer au premier malheur.

La poussée réglementaire catalyseur du changement

Les évolutions réglementaires (Sarbannes-Oxley, Bâle II, Solvency II, LSF, CRBF 97-02, etc) ont, pour les organisations soumises à conformité, généré un électrochoc auprès des Directions Générales dans leur compréhension des enjeux de la gestion des risques et du rôle de RSSI. Toutes ces réglementations se fondent sur une approche processus de la gestion des risques opérationnels. Les risques informatiques sont soit une catégorie de risque opérationnel pure, notamment par la résilience des SI et plus particulièrement le Plan de Continuation d’Activité (PCA), soit un sous-jacent d’un risque métier. Si l’on ne doit pas forcément souhaiter la généralisation de ce type de réglementation à toutes les organisations, il n’en demeure pas moins que l’on doit chercher dans l’exemple des travaux de conformités les indicateurs fondamentaux de l’évolution du métier de RSSI et de ses processus de gestion des risques.

Philippe Le Berre
Directeur

SEMINAIRE : “ Quel reporting sur la gestion des risques du SI pour les directions générales ? “

Tue, 6 Oct 2009 07:22:35 +0200

Consulare organise un séminaire le 5 novembre matin à Genève.

En ces temps de crise, la défiance peut insidieusement faire son œuvre de toute faille de gouvernance. Il n’est plus de nom ou de réputation qui puisse protéger, et la fameuse clause de « plausible deniability » a vécu.

Le RSSI se trouve à la croisée des chemins entre les approches globales de gestion des risques, la conformité réglementaire, les multiples audits et les nouvelles approches qualité du SI. Il ne peut tout faire, ni tout endosser. Plus que jamais, le RSSI doit affirmer ses missions et son positionnement au sein de l’organisation.

Il doit donc traduire ses réalisations, contributions et objectifs tout en apportant à sa Direction une compréhension renouvelée du risque opérationnel d’une défaillance du SI et des moyens mis en œuvre tant pour la prévenir, que la gérer, et y remédier.

A partir d’une approche pragmatique et sans dogmatisme, ce séminaire a pour objectif d’échanger sur les questions suivantes :

• Sur quelle(s) base(s) le RSSI peut-il définir avec la Direction ses missions et ses objectifs ?
• Quels sont les positionnements possibles dans l’organisation, et les plus adaptés pour atteindre ses objectifs ?
• Comment le RSSI peut-il organiser, structurer et piloter les missions de son activité ?
• Avec quels moyens le RSSI peut-il communiquer sur ses résultats et affirmer son rôle et sa contribution ?

Pour vous inscrire contactez-nous sur contact@consulare.ch ou télécharger l’invitation ci-dessus.