Commercial offerings include editor-backed platforms such as Horizon3.ai / NodeZero, Pentera, XBOW, and RunSybil, while the open-source ecosystem includes projects such as Strix, Shannon, PentAGI, PentestGPT, and PentestAgent. Their positioning differs, but they all attempt to translate the adaptability of modern AI systems into concrete offensive security outcomes.

The objective of this article is not to rank vendors. Instead, it is to clarify how agentic pentesting systems work, what technical prerequisites they require, and where their current limitations still prevent them from being treated as fully reliable autonomous testers.

A common architecture for agentic offensive testing

The current landscape is made up of heterogeneous tools with very different product strategies and target use cases: external web security testing, internal infrastructure and Active Directory reviews, cloud security assessments, or source-code analysis close to the CI/CD pipeline.

Nowadays, in their best configurations, the strongest systems can conduct autonomous static and dynamic security reviews with strong reasoning capabilities, and a workflow that can, at times, resemble the analytical posture of a human pentester.

Many of these tools are benchmarked internally, or through capture-the-flag environments, as CTFs provide an observable way to compare reasoning depth, exploitation ability, and tool usage. Despite a wide range of architecture, the following essential building blocks are broadly consistent across most solutions:

• An orchestrator: This layer coordinates parallel agents, handles freezes and timeouts, manages preconfigured workflows, and connects the other components into a coherent execution chain.
• An underlying LLM: The model acts as the cognitive core of the system, alternating between reasoning loops, tool invocation, and the creation of sub-agents when needed. Tool use is mandatory, and larger frontier models generally yield better results.
• An attack toolbox: Most platforms rely on a containerized toolkit broadly aligned with standard Kali-style capabilities. The exact content varies by use case, but web testing stacks are often relatively conventional. Many solutions also allow the agent to download additional tools or clone GitHub repositories dynamicaly when required.
• A set of skills or knowledge packs: These local libraries encode reusable expertise, including technology-specific attack techniques, pentester cheat sheets, standard exploitation workflows, and details related to newly disclosed vulnerabilities or attack patterns.

This last layer is often where vendors can differentiate most clearly. Strong cyber monitoring, threat hunting, and cyber threat intelligence capabilities can continuously refresh the knowledge base and improve both adaptability and confidence in the actual coverage delivered by automated sessions.

Because these agents can execute offensive actions against production-like environments, observability and governance are essential. Most serious implementations therefore include logging, telemetry, session replay, human approval steps for selected actions, and safeguards that distinguish lower-risk modules from more dangerous commands or exploit paths.

A key distinction often blurred in vendor marketing: fully agentic systems use an LLM to drive the entire decision loop, while AI-assisted platforms apply AI only to specific steps (usually the hardest exploitation decisions) within an otherwise deterministic pipeline. Most commercial products today fall into the second category.

An efficiency case study

Case study : CTF

To assess the current effectiveness of agentic pentesting, we benchmarked one such solution (Strix) using several different models against an internal set of Wavestone CTF challenges for which no public write-ups were available. The goal was not to compare products against each other, but rather to understand how model quality affects outcomes in a web security context.

This choice of benchmark offers a useful signal because web exploitation combines broad topic coverage with varying levels of difficulty. At the same time, the exercise should not be over-generalized: it does not fully represent other contexts such as internal infrastructure testing or Active Directory assessments.

Several conclusions emerged from this exercise:

• The results become genuinely impressive only when the system is paired with a state-of-the-art model.
• Conversely, models that can realistically run on a high-end consumer workstation still tend to produce mediocre offensive-testing performance, which often makes SaaS-based AI providers the sole effective solution today.
• Even powerful models can miss exploitable weaknesses, while some still-large but less optimized models can underperform, potentially because Strix was not designed and tuned with them in mind.
• Smaller models occasionally show flashes of insight and solve challenges that stronger models miss.
• A broad tendency remains for models to hallucinate paths to exploitation, especially when they reach a dead end. In CTF settings this often manifests as fabricated flags rather than validated solutions.
• In order to not pollute their context with large volume of data, agents tend to heavily truncate data (such as web pages or codebase files) and being too specific when using “grep” or “find” for research. In both cases, the behavior can restrict their coverage of the scope and their overall efficiency.

These results should be interpreted cautiously. For each model and each challenge, the benchmark was limited to at most two runs. In several cases, a model was very close to the solution before hallucinating the final step, or required human steering to close the investigation. Typically, those cases could plausibly be recovered in a real-world workflow that includes human review.

The best benchmark results were obtained with frontier proprietary models. In our observations, these models can solve a substantial portion of constrained offensive tasks while remaining operationally affordable; at least as long as sessions converge quickly.

What it shows is :

• Per-challenge cost can remain relatively modest, on the order of a few euros when the agent converges efficiently.
• Execution can be surprisingly fast, with many CTFs solved in less than five minutes when the model identifies the relevant path early.
• Failure is expensive. Without strict guardrails on duration and budget, token consumption can increase dramatically over the course of a few hours.
• In our own setup, solve rates between top-tier commercial models were close, but efficiency varied substantially in time, token consumption, and number of tool invocations. Surprisingly, despite Sonnet’s higher per-token price, overall session costs were comparable to GPT-5, Anthropic’s model compensated through greater token efficiency.

Case study : real web application

To complement the CTF benchmarks, we also tested one of our internally developed web applications (used for staffing and performance management). The system was assessed with several approaches, including authenticated modes in which the agent is provided with credentials or tokens.

In one representative pentesting session, 25 agents were deployed, 366 tool calls were executed, for a total cost around USD 5, and the session ran for around one hour. The resulting automatically generated report included an executive summary, an OWASP-oriented methodology section, technical findings with CVSS v3 scoring, and a prioritized remediation roadmap.

The outputs were mixed, but broadly informative after human review and retesting:

• The agent surfaced several relevant minor improvement areas, although findings were not always well contextualized and could become overly alarmist.
• Critical miss however : the agent completely missed an exposed admin interface with default credentials: a vulnerability no human pentester would overlook. This illustrates the reliability ceiling of current autonomous systems.
• The report also included a non-existent vulnerability candidate, JWT algorithm confusion, rated as critical, along with proof-of-exploit scripts that did not succeed in practice. This illustrates the persistent false-positive risk of autonomous systems.

Additional remarks :

• As with the CTF benchmarks, the quality of the review improved significantly when using a frontier-grade model.
• The non-deterministic nature of generative models remains visible: two runs can produce substantially different findings and reports against the same target.
• If prompting and scope controls are insufficient, some models attempt to expand the scope of the assessment by probing adjacent ports, applications, or subdomains.
• Coverage and relevance improve markedly in white-box or hybrid white-box/grey-box modes, where the agent can inspect the codebase, identify candidate weaknesses, and then attempt to validate them dynamically on the live application. Even then, some agents can still fixate on non-existent issues. And in white-box, very large codebases may saturate the system and reduce overall efficiency.
• Browser-driven interactions have progressed, yet some application types remain difficult to assess autonomously, especially multi-window or thick-client environments where headless browser interaction may not be enough.
• These systems rarely build a deep understanding of business logic. Their outputs remain strongly aligned with generic OWASP-style patterns and may not challenge the real business risk or abuse scenarios in a sufficiently contextual way.

It should be noted that the majority of these criticisms can also apply to human pentesters, who nonetheless remain more easily held accountable.

The scaling problem remains central. CTFs are only partially representative of real applications. While a CTF typically channels the tester toward a narrow and deliberate attack path, even a modest business application exposes a much broader surface. Today, guaranteeing exhaustiveness while avoiding fixation on irrelevant endpoints remains difficult.

Verdict and current limitations

Verdict

If one considers solutions that relies entirely on a general-purpose LLM for its decision tree, the conclusion is clear at the present time: only frontier-grade models from major AI providers consistently deliver results that are both relevant and reasonably verifiable.

Condisering four practical deployment options:

• SaaS LLM services: currently the highest-quality option, leveraging very large frontier models (>1T parameters) billed per use. The main drawback is data sovereignty: all prompts and findings leave your environment.
• Large private datacenter deployments, which can run powerful models (500b) and may become increasingly relevant for pentesting, but may still remain materially below the best commercial frontier systems.
• Small private datacenter deployments, which can run capable models (300b), but clearly not sufficient to efficiently orchestrate autonomous pentests.
• Dedicated workstations, which, even with very strong specifications, may quickly struggle above 100b, and remain far insufficient today.

The dependence on SaaS providers raises unavoidable sovereignty and confidentiality questions. Offensive security assessments often consolidate highly sensitive technical information about an organization’s weaknesses. Any externalization of prompts, traces, findings, or attack hypotheses therefore requires careful governance. And data anonymisation before the LLM step might not be a reliable mitigation, as it can decrease the efficiency of the run, while still sharing exploitable meta-data my SaaS suppliers.

In their current state, even equipped with the most capable LLMs, these systems also exhibit structural limitations that directly affect reliability:

• Instances of “tunnel vision”, with prolonged fixation on a single irrelevant attack path.
• A tendency to launch time-consuming brute-force activities without a sound appreciation of computational complexity or cost.
• Persistent hallucinations: despite significant progress, even frontier models still fabricate findings, exploit paths, or flag non-existent vulnerabilities, as shown in the JWT confusion example.

• The non deterministic nature of LLM, making some runs way less efficient and relevant than others
• A scaling problem tied to context-window constraints: it “scales” in the sense that you can launch as many parallel sessions against as many targets. However, it scales more poorly when a single session is launched against a single highly complex application. It becomes much harder to maintain exhaustive coverage and memory continuity across large, content-rich applications. Large improvments can be achieved on this front, with an efficient long term memory management allowing for more coherent runs for large applications and improving coverage.
• High verbosity and limited stealth, which makes these systems poorly suited in their default form for red-team style end-to-end scenarios that require discretion and tradecraft. This can be improved through dedicated configuration, without however equaling human capabilities

And from a higher standpoint, an autonomous SaaS-run process having the ability to remotely execute commands in your IS poses from the start the issue of accountability :

• Classifying tools as dangerous versus safe may not be enough, for instance with Swiss-army toolsets, capable of the most inocuous recon and of aggressive and potentially damaging exploits. Threat level should be dynamically assessed, taking the context and previous tests into accounts.
• Even then, pausing the tests and requesting a human approval may lead to a similar situation with coding agents, with “developer fatigue”, where users become too trusting and stop critically challenging the agent’s conclusions.

And of course, any vulnerability at the LLM level, such as susceptibility to prompt injection or poisonning, could be leveraged to hijack the automated pentest workflow. Essentially, those autonomous tools, if deployed internally, should be regarded as critical assets, with high value for attackers.

Where the architecture can improve

Beyond model quality itself, a substantial part of the improvement space lies in the overall system design. Several architectural directions already appear promising:

• Multiply sessions and validation passes, using continuous exploration, focused zoom-in phases, and explicit confirmation loops for candidate findings. This improves reliability but increases cost and duration.
• Precede the autonomous phase with scripted tests and deterministic reconnaissance, then feed those structured outputs to the agent. This is far more cost-efficient than spending LLM context and tokens on tasks that are already easy to automate without AI. The core principle should be simple: do not use AI where conventional automation already performs well. Delegate only the genuinely ambiguous, adaptive, or investigative parts of the workflow to the LLM, and avoid overloading the model with unnecessary command history and context noise.
• Introduce dedicated validation instances to confirm exploitability in a controlled environment before findings are promoted to a report.
• Use leaner decision trees or specialized modules upstream of exploitation, reserving high-end models only for the parts of the workflow that truly require adaptability and reasoning.

In practice, this last point is already the direction taken by many vendor platforms. They do not rely entirely on agentic AI; instead, they combine deterministic security logic with agentic exploitation only when potential weaknesses have already been narrowed down.

Lastly, an interesting thought : as such automated solutions may be used by real attackers, we may see “anti-AI” mechanisms included in applications and endpoints, such as “links labyrith” and token-draining honeypots designed specifically to mislead or exhaust automated testing systems.

With strong enough models, agentic systems can already excel in constrained environments such as CTFs. Their performance in real application assessments is more mixed: often useful, sometimes impressive, but still too inconsistent to be trusted without human oversight.

The most pragmatic path today is therefore a hybrid operating model: an agentic system carrying out the majority of the tests and suggesting investigation leads, supported by human pentesters who arbitrate, validate, and take over in the most complex cases. The result is a security assessment that is significantly shorter, while still guaranteeing a degree of coverage and relevance in the findings.

Agentic AI is not a replacement for human pentesters, not yet. At its current level of maturity, it is better understood as a force multiplier, one that can accelerate exploration and triage, but that still depends on expert supervision to turn raw autonomous activity into trustworthy security outcomes. In any case, these systems should also be treated as highly sensitive because of their autonomous nature, and the current constraints toward SaaS-run models should be considered, in terms of data confidentiality and digital souvereignty.

Despite not being fully mature yet, those solutions are beginning to leave a mark in the cybersecurity landscape, and will most likely alter the trajectory of the pentesting market, toward an ecosystem more centered on tools and compute while conserving a hybrid approach. We might even see audits following a “Bring Your Own Compute” model, where auditees provide their own LLM, and the auditors provide custom tools and skills.

Cet article Agentic AI for Offensive Security est apparu en premier sur RiskInsight.

The projected impact of agentic AI is significant. By 2028, it could automate 15% of routine[1] decision-making and be embedded in a third of enterprise applications, up from virtually none today. At the same time, perceptions of risk are shifting. In early 2024, Gartner surveyed 345 senior risk executives and identified malicious AI-driven activity and misinformation as the top two emerging threats[2]. Yet despite these concerns, organisations are accelerating adoption. By 2029, agentic AI could autonomously resolve up to 80% of common customer service issues, reducing costs by as much as 30%[3]. This tension, between the growing promise of agentic AI and the expanding risk surface it introduces, raises a critical question:

“How can organisations securely deploy agentic AI at scale, balancing innovation with accountability, and automation with control?”

This article explores that question, outlining key risks, security principles, and practical guidance to help CISOs and technology leaders navigate the next wave of AI adoption.

An AI agent is an autonomous AI system in the decision-making process

In AI systems, agents are designed to process external stimuli and respond through specific actions. The capabilities of these agents can vary significantly, especially depending on whether they are powered by LLMs.

Figure 1: A diagram to show the different constituent parts of an LLM-enabled agent, showing 1) external stimuli, 2) the agents core processes (reasoning and tools) and 3) the agent’s actions

Traditional agents typically follow a rule-based or pre-programmed workflow: they receive input, classify it, and execute a predefined action. In contrast, agentic AI introduces a new dimension by incorporating LLMs to perform reasoning and decision-making between perception and action. This, with only few words to configure it. This enables more flexible, context-aware responses, and in many cases, allows AI agents to behave more like human intermediaries.

As illustrated in Figure 1, the agentic AI workflow unfolds in several stages:

1. Perception: The AI agent receives external stimuli, such as text, images, or sound.
2. Reasoning: These inputs are processed through an orchestration layer, which transforms them into structured formats using classification rules and machine learning techniques.

Here, the LLM plays a central role. It adds a layer of adaptive thinking that enables the agent to analyse context, select tools, query external data sources, and plan multi-step actions.

3. Action: With refined data and a reasoning layer applied, the agent executes complex tasks, often with greater autonomy than traditional systems.

This architecture gives agentic AI the ability to operate across dynamic environments, adapt in real time, and coordinate with other agents or systems, a key differentiator from earlier, more static automation.

In summary, AI agents with LLM capabilities can perform more complex actions by applying “AI reasoning” to transformed and refined data, making them more powerful and versatile than traditional agents.

Field insights on Agentic AI use-cases in client environments

Businesses have rightfully recognised the potential of these AI agents in a variety of use cases, ranging from the simple, to the more complex. We will now take a deeper look at some of the different common use cases across these different levels of agent autonomy.

Basic Use Cases: Chatbot/Virtual Agents

AI agents can be configured to provide instant answers to complex questions and can be designed to only answer from certain information repositories. This allows them to smoothly and effectively guide users through extensive SharePoint libraries or other document repositories. Acting as both a search function and an assistant, these agents can dramatically improve the productivity of employees by reducing the time spent searching for information and ensuring that users have quick access to the data they need. For example, a chatbot integrated into SharePoint can help employees locate specific documents, understand company policies, or even assist with onboarding processes by providing relevant information and resources. These agents have no autonomy, and only directly respond to requests as they are made by users.

Intermediate Use Cases: Routine Task Automation

Agents can be used to streamline repetitive tasks such as managing scheduling, processing customer enquiries, and handling transactions. These agents can be designed to follow specified processes and workflows, offering significant advantages over humans by reducing human error and increasing productivity. For instance, an AI agent can automatically schedule meetings by coordinating with participants’ calendars, send reminders, and process routine customer service requests such as order tracking or account updates. This automation not only saves time but also ensures consistency and accuracy in task execution. Additionally, by handling routine tasks, AI agents free up human employees to focus on more complex and strategic activities, thereby contributing to higher efficiency and productivity within the organisation.

Advanced Use Cases: Complex data analysis & vulnerability management

Agents can also be used for more complex use cases, specifically in a security context. For example, Microsoft has recently announced the release of AI agents as part of their security copilot offering, with previews releasing in April 2025. One particularly interesting use case is regarding vulnerability remediation agents. These agents will work within Microsoft Intune to monitor endpoints for vulnerabilities, assess these vulnerabilities for potential risks and impacts, and then produce a prioritised list of remediation actions. This provides a large increase in productivity for security teams, as they can then focus on the most critical issues and streamline the decision-making process. By automating the identification and prioritisation of vulnerabilities, these agents help ensure that security teams can address the most pressing threats promptly, reducing the risk of security breaches and improving overall security posture.

The promise of intelligent automation and cost efficiency is compelling, but it also introduces a strategic trade-off. CISOs will face the growing challenge of securing increasingly autonomous systems. Without robust guardrails, organisations expose themselves to operational disruption, governance failures, and reputational damage. Transparency, asset visibility, and cloud security are areas which will also require heightened vigilance and a proactive security posture. The benefits are clear, but so are the risks. Without a security-first approach, agentic AI could quickly become a liability for organisations as much as an asset.

Risks mainly known but with increased likelihood and impact

Agentic AI introduces a new level of security complexity. Unlike traditional AI systems, where threat surfaces are generally limited to inputs, model behaviour, outputs, and infrastructure, agentic AI systems operate across dynamic, autonomous chains of interaction. This covers exchanges such as agent-to-agent, agent-to-human, and human-to-agent, many of which are difficult to trace, monitor, or control in real time. As a result, the security perimeter expands beyond static models to encompass unpredictable behaviours and interactions.

Recent work by OWASP on Agents’ security[4] highlights the breadth of threats facing AI systems today. These risks span multiple domains:

• Some are traditional cybersecurity risks (e.g., data extraction, and supply chain attacks),
• Others are general GenAI risks (e.g., hallucinations, model poisonning),
• A third emerging category relates specifically to agents’ autonomy in realising actions in real world.

In addition to traditional risks, agentic AI systems introduce new security threats, such as data exfiltration through agent-driven workflows, unauthorised or unintended code execution, and “agent hijacking,” where agents are manipulated to perform harmful or malicious actions. These risks are amplified by the way many agentic AI applications are built today. Around 90% of current AI agent use cases rely on low-code platforms, prized for their speed and flexibility. However, these platforms often depend heavily on third-party libraries and components, introducing significant supply chain vulnerabilities and further expanding the overall attack surface.

Agentic AI represents a shift from passive prediction to action-oriented intelligence, enabling more advanced automation and interactive workflows. As organisations deploy networks of interacting agents, the systems become more complex, and their exposure to security risks increases. With more interfaces and autonomous exchanges, it becomes essential to establish strong security foundations early. A critical first step is mapping agent activities to maintain transparency, support effective auditing, and enable meaningful oversight.

Security Best Practices

1. Activity Mapping & Security Audits

Since AI agents operate autonomously and interact with other systems, mapping all agent activities, processes, connections, and data flows is crucial. This visibility enables the detection of anomalies and ensures alignment with security policies.

Regular audits are vital for identifying vulnerabilities, ensuring compliance, and preventing shadow AI where agents act without oversight. Unauthorised agents can expose systems to significant risks, and shadow AI, especially unsanctioned models, pose major data security threats. Auditing decision-making processes, data access, and agent interactions, along with maintaining an immutable audit trail, supports overall accountability and traceability.

To mitigate these risks, organisations should adopt clear governance policies, comprehensive training, and effective detection strategies. These practices should be backed by a strong library of AI controls and data governance policies. However, audits and governance alone aren’t enough. Robust access controls for AI agents are necessary to restrict actions and protect the system’s integrity.

      2. AI Filtering

To avoid the agent performing inappropriate actions, the first step is to ensure that its decision-making system is protected. One of the most efficient ways is by filtering potentially malicious inputs and outputs of the Decision-Maker, often composed of an orchestrator & an LLM.

Several technical ways to perform AI filtering:

Keyword filtering – Medium-Low Efficiency: Prevent the LLM from considering any input containing specified keywords and from generating any output containing these keywords.

• Pro: Quick win, particularly on the outputs, for example preventing a chatbot from generating any rude words.
• Con: Can easily be bypassed by using obfuscated inputs or requiring obfuscated outputs. For example, “p@ssword” or “p,a,s,s,w,o,r,d” can be ways to bypass the keyword “password”

LLM as-a-judge – High Efficiency: Ask to the LLM to analyse both inputs & outputs and identify if they are malicious.

• Pro: Extend the analysis to the whole answer.
• Con: Can be bypassed by overflowing the agent’s inputs, so it has trouble dealing with the whole input.

AI Classification – Very-High Efficiency: Define categories of topic that the LLM can answer or not. It can be done through whitelisting (the LLM can answer to only some categories of topics) and blacklisting (the LLM cannot answer to some precise categories of topics). Use a specialised AI system to analyse each input and output.

• Pro: Ensure the agent’s alignment by not letting it receive inputs on topics it should not be able to answer.
• Con: High cost, as it requires additional LLM analysis.

These filtering actions need to be performed for the users’ inputs, but sometimes also for the data retrieved from external sources (they can be poisoned).

      3. AI-specific Security Measures

Human-in-the-loop (HITL) oversight is essential for ensuring the responsible and secure operation of agentic AI. While AI agents can autonomously perform tasks, human review in high-risk or ethically sensitive situations provides an extra layer of judgment and accountability. This oversight helps prevent errors, biases, and unintended consequences, while allowing organisations to intervene when AI actions deviate from guidelines or ethical standards. HITL also fosters trust in AI systems and ensures alignment with business objectives and regulatory requirements. To maximise the benefits of automation, a hybrid AI-human approach is critical, supported by ongoing training to address compliance and inherent risks.

Some actions may be strictly forbidden to the agent, some should require human validation, and some could be done without human supervision. These actions should be determined through classical risk analysis, based on the agent’s impact & autonomy.

Triggers should be set-up to determine if and when human validation is needed. This can be set-up in the LLM Master Prompt, and access can be restricted by using an appropriate IAM model.

      4. Access Controls & IAM

As AI agents take on more active roles in enterprise workflows, they must be managed as non-human identities (NHIs), with their own identity lifecycle, access permissions, and governance policies. Accordingly, this requires integrating agents into existing identity and IAM frameworks, applying the same rigor used for human users.

Managing AI agents introduces new requirements. When acting on behalf of end-users, agents must be constrained to operate strictly within the permissions of those users, without exceeding or retaining elevated privileges. To achieve this, organisations should enforce key IAM principles:

• Just Enough Access (JEA): Limit agents to the minimum set of permissions required to complete specific tasks.
• Just in Time (JIT) access: Provision access temporarily and contextually to reduce standing privileges and exposure.
• Segregation of duties and scoped credentials: Define clear boundaries between roles and prevent unauthorised privilege escalation.

In addition, to further enhance control, security teams should implement real-time anomaly detection to monitor agent behaviour, flag policy violations, and automatically remediate or escalate issues when necessary.

Access to sensitive data must also be tightly restricted. Violations should trigger immediate revocation of privileges and deny lists should be used to block known malicious patterns or endpoints.

Ultimately, while technical controls are essential, they should be supported by human oversight and governance mechanisms, particularly when agents operate in high-impact or sensitive contexts. IAM for agentic AI must evolve in step with these systems’ increasing autonomy and integration into critical business functions.

      5. AI Crisis Response & Red teaming

While AI-specific controls are essential, traditional measures like crisis management must also extend into the AI landscape. As cyberattacks become more sophisticated, organisations should consider crisis management strategies for potential AI failures or compromises; by ensuring all teams such as AI scientists, operational teams, and security teams are equipped to respond quickly and effectively to minimise disruption.

Concrete guidelines for CISOs

This year CISOs will be exposed to increased threats introduced by agentic AI alongside ongoing regulatory pressure from complex regulations such as DORA, NIS 2 and the AI Act. Both CISOs and CTOs will collaborate closely, with CISOs overseeing the secure deployment of AI systems to ensure that agent interactions are carefully mapped and secured to safeguard the security of their organisations, workforce and customers.

Key starting points for CISOs:

• Limit access to AI agents by enforcing strong access controls and aligning with existing IAM policies.
• Monitor agent behaviour by tracking activity and conducting regular audits to identify vulnerabilities.
• Filter the agent’s inputs and outputs to ensure that the decision-maker does not launch any unwilled action.
• Implement Human-in-the-Loop oversight to validate AI outputs for critical decisions/tasks.
• Provide agentic AI awareness training to educate employees on the risks, security best practices and identifying potential attacks.
• Perform AI red teaming on the agent, to identify potential weaknesses.
• Despite all security measures, AI operates on probabilistic principles rather than deterministic ones. This means that the agent might occasionally behave inappropriately. Therefore, it’s crucial to establish clear accountability for any wrongful actions taken by AI agents.
• Prepare for AI crises early by initiating discussions with relevant teams to ensure a coordinated response if an incident occurs.

Over the past several years, Wavestone has observed a marked increase in client maturity around AI security. Many organisations have already implemented robust processes to assess the sensitivity of AI initiatives and to manage associated risks. These early efforts have proven valuable in reducing exposure and strengthening governance.

While agentic AI does not fundamentally rewrite the AI security playbook, it does introduce a meaningful shift in the risk landscape. Its inherently autonomous, interconnected nature increases both the impact and likelihood of certain threats. The complexity of these systems can be challenging at first, but they are manageable. With a clear understanding of these dynamics and the emergence of new market standards and security protocols, agentic AI can deliver on its transformative potential.

As this transition unfolds, we remain committed to helping CISOs and their teams navigate the evolving risk environment with confidence.

References

[1] Orlando, Fla., Gartner Identifies the Top 10 Strategic Technology Trends for 2025, October 21, 2024. https://www.gartner.com/en/newsroom/press-releases/2024-10-21-gartner-identifies-the-top-10-strategic-technology-trends-for-2025

[2] Stamford, Conn., Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029, March 5, 2025. https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290

[3] Stamford, Conn. Gartner Survey Shows AI-Enhanced Malicious Attacks Are a New Top Emerging Risk for Enterprises, May 22, 2024. https://www.gartner.com/en/newsroom/press-releases/2024-05-22-gartner-survey-shows-ai-enhanced-malicious-attacks-are-new0

[4] OWASP, OWASP Top 10 threats and mitigation for AI Agents, 2025. OWASP-Agentic-AI/README.md at main · precize/OWASP-Agentic-AI · GitHub

Thank you to Leina HATCH for her valuable assistance in writing this article.

Cet article Agentic AI: typology of risks and security measures est apparu en premier sur RiskInsight.

Figure 1 : Example of the Leaking exploit found in ChatGPT in December 

Scandals like these highlight a deeper truth: the core architecture of Large Language Models (LLMs) such as GPT and Google’s Gemini is inherently prone to data leakage. This leakage can involve Personally Identifiable Information (PII) or confidential company data. The techniques used by attackers will continue to evolve in response to improved defenses from tech giants, the underlying vectors remain unchanged. 

Today, three main vectors exist through which PIIs (Personally Identifiable Information) or sensitive data might be exposed to such attacks:  

• The use of publicly available web content in training datasets 
• The continuous re-training of models using user prompts and conversations 
• The introduction of persistent memory features in chatbots 
   

LLM Pre-Training Data Leakage  

Most models available right now are transformer models, specifically GPTs or Generative Pre-Trained Transformers. The Pre-Trained in GPT refers to the initial training phase, where the model is exposed to a massive, diverse corpus of data unrelated to its final application. This helps the model learn foundational knowledge such as grammar, vocabulary, and factual information. When GPTs were first released, companies were transparent on where this training data came from, but currently the largest models on the web have datasets that are too large and too diverse and are often kept confidential.  

A major source of the data used in GPT pre-training are online forums such as Reddit (for Google’s models), Stack Overflow, and other social media platforms. This poses a significant risk since these social media forums often contain PIIs . Although companies claim to filter out PII during training, there have been many instances where LLMs have leaked personal data from their pre-training data corpus to users after some prompt engineering and jail breaking. This danger will become ever more present as companies race to gather more data through web scraping to train larger and more sophisticated models.  

Known leaks of this type are mostly uncovered by researchers who develop more and more creative methods to bypass the defenses of chatbots. The example mentioned earlier is one such case. By prompting the chatbot to repeat forever a word, it “forgets” its task and begins to exhibit a behavior known as memorization. In this state, the chatbot regurgitates data from its training set. While this attack has been patched, new prompt techniques continue to be found to change the behavior of the chatbot.

User Input Re-Usage and Re-Training  

User Inputs re-training is the process of continuously improving the LLM by training it on user inputs. This can be done in several ways, the most popular of which is RLHF or Reinforcement Learning from Human Feedback.   

Figure 3 : The feedback buttons used for RLHF in ChatGPT 

This method is built on top of collecting user feedback on the LLM’s output. Many users of LLMs might have seen the “Thumbs Up” or “Thumbs Down” buttons in ChatGPT or other LLM platforms.  

These buttons collect feedback from the user and use the feedback to re-train the model. If the user signifies the response as positive, the platform takes the user input / model output pair and encourages the model to replicate the behavior. Similarly, if the user indicates that the model performed poorly, the user input / model output pair will be used to discourage the model from replicating the behavior.  

However, continuous re-training can also occur without any user interaction. Models may occasionally use user input / model output to re-train in seemingly random ways. The lack of transparency from model providers and developers makes it difficult to pinpoint exactly how this happens. However, many users across the internet have reported models gaining new knowledge through re-training from other users’ chats all the way back to 2022. For example, OpenAI’s GPT 3.5 should not be able to know any information after Sept 2021, its cut-off date. Yet, asking it about recent information such as Elon Musk’s new position as CEO of Twitter (now X) will provide you with a different reality as it confidently answers your question with accuracy.   

Essentially, what this means for end-users is that their chats are not kept confidential at all and any information given to the LLM through internal documents, meeting minutes or development codebases may show up in the chats of other users thus leaking it. This poses significant privacy risks not only for individuals but also for companies, many of which have already taken action, like Samsung. In April 2023, Samsung banned the use of ChatGPT and similar chatbots after a group of employees used the tool for coding assistance and summarizing meeting notes. Although Samsung has no concrete evidence that the data was used by OpenAI, the potential risk was deemed too high to allow employees to continue using the tool. This is a classic example of Shadow AI, where unauthorized use of AI tools leads to the possible leakage of confidential or proprietary information. 

Many companies globally are waiting for stricter AI and data regulations before using LLMs for commercial use. We are seeing certain industries such as consulting open up but at an incredibly slow pace. Other companies, however, are tightening their control over internal LLM use to avoid leaking confidential data and client information.  

Memory Persistence 

While the two precedent risks have been recognized to exist for a few years, a new threat has emerged with the introduction of a feature by ChatGPT in September 2024. This feature enables the model to retain long-term memory of user conversations. The idea is to reduce redundancy by allowing the chatbot to remember user preferences, context, and previous interactions, thereby improving the relevance and personalization of responses.  

However, this convenience comes at a significant security cost. Unlike earlier cases, where leaked information was more or less random, persistent memory introduces account-level targeting. Now, attackers could potentially exploit this memory to extract specific details from a particular user’s history, significantly raising the stakes. 

Security researcher Johannes Rehberger demonstrated how this vulnerability could be exploited through a technique known as context poisoning. In his proof-of-concept, he crafted a site with a malicious image containing instructions. Once the targeted chatbot views the URL, its persistent memory is poisoned. This covert instruction allows the chatbot to be manipulated into extracting sensitive information from the victim’s conversation history and transmitting it to an external URL. 

This attack is particularly dangerous because it combines persistence and stealth. Once it infiltrates the chatbot, it remains active indefinitely, continuously exfiltrating user data until the memory is cleaned. At the same time, it is subtle enough to go unnoticed, requiring careful human analysis of the memory to be detected. 

LLM Data Privacy and Mitigation  

LLM developers often intentionally make it hard to disable re-training since it benefits their LLM development. If your personal information is already out in public, it has probably been scraped and used for pre-training an LLM. Additionally, if you gave ChatGPT or another LLM a confidential document in your prompt (without manually turning re-training OFF), it has most probably been used for re-training.  

Currently, there is no reliable technique that allows an individual to request the deletion of their data once it has been used for model training. Addressing this challenge is the goal of an emerging research area known as Machine Unlearning. This field focuses on developing methods to selectively remove the influence of specific data points from a trained model, thus deleting those data from the memory of the model. The field is evolving rapidly, particularly in response to GDPR regulations that enforce the right to erasure. For this reason, it is important to mitigate and minimize these risks in the future by controlling what data individuals and organizations put out on the internet and what information employees add to their prompts.  

It is vital for many business operations to stay confidential. However, the productivity boost that LLMs add to employee workflows cannot be overlooked. For this reason, we constructed a 3-step framework to ensure that organizations can harness the power of LLMs without losing control over their data.  

Choose the most optimal model, environment and configuration  

Ensure that the environment and model you are using are well-secured. Check over the model’s data retention period and the provider’s policy on re-training on user conversations. Ensure that you have “Auto-delete” as ON when available and “Chat History” to OFF.   

At Wavestone we made a tool that compares the top 3 closed-source and open-source models in terms of pricing, data retention period, guard rails, and confidentiality to empower organizations in their AI journey. 

Raise employee awareness on best practices when using LLMs  

Ensure that your employees know the danger of providing confidential and client information to LLMs and what they can do to minimize including corporate or personal information in an LLM’s pre-training and re-training data corpus.  

Implement a robust AI policy   

Forward-looking companies should implement a robust internal AI policy that specifies:  

• What information can and can’t be shared with LLMs internally  
• Monitoring of AI behavior  
• Limiting their online presence  
• Anonymization of prompt data  
• Limiting use to secure AI tools only  

Following these steps, organizations can minimize the digital risk they face by using the latest GenAI tools while also benefiting from their productivity increases.  

Moving Forward  

Although the data privacy vulnerabilities mentioned in this article impact individuals like you and me, their cause is the LLM developers’ greed for data. This greed produces higher-quality end products but at the cost of data privacy and autonomy.  

New regulations and technologies have come out to combat this issue such as the EU AI Act and OWASP top 10 LLM checklist. However, relying solely on responsible governance is not enough. Individuals and organizations must actively recognize the critical role PIIs play in today’s digital landscape and take proactive steps to protect them. This is especially important as we move toward more agentic AI systems, which autonomously interact with multiple third-party services. Not only will these systems process an increasing amount of personal and sensitive data, but this data will also be transmitted and handled by numerous different services, complicating oversight and control. 

References and Further Reading  

[1] D. Goodin, “OpenAI says mysterious chat histories resulted from account takeover,” Ars Technica, https://arstechnica.com/security/2024/01/ars-reader-reports-chatgpt-is-sending-him-conversations-from-unrelated-ai-users/ (accessed Jul. 13, 2024). 

[2] M. Nasr et al., “Extracting Training Data from ChatGPT,” not-just-memorization , Nov. 28, 2023. Available: https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html 

[3] “What Is Confidential Computing? Defined and Explained,” Fortinet. Available: https://www.fortinet.com/resources/cyberglossary/confidential-computing#:~:text=Confidential%20computing%20refers%20to%20cloud 

[4] S. Wilson, “OWASP Top 10 for Large Language Model Applications | OWASP Foundation,” owasp.org, Oct. 18, 2023. Available: https://owasp.org/www-project-top-10-for-large-language-model-applications/ 

[5] “Explaining the Einstein Trust Layer,” Salesforce. Available: https://www.salesforce.com/news/stories/video/explaining-the-einstein-gpt-trust-layer/ 

[6] “Hacker plants false memories in ChatGPT to steal user data in perpetuity” Ars Technica , 24 sept. 2024 Available: https://arstechnica.com/security/2024/09/false-memories-planted-in-chatgpt-give-hacker-persistent-exfiltration-channel/

[7] “Why we’re teaching LLMs to forget things” IBM, 07 Oct 2024 Available: https://research.ibm.com/blog/llm-unlearning

Cet article Leaking Minds: How Your Data Could Slip Through AI Chatbots  est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter February 2021 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter January 2021 est apparu en premier sur RiskInsight.

After having seen in a first article the state of the threat and the current issues related to vulnerability management, we will see in this second article the new approaches to be considered to better manage vulnerabilities, in particular through the prioritization of vulnerability remediation proposed by Hackuity.

The advent of Risk-Based Vulnerability Management (RBVM)

Risk Based Vulnerability Management (RBVM) is an approach that treats each vulnerability according to the risk it represents for each company.

In this context, the classic formula for calculating a risk applies:

The first part of the formula, vulnerability × threat, can also be considered as a probability. This probability describes the chances that a given vulnerability will be discovered and used by a threat actor in the specific technical context of the organization.The last part of the formula describes the consequences, or impact, of a successful attack by a threat actor in the company’s business context.

This is in synthesis the approach adopted by CVSS, a standard developed by FIRST (Forum of Incident Response and Security Teams), initially to quantify the technical severity of a vulnerability. Through 3 metrics (basic, temporal, environmental), the full CVSS score (now in its version 3.1) is supposed to reflect the real risk of each vulnerability, in the context of each company.

Source: FIRST (https://www.first.org/cvss/specification-document)

Our purpose here is not to describe CVSS, so we assume that the reader is familiar with the concept. The CVSS score has many advantages, among the main ones:

• The only standard on the market available to quantify the criticality of a vulnerability,
• A detailed and transparent algorithm,
• A scoring widely adopted by the industry,
• Several world-wide reference databases available (in particular to qualify the criticality of CVE).

However, it has many limitations, the main ones of which can be listed here:

1. Its low granularity: each of the metrics is composed of categorical values with predetermined values (e.g., low, medium, high) which limits its discrimination capabilities.
2. Its vocation to unitarily qualify vulnerabilities: it is thus impossible to evaluate the criticality of a complete attack scenario with CVSS. For example, some cyber-attacks exploit several low vulnerabilities to compromise an entire perimeter. However, the CVSS assessment will only cover each of the vulnerabilities independently; it is necessary for the auditor to present a global scenario to highlight the overall risk, and they cannot rely solely on CVSS to do so since it was not designed to be aggregated.
3. Its arbitrary nature: the weights in the algorithm sometimes seem to be composed of arbitrary figures making the interpretation of these values complex. In the end, there is sometimes a significant margin of error in the CVSS quantification of the same vulnerability by two professionals.

On the other hand, should it be reminded, the public CVSS scores, such as those referenced in the NVD, are only base scores. They represent the intrinsic criticality of a vulnerability, but do not reflect the risk that this vulnerability represents for the company. In other words, they answer the question “Is it dangerous?” but not “Is it dangerous for my company right now?”.

Effective vulnerability management must take into account not only the base score, but also temporal and environmental metrics. The FIRST provides the framework, but the NIST cannot compute the CVSS score for the enterprise, as it requires knowledge of the criticality of the assets, identification of controls in place, the exploitability of the vulnerability in this specific context, or the intensity of the actual and current threat.

In the field, however, we note that nearly 45% of the companies surveyed – of all sizes – only use the CVSS base score as the sole metric for quantifying the criticality of vulnerabilities.

Beyond the relevance of this approach, the use of this single metric does not solve the major problem of the industry, which remains the volume of vulnerabilities to be addressed.

Of the 123,454 vulnerabilities (CVE) identified as of 01/15/2020, more than 16K had a CVSS base score (V2.0) deemed critical (i.e., more than 13% of the total).

Beyond CVSS ?

The objective of prioritization is therefore to reduce the stock of vulnerabilities by discriminating the most critical in order to allow the teams and means of remediation to focus on the vulnerabilities that matter the most.

On the other hand, there is no doubt that the daily flood of new vulnerabilities brought up by the detection arsenal can no longer be managed manually. It is totally unrealistic to manually examine, analyze and prioritize all identified vulnerabilities.

Automation should enable teams to work more efficiently, reducing repetitive and/or low value-added manual tasks and processes.

To meet these needs and respond to the limitations of CVSS, the RBVM players are introducing:

• New risk metrics (scores) – proprietary – that complete, overload or replace CVSS,
• Automation of analysis and measurement tasks, including correlation with threat sources (CTI) to continuously qualify the threat intensity associated with each vulnerability.

More generally, the RBVM approach takes into account numerous evaluation metrics to establish a score based on context and threat. There seems to be a consensus on 4 main categories of criteria:

1/ The vulnerability or the individual – intrinsic – characteristics of the vulnerability itself.

Through these criteria, the aim is to measure the severity of a vulnerability by taking into account metrics that are constant over time and regardless of the environment, such as the privileges required to exploit the vulnerability or its attack vector (remotely, on the same local network, with physical access, etc.).

For this category, the CVSS base score (generally taken in its version 2.0 to ensure anteriority) is a solid starting point for analyzing the intrinsic criticality of the vulnerability. This is the score used by most solutions on the market.

2/ The external threats that will be used to quantify the current intensity of the threat associated with each vulnerability.

The metrics used reflect characteristics that may change over time but not from one technical environment to another.

“Is the vulnerability associated with hot topics on discussion forums, the darknet and social networks? Does it have an exploitation mechanism been published or is it currently being exploited by a particularly virulent ransomware?”

The availability of an “exploit” associated with a vulnerability is, for example, an important factor taken up by most risk-based vulnerability management solutions. According to a Tenable Research study, 76% of vulnerabilities with a CVSS baseline score > 7 do not have an exploit available.

Source: (https://fr.tenable.com/research)

This means that companies that are focusing on fixing all their vulnerabilities with a “high” or “critical” risk according to CVSS would spend three thirds of their time filling in holes that ultimately represent little risk. For better operational efficiency, it is therefore appropriate to focus remediation efforts on vulnerabilities for which an exploit has already been released.

But this is far from being the only relevant criteria. Without known exploit, the age of the vulnerability can be taken into account to compute its probability of exploitation, using a statistical approach based on the occurrences of exploitation measured. Some initiatives such as EPSS (Exploit Prediction Scoring System[1] ) even try to predict the “weaponization” of vulnerabilities.

Like the age of the vulnerability, the age of the exploit is also a factor that will highly influence the probability of exploitation. For example, the CVE exploitation rate skyrockets as soon as an exploit is published, and then progressively decreases.

More generally, the threat intensity is an important metric in the prioritization algorithm. Beyond statistical approaches, it can be measured by monitoring CTI sources, social networks or various publications, such as quantifying the number of occurrences of these vulnerabilities in cybercriminal forum discussions. It will thus be possible to determine that a new or particularly active malware exploits a vulnerability and therefore to increase its criticality score.

Many other indicators can be integrated to refine the relevance of vulnerability prioritization. The Hackuity solution takes into account more than 10 criteria in addition to the CVSS metrics to compute its “True Risk Score”:

In addition to the relevance of the choice of these criteria and the algorithm itself, the type and quality of the CTI sources monitored to continuously feed these metrics represent an important issue.

Some of the sources used include the numerous open sources (OSINT) on vulnerabilities and threats (NIST-NVD, Exploit-db, Metasploit, Vuldb, PacketStorm, …), some of which are consolidated through open-source initiatives such as VIA4CVE (https://github.com/cve-search/VIA4CVE).

There are also a large number of private and commercial players offering CTI feeds with virous levels of specialization in vulnerability intelligence.

3/ The technical context or the unique characteristics of the environment in which the asset is located.

This category is used to measure the probability / difficulty to exploit a vulnerability in the specific context of each organization.

“Is the asset exposed on the Internet or hidden somewhere in the company’s datacenter? What are the technical measures (protection, detection) that make it more or less vulnerable to attacks?”

If some market actors just determine that an asset is exposed on the Internet based on its IP addressing scheme, others like Hackuity will seek to measure the depth of the attack trees needed to exploit the vulnerability in the company’s IS.

These characteristics are by definition specific to each environment. It is therefore necessary to have, take from, or determine such information, in particular by feeding the prioritization formula with contextual data linked to the assets. For example, the data may exist and therefore be extracted from internal repositories.

4/ The business criticality of the asset.

This involves measuring the consequences, or impact, of a successful attack by a threat player in the business context of the company.

“Is the asset impacted by the vulnerability critical to the organization in one way or another? Does it host sensitive or nominative information? What are the impacts for the company in terms of financial, reputation or compliance if the vulnerability is exploited?”

As much as for the technical context, these characteristics are specific to each environment. They may be manually entered or derived from risk analysis results such as Business Impact Analyses.

To conclude on RBVM, whatever the degree of automation brought by the Solution, it will only take its full strength with the contribution of contextual elements that the tool cannot guess (business impacts, technical environment of the assets, organization, processes, etc.).

Beyond RBVM: Vulnerability Prioritization Technologies (VPTs)

While the major market leaders in vulnerability detection have adopted a risk-based approach to Vulnerability Management, they have not addressed the main problem associated with the “best-of-breed” approach to detection: companies use multiple detection tools and practices to ensure complete and effective coverage of their technical perimeter.

Average number of detection tools by company size / Hackuity – Panel of 93 companies

As mentioned above, this necessary use to a heterogeneous arsenal promotes a fragmented and unconsolidated view of the situation, which limits the ability to scale and, with the growing volume of vulnerabilities, leads to an explosion of costs.

To address this problem, emerging market players named VPTs (Vulnerability Prioritization Technologies) by Gartner, such as Hackuity, agnostically exploit existing sources of vulnerability.

They collect and centralize vulnerabilities from any company’s detection arsenal: multiple practices (pentest, bug-bounty, red team, etc.), vulnerability detection solution providers (vulnerability scans, SAST, DAST, IAST, SCA, etc.) and vulnerability watch feeds. The main features of VPT solutions are described below.

Functional diagram of the Hackuity solution

A comprehensive view of the state of the stock of vulnerabilities

Automating the collection of vulnerabilities enables security teams to have, sometimes for the first time, a consolidated and centralized view of the company’s stock of vulnerabilities, regardless of the solutions or detection practices implemented.

A crucial operation – and one that is very rarely performed – is the conversion of proprietary formats into a normalized format. This allows clones of the same vulnerability, which have been identified by several sources, to de deduplicated (e.g. the same SQL injection identified during an intrusion test and during a vulnerability scan).

As such, Hackuity’s vulnerability’s meta-repository is a multilingual knowledge base that provides a unified and standardized description of all vulnerabilities, including corrective actions, patches, remediation costs, or exploitability, with no loss of information from the original source.

The establishment and enrichment of an inventory of assets

In the field, there are only rare exceptions of companies that have an inventory of their assets that is considered complete or at least reliable (CMDB, ITAM, …). This is an endemic problem in the practice and sometimes the main obstacle to the implementation of an efficient vulnerability management policy in companies. In order to solve this problem, some solutions integrate into their operations the dynamic and continuous establishment of the repository of the company’s assets inventory. This inventory is established by analyzing and correlating the technical data collected (e.g. the software stack installed on a server, its various aliases, etc.) and provides an asset database that is continuously kept up to date with data from multiple sources.

Asset criticality is also a key element in the vulnerability risk measurement process and accounts for nearly 50% in a prioritization approach. Without an accurate inventory of assets and an assessment of their criticality in the company’s business environment, it is impossible to accurately compute the real risk associated with each vulnerability. Some solutions, such as Hackuity, will compensate for the absence or non-completeness of risk analyses by automatically assessing the criticality of assets based on their technical and operational properties (types and families of tools installed, density of interconnections, hosted databases, etc.).

In the end, to have consolidated information about vulnerabilities or the company’s assets, you no longer need to master dozens of tools or formats: the cost and workload associated with managing disparate tools is significantly reduced.

The missing link between detection and remediation of vulnerabilities

Finally, the bidirectional link with the teams in charge of remediation or security supervision provides a collaborative approach in managing the stock of vulnerabilities.

Indeed, while automation has become a key lever for vulnerability management, the human factor remains at the heart of the process.

In most companies, Vulnerability Management involves 3 actors who must work together:

1. The security teams in charge of operating the detection tools and managing remediation plans,
2. The business managers who arbitrate or clarify the remediation plans in the light of business constraints,
3. Operational staff in charge of deploying corrective measures (patch management, configuration, development, etc.).

The efficiency of the process is therefore not limited to the automation of vulnerability collection. In the downstream part of the process (remediation management), play-books can be used to mobilize the resources needed to implement corrective measures: identification of the person in charge of the task, automatic creation of incident tickets, generation of scripts for Infrastructure as Code solutions, etc.

Upstream, the CISO finally has, and often for the first time, a real-time perception of the progress of remediation plans.

The vulnerability management solution is then the orchestrator of the ecosystem of solutions aiming at detecting, qualifying, correcting and monitoring vulnerabilities affecting the company.

Designed as an open system, it also allows third party tools and processes (SIEM, GRC, Compliance, Forensics, …) to be fed with consolidated and structured data on vulnerabilities, assets and threats affecting the business.

Conclusion

As a true cornerstone of corporate cyber security, vulnerability management can finally be synonymous with a scalable, effective practice for which it is now possible to have factual indicators reflecting the efforts made by security teams and teams in charge of remediation.

Besides the direct impact on the company’s security posture, through a reduction in the vulnerability exploitation window, or even the mobilization of experts on high added-value tasks, the integration of a vulnerability management orchestration solution can also have indirect benefits, such as better understanding the information system thanks or even a tenfold increase in the commitment of the teams thanks to the quantification of the impact of their actions on the company’s security.

[1] https://arxiv.org/pdf/1908.04856.pdf

Cet article Hackuity | Shake’Up – The future of vulnerability management: towards new approaches based on risk and prioritization (2/2) est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter December 2020 est apparu en premier sur RiskInsight.

What is a bug bounty and what is it used for?

Mere buzzwords a few years ago, bug bounty programmes and vulnerability disclosure initiatives have since permeated the cyber-related vocabularies of a wide range of organisations, whether it be digital giants, top investment banks, or government bodies. The basic principle is the following: companies provide a financial incentive or reward for well-intentioned hackers to find and report vulnerabilities discovered in their assets. The catch is that the company behind the initiative sets a fixed window of opportunity for hackers to discover and fix these vulnerabilities. Wavestone has studied the adoption of these initiatives within the banking sector and the good practices to be drawn from such initiatives.

3 levels of maturity: Reporting Channel, Vulnerability Disclosure Policy and Bug Bounty Programmes

When it comes to vulnerability disclosure, the initiatives are various and the terminology is broad, whether it is Coordinated Vulnerability Disclosure, Responsible Vulnerability Disclosure or Vulnerability Disclosure Policy. All of these initiatives aim at providing researchers with a safe way to report vulnerabilities, yet the level of detail regarding the reporting process, rules for searching for vulnerabilities and the expectations of the organisation in question varies greatly from one programme to another. In the light of these observations, we identified 3 levels of maturity as follows: Reporting Channel, Vulnerability Disclosure Policy (VDP) and Bug Bounty Programmes (BBP).

The first level of maturity, Reporting Channel, generally consists of a simple web page providing very basic instructions and a dedicated channel to report vulnerabilities. This first step toward vulnerability disclosure acts as a safety net in case someone discovers a vulnerability, but it doesn’t actively attract hackers, particularly due to the lack of monetary incentive. Reporting Channel is the second most common type of initiative, accounting for 28% of the identified initiatives.

The second level of maturity, Vulnerability Disclosure Policies, also takes the format of a dedicated web page but this time with much more detail. It contains advanced information on reporting processes, the assets in scope, and the preferences, rules and exceptions for vulnerability researching. Furthermore, in most cases (90%), information regarding the expectations that hackers may have after submitting a report in terms of both service-level agreements (SLAs) and public recognition for their work are outlined. In many of these initiatives (77%), companies commit to providing hackers with safe harbour and not pursuing legal action against hackers if they follow the rules and act in good faith. This kind of initiative can be managed internally or by a third-party platform (HackerOne, BugCrowd, Synack…) that will communicate with hackers and oversee bug triage.

Finally, Bug Bounty Programmes represent the highest level of maturity, as it features the same level of information as Vulnerability Disclosure Policy but this time, hackers are financially rewarded for reporting vulnerabilities. This aims to attract talented hackers and make bug bounties a fully-fledged tool in banks’ cyber-ecosystems. Third-party platforms can either manage these programmes or set up private programmes to which only vetted hackers will have access (following a background and skills check). In many cases, private programmes are used as a steppingstone to bug bounty, allowing companies to gain experience with the concept before moving on to a public programme. They also make it possible to implement advanced security features (full research monitoring through VPNs, Non-Disclosure Agreements, advanced vetting, on-location research…) which make it easier to comply with the security and confidentiality standards that are common in the banking sector.

The banking industry is not outdistanced by other industries

These initiatives were implemented by 18% of the studied banks, which is 2.5 times higher than the average reported in the Forbes Global 2000. Therefore, it can be said that the banking sector has well-integrated vulnerability disclosure processes as part of its cyber ecosystem, with the banking and insurance sector ranking in 3rd position in terms of number of programmes for Internet and online services and computer software. However, it is not the most attractive from a financial point of view, ranking in 12th place in terms of the average remuneration for a critical vulnerability, with blockchains and crypto currencies offering an average remuneration that is almost 3 times higher (source: HackerOne’s Hacker Powered Security Report 2019).

Western banks are more confident about engaging in vulnerability disclosure processes

Although the adoption of vulnerability disclosure processes in the banking sector seems to be global, this research found that initiatives are mainly adopted by European and American banks with some specificities. These observations can be explained by several factors.

In the US, vulnerability disclosure has long been part of the culture of tech industry giants such as Google and Facebook which, among other companies, launched their own programmes before 2012. The US are also home to players that now rank among the world’s leading bug bounty platforms, including BugCrowd (2011), HackerOne (2012) and Synack (2013). It is therefore not a surprise to see that these platforms are managing most of the American banks’ vulnerability disclosure programmes.

In Europe, the situation is different and there are fewer key players. After several major cyber incidents, the Netherlands was the first country in Europe to launch a national initiative by publishing the Guidelines for Coordinated Vulnerability Disclosure (2013) – a collaborative effort between the Dutch Government’s National Cyber Security Centrum (NCSC) and various private sector companies. Today, nearly 70% of the major Dutch banks have a self-managed bug bounty programme and the country has played a key role in the construction of EU guidelines on the subject matter. It is also regularly referred to as an example to be followed by several European authorities. Other initiatives and platforms have also emerged elsewhere in Europe, such as YesWeHack, Intigriti, HackenProof, Yogosha, etc. However, it is difficult to precisely assess the emergence of bug bounty programmes across Europe, as more than half of them are private and lack publicly available information for the purpose of confidentiality.

In Asia, banks are less proactive on vulnerability disclosure on account of reservations about private programmes and other cultural factors. However, the last few years have seen growing initiatives from both Asian technology giants and government institutions, notably in Singapore and Japan. This is not surprising, as many government institutions have launched this type of initiative in the past (for example, Hack The Pentagon in the USA or the recent StopCovid application’s bug bounty that is managed by YesWeHack in France).

Getting into vulnerability disclosure will require truly effective preparation

With many success stories and a growing number of companies from all sectors launching vulnerability disclosure programmes, it is tempting to follow the trend. However, to ensure the success of this type of initiative, it is crucial to address a few points. First, a vulnerability or bug bounty disclosure programme should be part of a global cyber security approach and be complementary to more traditional measures such as regular code reviews, security by design and security/pentest audits. Reporting bugs and flaws is only the first step of the process. The company must then have the in-house skills to analyse the provided reports and remediate the vulnerabilities as soon as possible. Second, to avoid wasting both the hackers’ and the company’s time, the scope of the programme must be carefully designed in order to maximize its effectiveness and prevent intrusion on unwanted assets. The same rules apply when it comes to the rules for searching and reporting. Finally, it is crucial to address hackers’ motivations to ensure the success of a bug bounty programme. Expectations for submitting a report must be clearly specified and address the process, response time and reward. Constant communication with the hacker community as well as an evolution of the programme or the rewards are some key elements that can ensure the sustainability of the programme and the motivation of hackers, thus contributing to the programme’s success.

The image of hackers is still often associated with criminal actions…

When it comes to bug bounty, one of the main concerns is security, with organisations questioning whether exposing their platforms to hackers might lead to exploitation of any discovered vulnerabilities through the sale of user data or the vulnerabilities themselves directly on the black market.

These fears are partly justified, as user data can now easily be sold on the black market: credit cards, passports, medical records or authentication information can be sold for less than EUR 15 and targeted phishing using this information can generate even more profit. A critical flaw can also be exploited and result in a much larger cyber-attack, as demonstrated by the havoc wreaked by cryptolockers in recent years. However, these incidents are rarely linked to bug bounty programmes, as malicious hackers do not wait for organisations to launch bug bounty programmes in order to attack them. Rather, these attacks can occur at any time.

Secondly, different skills and levels of preparation are required to find vulnerabilities and exploit them.

Finally, money is the primary motivation for hackers participating in these programmes in less than 15% of cases, according to HackerOne. For the majority of hackers, hacking is a passion and they are mostly looking for challenges and opportunities to improve their skills and make the web more secure – in this case, financial rewards are just a small bonus and getting on the wrong side of the law is not worth it.

Vulnerability Disclosure Policy: a first step to improve cyber security

Vulnerability disclosure and bug bounty initiatives are now a mainstream topic in the cyber security field, and the banking sector is no exception. Although bug bounty programmes are not miracle solutions and some effort is required in order to ensure that they are really effective, implementing a Vulnerability Disclosure Policy appears to add a great additional layer of security for a low investment. We can therefore only recommend implementing such a policy as soon as an organisation’s cyber maturity allows for it.

Cet article Bug Bounty: insight and benchmark on the banking industry 2021 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Novembre 2020 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter November 2020 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter October 2020 est apparu en premier sur RiskInsight.

Indicators of the month

Top attack – French shipping giant CMA CGM hit by ransomware cyber attack

CMA CGM announces that it has been affected by a ransomware attack, which disabled its reservation system and affected some of its Chinese offices. The RagnarLocker gang reportedly asked the company to contact them within two days “via a live chat and pay for a special decryption key”. In a statement, the company said it had shut all external accesses to their network and computer applications as a precautionary measure and that the group’s information system was gradually resuming.

Top exploit – Microsoft warns of attackers now exploiting “Zerologon” flaw

Microsoft’s Security Intelligence team says it’s monitoring new attacks that employ public exploits of the recently patched CVE-2020-1472 Netlogon EoP vulnerability, aka Zerologon. The vulnerability carries a critical severity rating from Microsoft as well as a maximum of 10 under the Common Vulnerability Scoring System as it lets anyone with a network toehold obtain domain-controller password.

Top leak – Microsoft leaks 6.5TB in Bing search data via unsecured elastic server

Microsoft earlier this month exposed a 6.5TB Elastic server to the world that included search terms, location coordinates, device ID data, and a partial list of which URLs were visited. According to a report from cyber-security outfit WizCase, the server was password-protected until around 10 September, when “the authentication was removed”.

Cybercrime watch

US CISA report shares details on web shells used by iranian hackers

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a malware analysis report (MAR) that includes technical details about web shells employed by Iranian hackers. According to the CISA’s report, Iranian hackers from an unnamed APT group are employing several known web shells, in attacks on IT, government, healthcare, financial, and insurance organizations across the United States. The malware used by the threat actors includes the ChunkyTuna, Tiny, and China Chopper web shells.

Two Russians charged in $17m cryptocurrency phishing spree

U.S. authorities today announced criminal charges and financial sanctions against two Russian men accused of stealing nearly $17 million worth of virtual currencies in a series of phishing attacks throughout 2017 and 2018 that spoofed websites for some of the most popular cryptocurrency exchanges.

Google Chrome bugs open browsers to attack

Google’s release of Chrome 85.0.4183.121 for Windows, Mac and Linux fixed 10 vulnerabilities. The successful exploitation of the most severe of these could allow an attacker to execute arbitrary code in the context of the browser, according to Google. Google Chrome versions prior to 85.0.4183.121 are affected.

Vulnerabilities watch

CVE-2020-1472 – Netlogon Elevation of Privilege Vulnerability

CVSS score: 10.0 CRITICAL

An elevation of privilege vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol (MS-NRPC). An attacker who successfully exploited the vulnerability could run a specially crafted application on a device on the network.

CVE-2020-0922 – Microsoft COM* for Windows Remote Code Execution Vulnerability

CVSS score: 8.8 HIGH

A remote code execution vulnerability exists in the way that Microsoft COM for Windows handles objects in memory. An attacker who successfully exploited the vulnerability could execute arbitrary code on a target system.

*The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft’s OLE (compound documents), ActiveX (Internet-enabled components), as well as others.

CVE-2020-1380 – Scripting Engine Memory Corruption Vulnerability

CVSS score: 7.5 HIGH

A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current.

Cet article Review of the current news by CERT-W – September 2020 est apparu en premier sur RiskInsight.

Cybercrime watch

The most consequent Patch Tuesday in the history of Patch Tuesday

On March, Tuesday 10th, Microsoft has released updates no less than security vulnerabilities, targeting either the Windows operating systems or associated software. 26 of these vulnerabilities are considered “critical”, which is the highest level of severity. The exploit of some of them allow remote code execution and takeover of vulnerable assets without user interaction.

Mukashi: the new variant of the famous Mirai botnet is targeting Zyxel NAS

The Mukashi botnet has been found performing bruteforce attacks on random hosts. The botnet is using various combinations of credentials in an attemps to log in and seize control of the asset. It is now targeting the Network Access Storage (NAS) from the Zyxel brand by using the recent CVE-2020-9054, which allows for remote code execution on the 5.21 version of the firmware.

Coronavirus is now the most used decoy of all times

During the sanitary crisis linked to COVID-19, the coronavirus has become the most used decoy of all times in phishing attacks. The FBI Internet Crime Complaint Center (IC3) mentions that it can either be email pretending to offer information on the virus itself, test kits, vaccines. Attackers even go to such length like posing as charities asking for donations.

Vulnerability watch

CVE-2020-0684 – Remote code execution in Microsoft Windows

A new remote code execution vulnerability has been found in the Windows operating system that is triggered when a .LNK file is processed (analyzed or executed). An attacker could gain the same privileges as the local user by exploiting this vulnerability.

CVE-2020-3946 – Denial of Service in Vmware Workstation

Some versions of Vmware Workstation and Fusion are exposed to a “use-after-free” vulnerability in the vmnetdhcp service. The successful exploit of this vulnerability currently leads to denial of service but could be used in theory to execute arbitrary code.

CVE-2020-10887 – Firewall bypass in TP-Link routers

A version of the TP-Link firmware is exposed to firewall bypass. This vulnerability originates from an insufficiant filtering when handling IPv6 SSH connections. It can be exploited without authentication and can even be used to peform privilege escalation and code execution, up to root.

Weekly top

The top leak – A 5-million record leak of Mariott’s clients

Cybercriminals have succeeded in obtaining the credentials of two employees on a third-party piece of software used in Mariott resort to provide clients with various services. They used them to access numerous information on Mariott’s clients, including names, email addresses, phone numbers, etc.
It is the second data leak in 24 months for the brand!

The top exploit – CVE-2020-0796 – Remote code execution vulnerability in the SMB protocol

SMB is a network protocol used for file sharing, printers, and for other network purposes. The Microsoft SMB 3.1.1 (SMBv3) is suject to a vulnerability in the way it handles some requests. Unauthenticated attackers can use this vulnerability to remotely execute code on SMB servers as well as clients.

The top attack – One of the largest Czech hospital hit by a cyberattack

The Brno university hospital in Czech Republic has been hit by a major cyberattack in the midst of the COVID-19 outbreak. It has been forced to shut down all IT equipment and information system. Consequently, surgical procedures have been rescheduled and newly infected patients transferred to other hospitals.

Software version watch

Cet article Review of the current news by CERT-W – March 2020 est apparu en premier sur RiskInsight.

Cybercrime watch

Google Chrome’s update fight against Cybercrime

Google Chrome version 80 now supports AES-256 to user data stored locally. The change has made an impact on AZORult’s ability to steal user’s information. AZORult is a user profile malware that appeared in 2016 thieving big amounts of information including passwords, web browsing history, cookies, etc.

Bouygues Construction another’s ransomware victim

Bouygues Construction was victim of a ransomware attack. First detected on January 30, the company announced the attack in Twitter only few days before the MAZE‘s group expressed to be behind the attack.

Internet Complain Center reporting (FBI IC3 report)

The Federal Bureau of Investigation (FBI) released the Internet Complaint Center (IC3) reporting an increment up to 1300 complaints every single day. The report shows how the Business email compromise (BEC) cost organizations $1.7 billion in 2019. Since companies have implemented “volume spam” campaigns, attackers are becoming more sophisticated targeting high-value individuals such as CEOs and finance employees.

Vulnerability watch

CVE-2020-0688 – Remote code execution vulnerability in Microsoft Exchange software

A remote code execution vulnerability exists in Microsoft Exchange software when the software fails to properly handle objects in memory, aka ‘Microsoft Exchange Memory Corruption Vulnerability’.

CVE-2019-15126 – All-zero encryption key to encrypt part of the user’s communication

An issue was discovered on Broadcom Wi-Fi client devices. Specifically, timed and handcrafted traffic can cause internal errors (related to state transitions) in a WLAN device that lead to improper layer 2 Wi-Fi encryption with a consequent possibility of information disclosure over the air for a discrete set of traffic.

CVE-2020-0022 – Critical Bluetooth vulnerability in Android

Android Bluetooth stack that lets attackers silently deliver malware to and steal data from nearby phones simply knowing the Bluetooth MAC address of the target. As result, possibility to Deny of Service (DoS), if the device is running Android 8.0, 8.1 or 9.0 then Remote Code Execution (RCE)

Weekly top

Top leak: Decathlon leaks 123 Million records

A database misconfiguration let a vpnMentor team to reveal 123 million records including customer and employee information. Over 9GB database was found from an unsecured Elasticsearch server, exposing information from Decathlon – Spain.

Top exploit: CVE-2020-6418 – Confusion flaw in V8, Google Chrome

Confusion flaw in V8 (JavaScript engine used by Google Chrome) letting to arbitrary code execution within the browser sandbox.

Top attack: Cyber-attack cripples’ wool sales across Australia

A ransomware attack affected more than 75 per cent of the wool industry across Australia. Secretary of National Auction Selling Committee (NASC) confirmed the compromising of Talman. Talman is the major software supplier to the industry.

Cet article Review of the current news by CERT-W – February 2020 est apparu en premier sur RiskInsight.

Strengthening crisis management

Cyber crises are specific: they are often long (several weeks) and sometimes difficult to grasp (what has the attacker been able to do? For how long? What is the impact?). Often, affected external parties such as lawyers, authorities, suppliers, and sometimes even clients themselves are not well-prepared on the subject matter. Thus, it is necessary to adjust existing plans that have not been designed to cater to the cyber threat aspects.

Even if they is an operational player in cyber crisis management, the CIO should not be over-utilized in either the investigation or the defense measures if it is detrimental to overall production and recovery. Anticipation of these kinds of measures is vital to the recovery effort.  It is necessary to clearly identify the teams which need to be mobilized to respond to the crisis in a timely manner, and to organize the parallel interventions on both the investigation and the construction of the defense plan.

Beyond the organizational point of view, the CIO will have to ensure that they also have the investigation tools (mapping, search for attack signature, independent crisis management IS, capability to analyze unknown malware, etc.), remediation tools (Capabilities to rapidly deploy technical corrections, fragmentation of the IS to save what could be saved, IS surveillance toolkit) and reconstruction tools (access to backup, access to minimal documentation, capabilities to deploy workstation) required to understand the position the attacker took in the IS, to repel it and to ensure it doesn’t return.

Writing a crisis management guide that defines the essential steps, the macro-level responsibilities, and the key decision points can be done as an added bonus. With that, it is essential to conduct crisis exercises to ensure readiness for when one actually occurs.

Here is a functional integrity control chain :

Rethinking continuity plans

Continuity plans have to evolve to adapt to cyberthreats. Sometimes, this means they may have to be completely rebuilt.

There are many possible solutions that can cover all types of continuity plans.

The user recovery plan, for example, can evolve to integrate USB keys containing an alternative system which could be used in case of logical destruction of employee workstations. Some organizations have also decided to provision an allotted number of workstations directly with their suppliers to have them delivered quickly in case of physical destruction.

The IT continuity plan, on the other hand, can include new solutions which could be efficient in the event of a cyberattack. The most publicized one aims to build “non- similar facilities” by duplicating an application without using the same software, operating system, or production teams. It is an extreme solution, very costly and difficult to maintain, but one that is considered for specific, critical applications in the financial industry – most notably, payment system infrastructure.

Other less complex solutions such as adding functional integrity control in the business process have also been considered. The concept relies on the implementation of regular controls, at various levels and at different places within the application chain (“multi-level controls”). This enables quick detection of attacks. An alert could be raised in case of an interaction with technical layers, such as a modification of a value directly inside a database, without passing through regular business workflows (via graphical interfaces), for example. In another case, these mechanisms can also be applied to infrastructure systems by reconciling admin account creation request tickets with the number of accounts really in the system.

As a more intermediate complexity level solution, it is possible to implement a “floodgate”, or as a system and network isolation zone. This floodgate – for example, the industrial IS – can be activated in the event of an attack and could isolate the most sensitive systems from the rest of the IS.

These, often major, evolutions must be part of an existing recovery strategy review so that one can assess their vulnerability and the interest of deploying new cyber-resilience solutions, particularly on the most critical systems. The evolution of Business Impact Analysis (BIA) to include this dimension can be a key first step.

Without cybersecurity, cyber-resilience is nothing

Implementing these new cyber-resilience measures requires significant efforts. Note that these efforts can be wasted if both these recovery solutions and the regular systems are not already appropriately secured and under detailed surveillance. The CISO is the key player to ensure that these often started but rarely finalized initiatives come to fruition. Help from the Risk Manager (RM), or the Business Continuity Manager (BCM) if such a position is in place, will be valuable. It is widely acknowledged today that it is impossible to secure a system 100%, which means that organizations have to accept the inevitability of an attack occurring, at which moment the RM or the BCM will make full use of their role.

Protect, detect, respond, remediate, and rebuild. These are the pillars of a strong cyber-resilience program which can only be attained if the BCM and the CISO roles combine their full range of capabilities and work hard, hand-in-hand!

Cet article Cyber-resilience: bend without breaking (2/2) est apparu en premier sur RiskInsight.

When confronted with a major cyber attack, whether destructive or leading to a loss of trust in vital systems, the first reaction of a majority of companies is to activate their business continuity plan (BCP). This strategic element of resiliency is enacted  to ensure the organization’s survival against disasters whose magnitude causes computing resources, communication infrastructures, buildings, and possibly even users to be unavailable.

Yet major cyber attacks, have not been taken into account when developing most BCPs, even though they can be as destructive in scale as either Wannacry or NotPetya, or, more often, lead to a loss of trust in the basic components of the infrastructure (network, access control, inventory, etc.). By Focusing on an availability agenda, organizations fail to address the issue arising from the simultaneous destruction or the loss of confidence in Information System (IS) caused by cyber attacks.

Moreover, these IS continuity plans are frequently intimately linked to the resources they protect and are equally affected by the attacks. For over a decade, continuity processes (either user fallback or IT recovery) have adopted principles of infrastructure pooling and “hot” recovery to cope with both rapid business recovery and the need for better operability.

In effect, this « proximity » between the regular IS and its recovery counterpart makes continuity plans vulnerable to cyber attacks.

What vulnerabilities in business continuity systems?

As an example, various dedicated and connected recovery stations of fallback sites were contaminated by NotPetya and were useless for the remediation.

Legacy « cold » recovery/emergency plans (often consisting  of activating a recovery system in case of incident) concern fewer and fewer applications, and the remaining ones are often secondary.

Unfortunately, when dealing with a deep compromise of systems, backups often onboard malevolent elements such as malwares, base camps, or modifications meticulously operated by attackers beforehand, due to the fact that intrusions go undetected for long period of time (detection often happens hundreds of days following the initial infection). Not to mention that the continuity of the backup systems themselves is often neglected. During the management of the NotPetya crisis, the backup management servers were also destroyed. Restoring them took several days, due to their complexity and nested nature within the information system; an ActiveDirectory was necessary to launch the restorations while the ActiveDirectory backup was a prerequisite to rebuild it.

The same findings hold for industrial IS. Industrial digital systems are resilient against technical breakdowns or anticipated mechanical incidents. However, they were rarely designed with the consideration of the possibility of human malice and as a result often lack advanced security systems. To compound on this, industrial IS has lifecycles of several decades which expose them to old vulnerabilities. Finally, the independence of control channels from the digital systems which they oversee is not always implemented.

Two illustrated major attack scenarii

Logical destruction or the unavailability of a large chunck of an Information System

Made real by attacks from true-false ransomware, Wannacry and NotPetya. This type of attack causes mass unavailability of services due to the encryption of data files and/or the operating system. The companies affected by this attack (Merck, Maersk, Saint Gobain, Fedex… as well as Sony Pictures and Saudi Amramco) lost up to 95% of their Information Systems (tens of thousands of computers and servers) in a timeframe that often lasts less than an hour. At the start of such crisis, the situation is highly difficult since there is no longer any means of communication or exchange mechanism within the affected company, including ISD. Victims have outlined losses of several hundred of million euros following these attacks.

A compromise and loss of confidence in Information Systems

It concerns a targeted attack does not challenge the proper functioning of the system. Rather, it aims to give attackers access to all of the company’s information systems (email and messaging, files, business applications, etc.) allowing them to steal the identity of any employee and carry out actions in their name. The attackers may then extract any type of data or carry out business actions which require several successive validations. These attacks affected a large number of companies across all sectors incurring massive fraud as a result, including the bank of Banglasdesh. These attacks also affected financial and payment data theft as was the case for several distribution groups in the United States including Target and Home Depot. The situation at the start of the crisis is complex since there is no confidence in the Information System and there is considerable uncertainty about what the attacker could do and their motives. It involves quietly investigating until being able to remove the attacker and rebuild a secure system. Victims affected by these attacks have also reported financial impacts worth several hundred million euros.

Cet article Cyber-resilience: bend without breaking (1/2) est apparu en premier sur RiskInsight.

Muscler la gestion de crise

Les crises cyber sont des crises particulières : souvent longues (plusieurs semaines), parfois difficiles à cerner (qu’a pu faire l’attaquant ? depuis combien de temps ? quels sont les impacts ?) et impliquant des parties externes elles-mêmes souvent peu préparées sur ce sujet (avocats, huissiers, autorités, fournisseurs, voire les clients…). Il est donc nécessaire d’ajuster les dispositifs existants qui n’ont pas été conçus pour intégrer la dimension cyber.

Acteur opérationnel de la gestion de la crise cyber, la DSI ne doit pas être sur-mobilisée sur l’investigation et la défense au détriment de la production et du secours. Cet aspect constitue un point d’anticipation important à ne pas négliger. Il s’agira donc d’identifier clairement les équipes à mobiliser sur la crise et d’organiser les interventions parallèles d’investigation et de construction de plan de défense.

Au-delà de l’aspect organisationnel, il faudra s’assurer de disposer également de l’outillage d’investigation (cartographie, recherche de signature de l’attaque, SI de gestion de crise indépendant, capacité d’analyse de malware inconnu…), d’assainissement (capacité de déploiement rapide de correctifs ou de « vaccin », isolation en urgence de portions non touchées du SI, isolation réseau…) et de reconstruction (accès rapide aux sauvegardes, accès aux documentations minimum de reconstruction, support des fournisseurs clés sur le SI, capacité à réinstaller massivement des postes de travail…) requis pour comprendre la position de l’attaquant, stopper sa propagation et faire repartir au plus vite l’activité.

La définition d’un guide de gestion de crise, définissant les étapes structurantes, les responsabilités macroscopiques et les points de clés de décision sera un plus. Et parce qu’il est primordial de s’exercer en amont afin d’être prêt le jour où il faut faire face à la crise, la réalisation d’exercice de crise sera un bon révélateur de la situation réelle.

Repenser les dispositifs de continuité

Les dispositifs de continuité doivent également évoluer pour s’adapter aux menaces cyber. Les solutions possibles sont nombreuses et peuvent toucher tous les types de dispositifs de continuité. Le plan de reprise utilisateur peut intégrer par exemple la mise à disposition de clés USB avec un système alternatif. Les collaborateurs pourraient l’utiliser en cas de destruction logique de leur poste de travail.

Certains établissements ont fait le choix de provisionner des volumes de postes de travail de remplacement directement avec leurs fournisseurs de matériel afin de les délivrer rapidement en cas de destruction physique.

Le plan de continuité informatique peut inclure de nouvelles solutions pour être efficace en cas de cyberattaque. La plus emblématique vise à construire des chaînes applicatives alternatives. Il s’agit de « dupliquer » une application sans utiliser les mêmes logiciels, systèmes d’exploitation et équipes de production. C’est une solution extrême, très coûteuse et difficile à maintenir, mais qui est envisagée pour certaines applications critiques dans le monde de la finance (notamment les infrastructures de paiement à caractère systémique).

D’autres solutions moins complexes sont envisagées. Il s’agit par exemple de l’ajout de contrôle fonctionnel d’intégrité dans le processus métier. Son concept repose sur la réalisation de contrôles réguliers, à différents niveaux et à différents endroits dans la chaîne applicative (« multi-level controls »). Ceci permet de détecter rapidement des attaques qui toucheraient par exemple les couches techniques (modification d’une valeur directement dans une base de données) sans avoir été réalisées par les actions métier classiques (via les interfaces graphiques). Ces mécanismes peuvent aussi s’appliquer aux systèmes d’infrastructures, par exemple en réconciliant les tickets de demande de création de compte d’administration avec le nombre de comptes réellement dans le système.

D’un niveau de complexité intermédiaire, il est possible d’envisager la définition de zone d’isolation système et réseau (« floodgate ») que l’on peut activer en cas d’attaques et qui vont isoler les systèmes les plus sensibles du reste du SI. Le SI industriel pourra, à ce titre, constituer à lui seul, une de ces zones d’isolation vis-à-vis du reste du SI.

Ces évolutions, souvent majeures, doivent s’inscrire dans une revue des stratégies de secours existantes afin d’évaluer leur vulnérabilité et l’intérêt de déployer des nouvelles solutions de cyber-résilience, en particulier sur les systèmes les plus critiques. L’évolution des Business Impact Analysis (BIA) pour inclure cette dimension est certainement une première étape clé.

Sans cybersécurité, la cyber-résilience n’est rien

Implémenter ces nouvelles mesures de cyber-résilience nécessite des efforts importants. Des efforts qui seront vains si ces solutions de secours et les systèmes nominaux ne sont pas eux-mêmes déjà sécurisés correctement et surveillés avec attention. Le RSSI est l’acteur clé pour faire aboutir ces démarches souvent entamées mais rarement finalisées. L’aide du Risk Manager (RM) – ou, s’il est désigné, son Responsable du Plan de Continuité d’Activité (RPCA) – sera alors un plus. Il est aujourd’hui communément acquis qu’il est impossible de sécuriser des systèmes à 100%, il faut donc accepter la probabilité d’occurrence d’une attaque et c’est à ce moment-là que le RM ou son RPCA prendra tout son rôle.

Cet article est issu de notre focus “Cyber-résilience : plier pour ne pas rompre“.

Cet article Cyber-résilience : plier pour ne pas rompre (2/2) est apparu en premier sur RiskInsight.

Face à une cyberattaque majeure, qu’elle soit destructive ou qu’elle entraîne une perte de confiance dans les systèmes clés, le premier réflexe pour une majorité d’entreprises est d’activer le plan de continuité d’activité (PCA). Celui-ci est un élément majeur de la stratégie de résilience des organisations ; afin d’en assurer la survie lorsque surviennent des sinistres d’ampleur entraînant l’indisponibilité de ressources informatiques, d’infrastructures de communication, d’immeubles voire de collaborateurs.

Or les cyberattaques majeures, destructives comme Wannacry ou NotPetya ou provoquant une perte de confiance dans les infrastructures (réseau, gestion des accès, gestion du parc…) comme les attaques ciblées en profondeur (APT), n’ont pas été prises en compte lors de l’élaboration de la majorité des PCA. Ces derniers, focalisés sur un enjeu de disponibilité, n’appréhendent pas les problématiques de la destruction simultanée et de la perte de confiance dans le SI induites par les cyberattaques.

En effet, les dispositifs de continuité du SI, le plus souvent liés aux ressources qu’ils protègent, sont également affectés par ces attaques. Depuis plus de dix ans, les dispositifs de continuité (utilisateurs ou informatiques) ont adopté les principes de mutualisation des infrastructures et de secours « à chaud » à la fois pour répondre aux exigences de reprise rapide et d’une meilleure exploitabilité. De fait, cette « proximité » entre le SI nominal et son secours rend vulnérables les dispositifs de continuité aux cyberattaques.

Quelles vulnérabilités pour les dispositifs de continuité ?

À titre d’exemple, lors d’une intervention de crise suite à l’attaque NotPetya, l’idée d’utiliser les postes de secours présents sur le site de repli a très rapidement été évoquée. Malheureusement ceux-ci avaient été détruits de la même manière que les sites nominaux car ils partageaient les mêmes systèmes de gestion de parcs et les mêmes vulnérabilités. Les investissements et les efforts investis dans les dispositifs de continuité ont semblé à ce moment très vains.

Enfin, les sauvegardes, établies sur une base souvent quotidienne, constituent pour la plupart des organisations le dispositif de dernier recours pour reconstruire le SI.

Malheureusement, en cas de compromission en profondeur, du fait de l’antériorité de l’intrusion (souvent plusieurs centaines de jours avant sa détection), ces sauvegardes embarquent de fait les éléments malveillants : malwares, camps de base, mais aussi les modifications déjà opérées par les attaquants. De plus, la continuité en tant que telle des systèmes de sauvegarde est souvent négligée. Lors de gestion de crise sur NotPetya, les serveurs gérant les sauvegardes ont eux-mêmes été détruits. Les restaurer a pris plusieurs jours vu leur complexité et leur imbrication dans le SI (nécessité de disposer d’un ActiveDirectory pour lancer des restaurations alors que la sauvegarde de l’AD était nécessaire pour le reconstruire, reconstruction de l’index des bandes de sauvegardes détruit avec le reste…).

S’agissant des SI industriels, les constats sont tout aussi manifestes. Les systèmes numériques industriels sont résilients à des pannes techniques ou des incidents mécaniques anticipés. En revanche, ils n’ont que rarement intégré, dès leur conception, les potentialités d’une malveillance humaine et ne disposent souvent pas de mécanismes de sécurité avancés. Du reste, leur cycle de vie long (plusieurs dizaines d’années) les expose à l’exploitation de vulnérabilités parfois anciennes. Enfin l’indépendance des chaînes de contrôle (Systèmes Instrumentés de Sécurité, cf. encadré ci-après) vis-à- vis des systèmes numériques qu’elles supervisent n’est pas toujours appliquée.

Des scénarios d’attaques majeures illustrés par des attaques récentes

La destruction logique ou l’indisponibilité d’une grande partie du système d’information.

Concrétisé par les attaques de vrai-faux rançongiciels Wannacry et NotPetya, ce type d’attaque entraîne une indisponibilité massive du fait du chiffrement des fichiers de données et/ou du système d’exploitation. Les sociétés touchées par ce type d’attaque (Merck, Maersk, Saint Gobain, Fedex… mais aussi Sony Pictures ou Saudi Aramco) ont perdu jusqu’à plus de 95% de leurs systèmes d’information (des dizaines de milliers d’ordinateurs et de serveurs) en un délai souvent inférieur à 1h. La situation au démarrage de la crise est très difficile car il n’y a plus aucun moyen de communication et d’échange au sein de l’entreprise, y compris au sein de la DSI. Les victimes ont communiqué sur des pertes de plusieurs centaines de millions d’euros suite à ces attaques.

La compromission et la perte de confiance dans le système d’information

Il s’agit d’attaques ciblées qui ne remettent en pas en cause le bon fonctionnement du système mais qui visent à donner aux attaquants l’accès à l’ensemble des systèmes de l’entreprise (messagerie, fichiers, applications métiers…), leur permettent d’usurper l’identité de n’importe quel employé et de réaliser des actions en leur nom. Les attaquants peuvent ainsi exfiltrer tout type de données ou réaliser des actions métiers demandant plusieurs validations successives. Ces attaques ont touché de très nombreuses entreprises dans tous les secteurs avec comme conséquences des fraudes massives, comme celles ayant touché la banque du Bangladesh, ou des vols de données financières et de paiements comme celles ayant touchés plusieurs groupes de distribution aux Etats-Unis dont Target ou encore Home Depot. La situation au démarrage de la crise est complexe en raison d’une conjugaison de plusieurs éléments aggravants : perte de confiance dans le système d’information et flou grandissant sur les actions et objectifs. Il s’agit alors d’investiguer discrètement jusqu’à pouvoir déloger l’attaquant et reconstruire un système sain. Les victimes touchées par ces attaques ont fait état d’impacts financiers de plusieurs centaines de millions d’euros.

Cet article est issu de notre focus “Cyber-résilience : plier pour ne pas rompre“.

Cet article Cyber-résilience : plier pour ne pas rompre (1/2) est apparu en premier sur RiskInsight.

Un concours digne d’une compétition sportive

Au Paris Hotel de Las Vegas, Nevada, s’est déroulé en août 2016 cet étrange concours digne d’une compétition sportive. Pendant près de 12 heures, d’imposantes machines, appelées Cyber Reasoning Systems se sont affrontées dans l’arène devant un public de 3000 personnes, auquel les présentateurs expliquaient les tentatives d’attaques et les corrections de vulnérabilités grâce à des représentations en 3D très parlantes. Organisé par la DARPA, ce concours avait un double but : valider le concept de cyberdéfense automatisée et stimuler la recherche en offrant 4 millions de dollars de prix, dont 2 à l’équipe vainqueur.

Selon Mike Walker, responsable du programme du Cyber Grand Challenge, les failles de sécurité exploitées dans la nature le seraient pendant 312 jours en moyenne avant leur détection et le temps médian de correction après détection serait de 24 jours. Un délai très long pendant lequel les systèmes restent vulnérables et que la DARPA souhaiterait voir réduit à quelques minutes ou secondes, en confiant aux machines la tâche de détecter et de corriger elles-mêmes ces failles de sécurité.

Depuis l’annonce du concours en 2013, la DARPA qui prend le sujet très au sérieux, y a investi 55 millions de dollars. 7 équipes aux propositions intéressantes ont été invitées à participer au concours en recevant une aide financière mais l’entrée restait ouverte à toute équipe auto-financée souhaitant relever le défi. En juin 2015, les qualifications ont eu lieu sur Internet pendant 24 heures au cours desquelles les équipes devaient trouver le maximum de vulnérabilités affectant 131 programmes. Sur plus de 100 équipes les 7 meilleures se sont qualifiées pour l’événement final, touchant 750.000$ au passage afin de s’y préparer. Parmi elles, 3 équipes financées par la DARPA et 4 équipes auto-financées.

Au bout de 12 heures de compétition acharnée, c’est Mayhem, le CRS de l’équipe ForAllSecure qui a remporté la victoire malgré une difficulté technique qui l’a empêché de soumettre des correctifs pendant une partie de l’épreuve. Mayhem a eu le privilège de pouvoir concourir au concours « normal » de la conférence DEFCON où s’affrontaient les meilleures équipes de hackers du monde entier. Mayhem est arrivé bon dernier de ce concours, mais à quelques points seulement de la dernière équipe humaine. Ce résultat peut être comparé à la progression des machines contre les humains aux échecs en conditions de tournoi : entre les premières victoires des machines contre des maîtres au début des années 80 et le moment où les machines parvenaient à battre des grands maîtres de façon régulière au milieu des années 2000, 25 ans se sont écoulés.

Si les machines talonnent aujourd’hui les meilleures équipes de hackers, de quoi seront-elles capables dans 10 ou 20 ans ?

Vers un monde plus sûr ?

David Brumley, CEO de ForAllSecure spinoff de l’université Carnegie Mellon, souhaite que dans le monde ultra connecté qui est le nôtre, chacun puisse avoir la garantie que les objets et les applications que nous utilisons soient sûrs, sans s’en remettre uniquement à leurs développeurs. Mais si le développement d’une cyberdéfense automatisée est une aubaine pour la société civile, on peut bien imaginer quelles implications offensives ces recherches pourraient avoir. Découvrir rapidement et en grande quantité des bugs dans des programmes fournirait autant de munitions à un état décidé à attaquer des systèmes d’organisations ou d’autres nations n’étant pas alignées avec ses intérêts. Et l’on peut être sûr que la DARPA, dont la vocation première est militaire, en a parfaitement conscience.

Cet article Et si les machines assuraient leur propre cyberdéfense ? est apparu en premier sur RiskInsight.

La sécurité informatique a fait du chemin ces dernières années. Désormais, toute entreprise de taille respectable dispose de sa politique de sécurité des systèmes d’information. Des sessions de sensibilisation des utilisateurs à la sécurité sont réalisées. Une gouvernance sécurité s’est même mise en place : le RSSI pilote, définit des KPI, analyse ses tableaux de bords SSI. Mais la technique n’est pas non plus oubliée ; on sait désormais que rien ne vaut un test d’intrusion pour vérifier, en imitant les méchants hackers, le niveau de sécurité d’une application ou d’un SI. Et ils vécurent heureux et ne subirent aucune attaque ? Pas si sûr…

Cet article Le fardeau du pentesteur est apparu en premier sur RiskInsight.

Une sécurisation insuffisante, voire inexistante

Les automates programmables industriels (API), en charge de l’interface avec le monde physique, n’intègrent souvent que peu de fonctions de sécurité et les failles de sécurité publiques les concernant sont nombreuses. L’ICS-CERT a ainsi publié près d’une centaine de bulletins de vulnérabilités sur des composants industriels. Les protocoles de communication utilisés sont un des maillons faibles de la chaîne. Ces protocoles, parmi lesquels on peut citer Modbus, permettent l’échange de consignes ou de valeurs en clair, sans chiffrement.

De même, les possibilités d’authentification des actions sont souvent limitées, permettant à n’importe quel attaquant ayant accès au réseau de modifier les consignes des automates et ainsi d’influer sur leur comportement. Les interfaces d’administration des automates sont par ailleurs souvent protégées par des mots de passe par défaut, jamais changés, et qui parfois ne peuvent pas l’être. Les systèmes plus intégrés appelés SNCC (Systèmes Numériques de Contrôle-Commande) ne sont pas garants d’une sécurité accrue, les protocoles propriétaires utilisés n’apportant pas forcément une réelle couche de sécurité.

La situation est identique pour les PC de supervision ou de programmation qui sont souvent des équipements reposant sur des technologies standard, tels que des systèmes d’exploitation Microsoft Windows. Malheureusement, l’expérience sécurité acquise sur le SI de gestion pour ces équipements profite rarement à leur sécurisation sur la partie industrielle. Les étapes de durcissement sécurité sont rares, de même que l’application de correctifs de sécurité, ou encore la présence d’un antivirus. Il est fréquent de pouvoir prendre le contrôle de ces systèmes par l’exploitation d’une faille de sécurité datant de près de 6 ans.

Un cloisonnement tout à fait relatif

De plus, les équipements du SI Industriel sont très largement interfacés avec les SI de gestion. Le cloisonnement entre ces deux mondes est souvent permissif. Il arrive même que le filtrage autorise l’accès à certains équipements industriels depuis l’ensemble du réseau interne d’une entreprise, ce qui peut représenter plusieurs dizaines de milliers de machines.
Les postes de programmation et clés USB constituent également des vecteurs d’attaques puisqu’ils sont connectés à des réseaux de niveau de sécurité hétérogène, voire à des environnements non-maîtrisés (par exemple dans le cas de sous-traitants).

Pire encore, il arrive trop souvent que des équipements industriels soient accessibles directement sur internet. Il existe même des moteurs de recherche dédiés à la recherche d’équipements exposés sur internet, Shodan étant le plus connu. Près de 1500 équipements Modbus sont ainsi recensés en France sur Shodan et plus de 20 000 dans le monde.

Un constat d’échec ?

Il ne s’agit néanmoins pas de se lamenter. Bien que le niveau de sécurité actuellement constaté soit faible, il est possible de mener des actions d’amélioration. Au-delà des concepts d’architecture qui permettent de cloisonner ces équipements vulnérables, la vraie, seule solution à long terme consiste à développer de nouveaux produits, sécurisés by design. Bien sûr, les fruits de ce travail ne se verront que sur les nouvelles installations, et pas avant plusieurs dizaines d’années. On peut espérer que la prise de conscience globale des parties prenantes, ainsi que l’implication des instances gouvernementales accélèrent ce changement.
En attendant il semble aujourd’hui nécessaire de déporter les fonctions sécurité sur des équipements dédiés, comme des passerelles encapsulant le trafic réseau dans un tunnel chiffré, ou bien des pare-feu ou IPS disposant de modules spécifiques aux protocoles industriels.

Enfin, il faut également savoir tirer parti d’une des faiblesses des SI Industriels : leur durée de vie et la complexité de changements. En effet, la mise en place d’une supervision sécurité sera facilitée par le caractère figé des réseaux industriels : il est rare que de nouveaux équipements soient installés ou que la topologie réseau soit modifiée. De même, l’emploi d’une solution de contrôle d’exécution par liste blanche sera plus facile sur un PC industriel n’exécutant qu’un seul logiciel de supervision que sur un poste de travail bureautique.

1 – http://www.rapid7.com/db/modules/auxiliary/scanner/scada/modbusclient
2 – https://github.com/arnaudsoullie/metasploit-framework/blob/modicon_stux_transfer/modules/auxiliary/admin/scada/modicon_stux_transfer.rb
3 – https://github.com/arnaudsoullie/scan7

Cet article Niveau de sécurité des SI Industriels : les vulnérabilités les plus courantes est apparu en premier sur RiskInsight.

 Le Top 10 2013, dans la continuité des Top 10 précédents

La quasi-totalité des risques présents dans le top 10 2010 le sont encore dans le top 10 2013. De même, aucun réel nouveau risque n’est apparu : il ne s’agit que d’un remaniement.

 Evolutions du Top 10 entre 2010 et 2013

Cette mise à jour reflète néanmoins les évolutions constatées lors de nos audits, et notamment le recours de plus en plus fréquent à des framework de développement, mais dont les fonctionnalités de sécurité ne sont pas forcément (bien) utilisées ; ainsi, les failles applicatives sont souvent détectées dans les modules développés spécifiquement pour les besoins métiers. Par ailleurs, le trio de tête « Injection, XSS et gestion des sessions » reste présent dans la quasi-totalité des applications que nous auditons.

Quelques évolutions marquantes du Top10 2013

 Falsification de requête intersites (CSRF)

De plus en plus, des fonctions de protection contre le CSRF sont intégrées dans les framework de développement ainsi que dans les logiciels commerciaux, ce qui explique la diminution du risque associé. Cependant, ne prenons pas pour acquis cette protection : nous constatons très fréquemment des vulnérabilités de ce type, qui restent moins connues des développeurs que les vulnérabilités d’injection.

 Manque de contrôle d’accès au niveau fonctionnel

Les vulnérabilités de contrôle d’accès remontent dans le classement, non pas parce qu’elles sont plus fréquentes, mais parce qu’elles sont mieux détectées. Il s’agit effectivement de vulnérabilités que l’on retrouve très classiquement de nos audits. De plus, ces vulnérabilités sont souvent très difficiles, voire impossible à détecter à l’aide d’outils automatisés, car elles nécessitent une bonne compréhension du fonctionnement de l’application et de la logique métier : seul un auditeur humain saura comprendre et évaluer en détails ces mécanismes.

Utilisation de composants avec des vulnérabilités connues

Le recours à des frameworks de développement, ou plus simplement à des librairies externes, est de plus en plus fréquent. Cependant, les processus associés de veille sécurité et de mise à niveau régulière ne sont que rarement mis en place ; ainsi, nombreuses sont les applications à utiliser des composants pour lesquels des vulnérabilités sont connues, et exploitables.  De plus, les modifications apportées à certaines applications peuvent empêcher l’application des correctifs de sécurité ou la migration vers des versions nouvelles. Il est donc primordial d’assurer un suivi de l’ensemble des briques applicatives utilisées, comme suggéré par la règle d’hygiène n°6 de l’ANSSI.

 La sécurité applicative, un domaine que l’on ne peut plus ignorer

Malheureusement, il est très rare d’auditer une application web dont le niveau de sécurité est satisfaisant. L’évolution du niveau de sécurité reste lente, notamment au regard d’une forte tendance à la hausse des intrusions et défacements. Pourtant, l’intégration de la sécurité dans les projets, ainsi que la création de cellules de sécurité applicative sont des initiatives qui fonctionnent !

Alors, que faire ? Ne vous arrêtez pas à 10 ! Ce Top 10 n’a pas pour vocation de lister l’ensemble des vulnérabilités possibles et imaginables sur les applications web ! Il est primordial de savoir ajuster les mesures de sécurité aux besoins de sécurité propres à votre métier et à vos données, notamment par la réalisation d’une analyse de risques préalable.
 

Le Top 10 vient également d’être traduit en français par le chapitre français de l’OWASP, projet auquel Solucom a eu le plaisir de participer. La version française est disponible sous ce lien. 

 Pour être informé des prochains événements organisés par l’OWASP France, n’hésitez pas à rejoindre la mailing-list OWASP France.

 Pour en savoir plus sur les cellules de sécurité applicative (SecApp), n’hésitez pas à télécharger notre focus sur le sujet.

Cet article SecApp : que retenir du nouveau TOP 10 de l’OWASP ? est apparu en premier sur RiskInsight.