As crime progressed along with techniques and technologies, the integration of AI into the cybercriminal’s arsenal was, all in all, fairly natural and predictable. Initially used for simple operations such as decrypting captchas or creating the first deepfakes, AI is now employed for a much wider range of malicious activities.  

Continuing our series on cybersecurity and AI (Attacking AI: a real-life example, Language as a sword: the risk of prompt injection on AI Generative, ChatGPT & DevSecOps – What are the new cybersecurity risks introduced by the use of AI by developers? ), we delve into the instrumentalization of AI by cybercriminals. While AI enables an escalation in the quality and quantity of cyber attacks, its exploitation by cybercriminals does not fundamentally challenge the defense models for organizations.  

The malicious use of AI by cybercriminals: hijacking, the black market and DeepFake 

The hijacking of general public Chatbots 

In 2023, it’s impossible to miss ChatGPT, the generative AI developed by OpenAI. Garnering billions of requests per day, it’s a marvellous tool, and the use cases are numerous. The potential and value added by this type of tool are vast, making it a prime target for exploitation by malicious actors. 

Despite the implementation of security measures aimed at preventing misuse for malicious purposes, such as the widely-known moderation points, certain techniques like prompt injection can evade these safeguards. Attackers are not hesitant to share their discoveries on criminal forums. These techniques predominantly target the most extensively used bots in the public domain: ChatGPT and Google Bard. 

Screenshot from Slahnext article. 

But other, more powerful tools could do even more damage. For example, DarkBert, created by S2W Inc. claims to be the first generative AI trained on dark web data. The company claims to pursue a defensive objective, in particular by monitoring the dark web to detect the appearance of malicious sites or new threats.  

In their demonstration video, they draw a comparison in response quality from different Chatbots (GPT, Bard, DarkBert) when ask about “the latest attacks in Europe?”. In this particular case, Google Bard provides the names of the victims and a fairly detailed answer to the type of attack (plus some basic security advice), ChatGPT replies that it doesn’t have the capacity to answer, while DarkBert is able to answer with the names, exact date and even the stolen data sets! Even in instances where the data is supposedly inaccessible, it’s conceivable to coerce the model into revealing and disseminating the specific data sets. through the use of oracle attack techniques (attacks that combine a set of techniques to “pull the wool over the AI’s eyes” and bypass its moderation framework), to get the model to reveal and communicate the data sets in question. 

The paramount lies in malevolent actors harnessing the capabilities of these tools for nefarious purposes, such as to obtain malicious code, have particularly realistic fraud documents drafted, or obtain sensitive data. 

Nonetheless, the utilization of prompt injection and Oracle techniques remains somewhat time-consuming for attackers, at least until automated tools are developed. Simultaneously, chatbots continually fortify their defence mechanisms and moderation capabilities. 

The black market in criminal AI  

Slightly more worrying is the publication of purely criminal generative AI Chatbots. In this case, the attackers get hold of open source AI technologies, remove the security measures, and publish an “unbridled” model.  

Prominent tools such as FraudGPT and WormGPT have now surfaced in various forums. These new bots empower users to go even further: find vulnerabilities, learn how to hack a site, create phishing e-mails, code malware, automate it and so on. Cybercriminals are going so far as to commercialize these models, creating a new black market in generative AI engines. 

Screenshot from the Netenrich blog article showing the different uses of Fraud Bot. 

Exploiting human vulnerability: ultra-realistic DeepFakes 

The major concern lies in the increasing use of ultra-realistic DeepFake. You’ve probably seen the now-famous photos of the Pope in Balenciaga, or the video of the 1988 French presidential debate between Chirac and Mitterrand, perfectly dubbed in English and bluffingly realistic.  

In the latest Cybersecurity Information Sheet (CSI), Contextualizing Deepfake Threats to Organizations (September 2023), published by the NSA, FBI and CISA, some examples of DeepFake attacks are given. Among them, a case in 2019 in which a British subsidiary in the energy sector paid out $243,000 because of an AI-generated audio; the attackers had impersonated the group’s CEO, urging the subsidiary’s CEO to pay him this sum with the promise of a refund. In 2023, cases of CEO video identity fraud have already been reported. 

These attacks introduce a novel and concerning dimension to cybercrime, presenting formidable challenges in identity verification and evoking ethical and legal questions, particularly regarding the dissemination of false information and identity theft. They exacerbate the most critical vulnerability in IT cybersecurity: the human element. There’s a clear trajectory indicating a proliferation of cases involving President fraud and phishing employing DeepFake techniques in the upcoming months and years. 

AI as a tool for attackers, not a revolution for defenders 

It’s undeniable that the utilization of AI Chatbots, whether for consumer engagement or criminal endeavors, will facilitate a surge in carried-out attacks, delivering higher quality results. With enhanced technical skills and the ability to identify vulnerabilities, alongside readily available resources, both comprehensive and partial, less experienced individuals can now conduct advanced, more qualitative, and higher-impact attacks. 

However, the application of AI by malicious actors will not fundamentally revolutionize how companies defend themselves. The impact of an AI-generated or AI-supported attack will remain limited for mature organizations, just as with any other forms of attacks. When your defenses are fortified, the caliber of the weapon firing at them becomes less significant. 

Messages, processes and tools will have to be adapted, but the concepts remain the same. Even the most sophisticated and automated malware will struggle to make headway against a company that has properly implemented defense-in-depth and segmentation mechanisms (rights, network, etc.). Basically, even if an attack is AI-boosted, the objective remains to protect against phishing, fraud, ransomware, data theft, and the like. 

Concerning DeepFakes, employee awareness will continue to be paramount. Anti-phishing training courses must be adjusted to encompass techniques for detecting and responding to this evolving threat. Lastly, prevention encompasses fostering an understanding of disinformation techniques and adopting appropriate precautions (reporting, evidence preservation, source verification, metadata checks, etc.). 

Undoubtedly, those employing behavioral analysis tools or automating aspects of their incident response possess an advantage in mitigating potential compromises. To further this advantage, consider exploring and testing the AI beta features within your existing solutions — a gradual integration of AI into your security strategy. Although not all vendor promises have been fully realized yet, integrating AI in this strategic manner is a step forward. For the more mature, take advantage of your new strategy cycle to explore new AI-boosted tools, for example for detecting deep fakes in real time, capable of analyzing audio and video streams. These will provide an additional layer of security to existing detection tools. 

In conclusion, let’s keep a cool head! 

The integration of AI by cybercriminals poses a significant threat that demands urgent attention and proactive measures. However, it’s not so much about revolutionizing security practices as it is about continual improvement, updating, and adaptation. 

Above all, security teams must adopt a proactive stance in confronting the challenges raised by artificial intelligence. Through process adaptation and staying informed about advancements in these technologies, teams can navigate these changes calmly, enhancing their ability to detect emerging threats. Existing defense techniques should be flexible enough to cover a majority of risks. 

It’s also important not to neglect the security of your use of AI: whether it’s the risk of loss of data and intellectual property with the use of consumer Chatbots by your employees, or the risk of attacks (poisoning, oracle, evasion) on your internal AI algorithms. It’s vital to integrate security throughout the entire development cycle, adopting an approach based on the risks specific to the use of AI.  

On September 11, 2023, CNIL (French National Data Protection Commission) President, Marie-Laure DENIS, called for “the need to create the conditions for use that is ethical, responsible and respectful of our values” before the French National Assembly’s Law Commission. The emerging technological landscape necessitates a thorough understanding, risk assessment, and regulation of AI applications, particularly by aligning them with the GDPR. The time is ripe to contemplate these matters and establish appropriate processes accordingly. 

Cet article The industrialization of AI by cybercriminals: should we really be worried? est apparu en premier sur RiskInsight.

We have cited five key success factors needed to deliver an ERP permissions risk-remediation project:

The key success factors for an ERP permissions risk-remediation project

The first two key success factors were discussed in the previous article; and the other three are covered in this one.

3. Preparing for large-scale deployment

Services, business lines, geographical or legal entities… the remediation of permission-related risks means reviewing user accounts across varied—and often numerous—functional areas. To be able to keep to schedules, limit workloads, and reassure those involved in the project locally, it’s best to deploy things at as larger scale as possible. Doing this means:

• Defining and communicating the risk analysis and remediation methodology;
• Putting in place a steering plan;
• Introducing analytical tools, automated as far as possible, to cope with volumes;
• Formally preparing materials for workshops and consolidation sessions;
• The documentation for the methodology and the tool in order to be able to train users.

These documents will form the deployment kit to be used in the different areas of work of the project phase; this can also continue to be used when the project phase is complete.

The deployment kit for an ERP permissions risk-remediation project

The deployment methodology will need to cover the following activities, and will need to be recreated for each area of work:

• Risk assessments and the definition of KPIs.
• Remediation workshops for user-related risks.
• Validation and execution of remediation plans.
• Training and support for upskilling.

Obviously, the methodology must be adapted to the company’s organizational structure and the resources available to it: the workforce, local variations in business processes, the degree of maturity in risk and permissions management, etc.

In particular, this will involve engaging local experts both on the technical aspects of permissions (access rights officers, application owners, security officers), and on the business-function aspects of processes (business-function representatives, process owners, internal controllers, team managers, etc.). The contribution that will be expected from them, and the effort they will need to put in, should be clear from the start and must remain “reasonable”. Local managers should therefore be involved, to ensure that those who need to take part do so, and to help in decision-making.

During remediation workshops, participants will, in particular, analyze user-related risks, but they will also have to consider various remediation strategies, such as the ones described below:

Strategies to consider in an ERP permissions risk-remediation project

It’s always preferable to validate the methodology using a pilot project that is small enough to limit work volumes, but large enough to be representative of the company. In some cases, a better strategic choice may be to select a work area that’s likely to be more fruitful for the project; or, conversely, one that’s expected to require more support. The lessons learned at the pilot stage will allow the methodology and tools to be adjusted before they are deployed more widely.

4. Selecting the right tools

The tools put in place must aid success during the project phase, but also—and more importantly—provide long-term support for the chosen approach; both these phases must be complementary.

Being well equipped is about being clear on the initial controls to be applied (at the point when new permissions are requested) as well as on the ongoing controls (those applied once permissions have been granted). Having more initial controls will help reduce risks, but operational efficiency may also suffer (delays, difficulties in processing requests, etc.); a balance needs to be found.

From a functional point of view, it’s a question of putting in place the families of controls typically found in such projects, namely:

• Data quality controls: completeness and coherence of data; respect for nomenclature, etc.
• IT security-rule controls: orphan, dormant, and administrator accounts; temporary and residual permissions; IT accounts with business-function permissions and vice versa, etc.
• Business-functions rules/compliance controls: discrepancies between jobs and the associated permissions; discrepancies in permissions between members of the same team; breaches of rules on the segregation of duties; users having access to areas that are beyond the scope of their responsibility, etc.
• Usages and behavior control: excessive or unusual uses, suspicious behavior, typical fraud scenarios, etc.

Families of typical controls for an ERP permissions risk-remediation project

Being well equipped is also about prioritizing and automating the controls that are worth putting in place. The return on investment must be assessed in terms of each control’s relevance to the company’s situation (does the control cost more than dealing with the consequences of the risk it’s designed to cover?), and the potential benefits of automation (how much will be saved compared with a manual process?).

The volumes and complexities associated with ERP authorization models means turning to tools specifically designed for the task: for example, it’s not unusual to see SAP systems with several thousand roles and over a hundred thousand fine-grained permissions (transactions and authorization objects).

These needs fall at the intersection of several different segments of the software market; these are currently highly dynamic and far from mutually exclusive: “Identity and Access Management”, “Continuous Control”, “Specialized Governance-Risk-Compliance tools on a given ERP”, and so on. Given this, the approach taken, degree of maturity, functional coverage, and mode of delivery (on site or cloud/SaaS), can vary substantially from one product to another.

When selecting a tool, it’s a question of considering the following elements carefully:

• Ergonomics and ease of use: once the project is finished, the tool’s users will be mostly from business functions—not from IT.
• Customization options: such that the tool really can be used to support the methodology taken (vocabulary and screens, rules and controls, dashboards and reports customized to company needs, etc.).
• A package of preconfigured controls: usually based on good practice, for the company ERP.
• The ability to put in place controls on other applications, and between applications: over the medium-term.
• Analysis and decision support functionality: to highlight anomalies, simulate changes in permissions, conduct in-depth analyses, suggest remediation measures, etc.

Although the tools are generally not intrusive, in terms of their effect on applications, there’s still a need to automate the transfer of data, in a reliable way—from the ERP and other potential repositories. Involvement of the relevant IT teams will thus be needed too.

5. Getting things right for the long term

Projects of this type only make good sense if permission-related risks can be controlled effectively over the long-term. Doing so avoids the problem of risks that have been brought under control during the project appearing again—some time later.

To encourage long-term buy-in to the approach and tools put in place, it’s essential to invest in change management from the start—and throughout the project—by means of meetings and regular newsletters, training and coaching sessions, documentation and tutorials, etc. It’s best to use a diversity of channels and communication supports to reach the maximum number of people without giving the impression of over-marketing.

It’s also important to help those responsible for permission-related risks to apply new controls to their recurring activities. In fact, the frequencies of advanced controls, the objectives to be achieved, and the levels of risk that must not be exceeded, can be explicitly defined. These objectives must be realistic and progressive: “What’s needed is to envision a long road—but with short milestones.”

There must be an emphasis on community too: it’s important to encourage interactions between managers from different functions, which will enable them to share experiences and good practice. There may even be a value in introducing a degree of healthy competition between different business functions; perhaps even organizing some low-key challenges. However, you should ensure that the fact of making progress is valued more highly than achieving any specific numerical objective, because the various work areas will have to progress from very different starting points.

Finally, an “ongoing” mode needs to be implemented—to ensure that permission-related risks remain under control once the project is completed. This should include:

• Choosing a designated contact for the methodology and tools put in place;
• Upskilling the technical teams to ensure in-service support for tools, and that reports and controls can be developed when necessary;
• Documenting and capitalizing on the knowledge acquired during the project phase.

This must give consideration to developing a roadmap for other future activities that will address new processes, risks, applications, or populations.

Long-term control of the risks related to ERP permissions

In conclusion: it can be done!

As we’ve seen in the two articles on this topic, controlling the risks related to ERP permissions means pursuing a number of key workstreams—from putting in place the right tools, through holding workshops for the business functions, to training and change management.

But with a good methodology and committed participants from IT and the business functions on board, anything is possible! Tangible results can be achieved—and corporate momentum built—within a reasonable timeframe, to regain control of permissions across the IS. And, lastly, the key success factors presented here are broadly applicable to applications other than ERPs.

Cet article ERPs: How to control permission-related risks (PART 2) est apparu en premier sur RiskInsight.

La standardisation est l’une des caractéristiques du Cloud. Si l’entreprise veut en tirer tous les bénéfices, opérationnels comme économiques, elle doit accepter et faire accepter aux utilisateurs un degré de standardisation important. Le déploiement du Cloud en entreprise implique un changement de posture pour la DSI et une évolution radicale dans les mentalités, au sein des équipes informatiques comme du côté des Métiers.

Le challenge principal pour les équipes de maîtrise d’ouvrage et de conception du SI va avant tout être de trouver le bon point d’équilibre entre les besoins de personnalisation des services Cloud et le niveau de standardisation imposé par les fournisseurs.

En outre, les équipes informatiques vont devoir apporter toute leur expertise pour mettre en cohérence des Clouds multiples et ainsi former un SI homogène. Bien qu’habituées à des environnements complexes, elles devront également intégrer un cadre moins flexible qu’auparavant.

Faire évoluer les fonctions techniques

Avec le développement du Cloud, la spécialisation des compétences est de moins en moins d’actualité : la tendance est au profil multi-généraliste. On le voit par exemple avec la mise en place de services SaaS, comme la bureautique et la messagerie : le besoin d’experts techniques sur ces périmètres auparavant internalisés est de plus en plus faible.

Avec un SI hybride, intégrant des services Cloud et des composants hébergés en propre, la coordination technique devient un enjeu majeur. Ce sera tout particulièrement le cas sur des actions opérationnelles comme la mise en œuvre des changements ou la résolution des incidents. La présence de ces profils techniques, capables de comprendre ce SI multi-facettes et de coordonner les fournisseurs, constituera même très vite un impératif pour la DSI.

On assistera aussi à la montée en puissance de profils techniques très spécifiques, conséquence directe de l’évolution de l’architecture du SI dans le contexte Cloud. Les compétences d’intégration technique des SI (architecture, orchestration, intégration de données, etc.) vont ainsi être amenées à se développer, avec un objectif clé : garantir la cohérence du SI. Des compétences sécurité (fédération d’identité, gestion des habilitations) vont également se développer.

Renforcer les fonctions de management des services

Le phénomène d’externalisation, croissant ces dernières années, a poussé au développement de compétences de pilotage des activités externalisées, mais aussi à une réduction de la prise en charge en interne des activités opérationnelles de la DSI (production, développement…).

Cette transition du « faire » au « faire faire » est encore plus marquée dans un contexte Cloud, où le niveau de standardisation requis va imposer à la DSI d’industrialiser encore plus ses activités. Les démarches de définition et de mise en place de services et de lignes de services ont conduit à l’apparition de fonctions de type « Service Manager » ou « Service Delivery Manager », dont le rôle est de coordonner la production du service et sa bonne fourniture au client.

Ces rôles doivent fortement se renforcer sur le pilotage des volumes consommés afin d’accompagner avec proactivité les clients dans la gestion de leur demande. De cette manière, les service managers peuvent être responsabilisés sur l’équilibre économique de leur service et plus seulement sur les engagements de qualité de service et de performance opérationnelle.

Anticiper dès aujourd’hui les impacts RH du Cloud

Il est crucial de bien accompagner la transition des compétences associées aux externalisations croissantes induites par le Cloud. Une méthode classique consiste à mettre en place une démarche de Gestion Prévisionnelle des Emplois et Compétences (GPEC), aussi connue sous le nom de Talent Management.

Pour analyser l’impact RH lié au Cloud, les DSI doivent justement se doter d’une véritable cartographie de ces emplois et compétences. Les déformations RH provoquées à court terme par les décisions connues en matière de Cloud peuvent ainsi être évaluées et faire l’objet de plans d’actions de redéploiements optimaux.

Par ailleurs, une identification des impacts potentiels à moyen / long terme doit être réalisée. Elle permet d’évaluer les plans d’actions RH et management à dérouler en matière de mobilité, formation, gestion de carrière et objectifs. Autant de transformations à prendre en compte.

Cet article Cloud : une nécessaire transformation des compétences et des pratiques est apparu en premier sur RiskInsight.

Ce constat pousse les DSI à répondre à une équation complexe : comment optimiser ma stratégie de sourcing pour générer de la performance opérationnelle et économique tout en garantissant l’alignement avec mes objectifs métiers.

Bannir les idées reçues

La refonte d’une stratégie de sourcing est l’occasion de remettre à plat le modèle de sourcing en place sans hésiter à bousculer les « bonnes pratiques du marché » ni à remettre en question ses propres convictions afin d’identifier les vraies réponses aux nouveaux enjeux de la DSI en termes de sourcing.

Par exemple, il est usuel de remettre en concurrence un fournisseur dans un objectif de réduction des coûts. Or, les coûts cachés liés à la consultation et à la réversibilité peuvent venir alourdir le coût global de l’opération et venir diminuer voir annuler les gains escomptés dans certains cas.

À travers une relation de partenariat « Win-Win » et un partage des objectifs de sourcing, les fournisseurs en place peuvent jouer un rôle de partenaire conseil lors de la conception du modèle cible, voire se positionner sur de nouveaux périmètres pouvant intégrer des activités à plus forte valeur ajoutée.

Rechercher le bon équilibre entre « audace » et « conservatisme » pour redessiner les frontières du modèle de sourcing

La conception du modèle de sourcing cible doit répondre aux axes suivants :

• Contribution aux objectifs métiers : il s’agit d’identifier les « zones » du SI qui génèrent directement de la valeur pour le métier et garantissent des avantages concurrentiels afin d’y apporter une attention particulière dans la conception du nouveau modèle de sourcing.
• Maturité du marché : une telle refonte devra être une opportunité de se positionner à la pointe du marché sans se limiter à la capacité à faire des prestataires en place.
• Bénéfices attendus : les bénéfices économiques et opérationnels du modèle cible doivent être évalués en avance de phase. Ce critère peut être déterminant dans le choix du scénario de sourcing cible.

Dans un objectif d’optimisation des coûts, il est nécessaire de trouver le bon équilibre entre le niveau de « spécifique » imposé au prestataire et les services standard et non différenciant pour le métier. Imposer des spécificités à un fournisseur revient à renoncer aux bénéfices de l’industrialisation et de la mutualisation et, de fait, à la réduction des coûts.

Bâtir une stratégie de sourcing en approche Base Zéro afin d’élargir le champ du possible

Construire son modèle de sourcing cible en mode top-down sans se laisser guider par les choix du passé permet de dessiner le modèle qui répondra le mieux aux objectifs stratégiques, opérationnels et économiques de la DSI. Il ne s’agit pas de refaire l’histoire ni d’opposer les différents modèles de sourcing en place mais de faire émerger un nouveau modèle agile et ajustable en fonction des périmètres externalisés.

Cette approche permet d’aboutir, plus facilement, à un consensus sur la cible indépendamment des modèles de sourcing, des organisations et de la gouvernance en place. Une fois la cible définie, une analyse d’écart entre la cible et la situation courante permettra d’identifier les vraies contraintes de transformation et d’affiner la cible.

Trop souvent, les DSI se mettent des barrières « imaginaires » quand il s’agit de faire évoluer leur modèle de sourcing. La part des activités / services externalisés étant souvent très significative, pour garantir l’alignement et l’évolutivité de leur modèle de sourcing avec les objectifs métiers, les DSI ne doivent pas hésiter à être offensifs et innovants sur ce sujet.

Cet article Refonte de stratégie de sourcing DSI, et si tout était possible ? est apparu en premier sur RiskInsight.